[ANNOUNCE] cvsauth 0.2.1

[Alexey Mahotkin]

>>>>> "MV" == Martin Vogt <address@hidden> writes:

MV> the new developement version supports full ssl encryption even
MV> with the data!

MV> Now you have 3 connection methods:

MV> Method PORT AUTHORISATION DATA

MV> :sserver 2401 ssl plain text 
MV> :s2server 2405 ssl plain text
MV> :sslserver 2405 ssl ssl

It's nice to see SSL support in CVS, but Martin, I have looked at your
changes and have couple of critical comments and comparisons with my
http://alexm.here.ru/cvs-nserver/ code. :)

It does not seem to me appropriate to have so many methods of SSL
usage.  I don't see any rationale beyond using anything else than
sslpserver protocol, that simply wraps all the CVS communications in
SSL.

In cvs-nserver I intend to simply wrap pserver into stunnel, so that
only client needs to be patched.  That way you can even run very old
cvs server binaries wrapped in stunnel, and this is a good step
forward in compatibility.

Three separate access methods don't seem reasonable: they bloat CVS
code, which by itself is bloated enough.  Several screens of
cut-and-pasted code just add to the misery :) You should at least
clean up this part and merge duplicated functionality.

In current cvs-nserver patches I've streamlined and clarified the code
in client, so that the functions are named more appropriately, and the
passing of server authentication is cleanly separated from
connect()/shutdown() parts, and SSL support just waits to be
implemented in one single well-defined point.  As a side effect it
even allows very strange combination "gserver over SSL" :)


I have at last started using cvs-nserver with virtual repositories in
real work environment, and it successfully servers several of my
co-workers, including myself, so I am going to release current
version, and then start to implement SSL in client, looking at
Martin's code :) Announcement will follow.


MV> We should find a way how to add easily new access methods to the
MV> cvsclient, currently every access method needs to be edited in 7
MV> (?)  locations.

Yes, that's real.  client.c and server.c have one big problem: they
unnecessarily mix both "network" part (connect()/shutdown(),
read()/write(), send()/recv()) and "CVS protocol" part
(send_file_names(), for example).

All non-protocol parts of clients should be moved to separate files
(network-client.c, fork-client.c, rsh_client.c etc.).  Half of servers
(most important ones: cvs-pserver and cvs-nserver) are already moved
as a result of cvs-nserver development, and the cvs-kserver.c and
cvs-gserver.c just wait for competent coders.  Help server.c to get
rid of a thousand lines or so!!! :)

--alexm