Re: TLS/SSL patch (alpha)

[Derek R. Price]

Alexey Mahotkin wrote:

> >>>>> "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 :)  ]

On that note, I finally took a quick look at your nserver code yesterday
and it is one 97k patch.  Is it possible for you to reorganize it into
smaller chunks corresponding to "features"?  It would be much easier for
me to deal with.


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

There's a copy on bug-cvs yesterday:

    http://www.mail-archive.com/bug-cvs%40gnu.org/msg01347.html

and leading up to it:

    http://www.mail-archive.com/bug-cvs%40gnu.org/msg01346.html


> 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.

Buffers are already doing that...  sometimes...  and CVS still wants some
control over when buffers get flushed unless they go autoflush (a
performance hit), but I think I understand your logic here.  The
advantages of this kind of system is that an external socket provider
like tcpclient or stunnel or ssh can be shoved in as the final piece and
external filters like gzip and bzip can be shoved in place as desired,
but then each individual "buffer" then needs to know how to parse and
interpret a cvsroot....  the logging buffer needs to know how to launch
the (g|b)zip buffer which needs to know how to launch the auth_server
buffer which needs to know how to launch the socket buffer or the
SSL buffer or the forked server...  I'm not sure the advantages are worth
the pain when CVS already has a working stackable buffering system in
place.

Moving the buffers into indivdual C files as Bear Giles proposes seems
reasonable, however.


> 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.

Bear seems to have a fairly coherent and complete idea of how to
implement this...  You might want to browse those messages.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@collab.net         CollabNet ( http://collab.net )
--
Old heads as well as young may sometimes be charged with ignorance and
presumption.  The natural course of the human mind is certainly from credulity
to skepticism.
                        - Thomas Jefferson to Caspar Wistar, 1807