Re: SSL?

[Alexey Mahotkin]

>>>>> "DRP" == Derek R Price <dprice@collab.net> writes:

DRP> What are the advantages/disadvantages of making the encryption
DRP> code part of the authentication module or another intermediate
DRP> filter process?  What design are you using currently, Alexey?

I'm trying to use simple tunneling as much as possible.  :pserver: and
:ext: methods are working just fine this way.

Same seems to be for Kerberos, GSSAPI and SSL.  For example, I think
that server-side of CVS/SSL-server will be just a good old stunnel,
which simply runs 'cvs pserver'.  Only client side must be linked with
OpenSSL, because there is nothing you could tunnel there.  Same thing
should be done with Kerberos/GSSAPI.

But!  I've heard a rather valid (but probably ignorable ;) argument
from Martin Vogt, who says that it should be sometimes convenient to
turn off encryption altogether when commiting large (hundreds of
megabytes) binary files, while leaving encryption on when commiting
other types of files.  Hm.  I've looked at this argument once again
and it does not seem so valid to me any more :) Yes, I understand that
encrypting 200Mb adds a lot of time to transferring 200Mb over the
network (even local one), but going into trouble of creating control
channel from CVS server to its SSL-wrapper is probably not worth it...
If someone could come with other argument pro changing SSL session
parameters during single CVS operation, then step out and speak.

DRP> Of course, as I mentioned before, all of this complicates the
DRP> design of the reentrant server that has apparently been in the
DRP> works, or at least in planning, for awhile.

Well, the design of "reentrant server" (though I fail to understand
its usefulness beyond forcing developer to use sane architecturing
practices) IMHO depends largely upon reentrancy of librcs (so called)
and libdiff.  It does not seem to me that merging code, e.g., is
particularly reentrant ;)

--alexm