On 27 Oct 2000, Neil Schellenberger <[EMAIL PROTECTED]> wrote:
> I'm absolutely no expert on it (e.g. never programmed with it), but
> perhaps you could simply use OpenSSL (which is, after all, what
> OpenSSH is implemented on top of anyway). Then you'd get high grade
> encryption, certificates, and all the latest hoopla. I believe (but
> don't know) that the API is pretty simple to use.
I came to this after looking at integration with OpenSSL.
The main problem, as I see it, is that SSL does its own packetization
on top of the TCP connection. The receiver of data also sends packets
back in the other direction to negotiate cyphers, and so on.
In rsync, the destination machine runs two processes, one of which
generates checksums and the other applies changes to files. The first
only writes and the second only reads, so they can share a single
socket.
However, I don't think SSL will cope with two fork'd processes trying
to do SSL simultaneously, because the library assumes complete control
over the local end of the socket.
One solution might be to use another process that wraps the SSL
connection, but then we're likely to get the same bugs encountered
with SSH and in any case are not much better off than stunnel.
Another would be not to fork, but it seems that would lose a fair bit
of speed because we'd no longer be pipelining.
I might be wrong about SSL.
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
PGP signature
