> >As for implementing ssh inside of rsync, I'd like to continue to reiterate
> >what a bad idea I think that is. Security is enough pain without worrying
Indeed, the biggest reason to use an external ssh program is that it
makes security updates *someone else's* problem -- ideally someone who
ca
>> -e "ssh -o'IdentityFile2 ~/.ssh/xxkey'"
sure, that causes you to pass
- o ' I d e n t i t y F i l e 2 ~ / . s s h / x x k e y '
(spaces inserted to emphasize the literal nature of the characters)
as arg 1 to ssh; the ~ isn't going to get expanded, because you've quoted it
sufficiently tha
> converse among themselves. If data is buffered up into blocks they
If you're using zlib on the streams you already *have* sufficient
packetization...
Instead of making up some hashing key-generation method, please look
at RFC2104 "HMAC" (and the six or seven followup rfc's on specific
instantiations.)
Also, for rsync, I don't see why you'd particularly want a stream
cipher (it isn't interactive, you have "large" packets to work with)
and I mig
Yes, at MIT we mount the backup volume as "OldFiles" in the user's
homedir. Causes some confusion but far less than the load of actually
doing tape restores would be...) The actual cloning is *sometimes*
user visible in that starting certain operations will get delayed
until the cloning finishes
> inconsistent, right ? And we won't notice that the file being send
> is inconsistent.
rsync could stat the initial file after reading, and complain;
actually, doesn't it do something like that already, ISTR it at least
notices length changes...
> Somewhere in the '80s, standards shifted. It's
