Attempting to move this discussion to bug-cvs...

Jon Miner wrote:

> * Alexey Mahotkin ([EMAIL PROTECTED]) [010318 14:44]:
> > Yes, and also it's about flexibility.  In my scheme 'cvs' binary does not
> > know (should not know) about Kerberos, GSSAPI, SSL (this case is somewhat
> > unclear to me, probably CVS-server should indeed somehow control SSL
> > session)
>
> Kerberos/GSSAPI are not the same as SSL..  SSL is simply an encryption
> layer, not an authentication method...  It would need to be controled by
> the server, since you on;y set up the SSL link once..

True, but there might be some sense to consolidating all the encryption into a
single and separate layer as well.

I know that Kerberos/GSSAPI has an encryption scheme built in, though I don't
know how complicated passing off the necessary tokens to a child process would
be.

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

I see obvious advantages to keeping all the GSSAPI code in a single module, as
well as to having a server process which only knows about authenticated
cleartext connections on stdin/stdout, although I'll grant that good coding
can come close to achieving this appearance anyhow.

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

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED]         CollabNet ( http://collab.net )
--
As honest as the day is long.

                - S. Z. Sakall as Headwaiter Carl, _Casablanca_




_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs

Reply via email to