Re: TLS/SSL patch (alpha)

[Alexey Mahotkin]

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

[ Derek, please don't include me to Cc: when cvs-nserver is in Cc:
  too.  My mail system is somewhat brain-damaged and everyone on
  cvs-nserver get your messages twice...  I promise to include
  changelogs into my future patches :)  ]

DRP> This still doesn't do it for me.  Why can't you use a buffer as
DRP> your "socket"?  So, the client sends "starttls", then both server
DRP> and client treat the buffer like a socket for the next-stage
DRP> negotiation, then both stuff the newly established buffers onto
DRP> the front of their buffer chain.  The only roadblock I see from
DRP> the perspective of my limited TLS/SSL knowledge is that you will
DRP> need the server name to verify the cert, but this information
DRP> could easily have been stored somewhere and perhaps requested of
DRP> the buffer itself.

I mostly could not find anything to comment in this mail, probably
because I've not yet switched to context of the discussion, but I have
couple of words to say.

In particular, I didn't see who wrote that "SSL/TLS patch" and where
could I find it? 

It seems to me that to write SSL/TLS or SASL support for CVS is the
least half of what really should be done.  I consider proper rewriting
of CVS _client_ (NB: cvs-nserver is rewritten _server_ side).
Preliminary results are at

        http://alexm.here.ru/cvs-nserver/download/devel/

IMO buffers should be phased out and replaced by simple stacked
network clients.  That way a lot of code is moved out of client.c (as
I've already moved a lot of code out of server.c) and put into small
.c-files (socket-client.c, logging-client.c, rsh-client.c, etc.)

It currently seems to me that buffering could be implemented simply by
creating buffering-client.c which when buffer is full calls underlying
"real" client that send()s, or writes to ssh pipe, or anything else.


Simplest support for SSL is already done
(http://cvsauth.sourceforge.net/).  This project has IMO major
deficiency -- when I looked at it last time, a lot of code has been
simply cut-and-pasted (with SSL calls added).  This is inacceptable
IMHO.


Now that cvs-nserver is upgraded to 1.11.1, I'm going to merge ncli
(new stacked clients) changes and that's when I'm going to finally and
very cleanly support SSL/TLS.  


>> I haven't looked at it, but I know that SASL is covered by a number
>> of RFCs and numerous other projects are adding support for it.
>> This provides an opportunity for "herd immunity" - CVS picks up
>> strong authentication because a site has set it up for another
>> application, but since both apps use SASL the cost of the
>> additional coverage is trivial.

DRP> I've cc'd Alexey and the cvs-nserver list for comments.

I do not know much about SASL (is that kinda PAM for non-interactive
sessions?), but I see a growing trend of supporting that protocol.
Probably it's worth implementing in cvs-nserver (or cvs-ncli).

>> buffer overflow bugs and the like.  Then the auth executable can >
>> setuid and exec the cvs server when necessary/desirable.
>> 
>> I don't think either TLS/SSL or SASL require root access, although

It's not about root access.  It's about maintainability.  wc -l
server.c client.c and see for yourself.


I don't know much about SSL and seems like cannot comment further.
However, my copy of "SSL and TLS" book is already flying overseas, so
I hope to be more competent rather soon.

--alexm