Re: SSL pserver, CVS

>>>>> "DRP" == Derek Robert Price <[email protected]> writes:

 DRP> nserver has SSL already, as well as CVSNT, I believe.

While we're at it.  

cvs-nserver basically has four "advantages" (YMMV) over CVS:

 1) server side authentication splitted into separate executables;

 2) code reorganization;

 3) SSL support (with stunnel wrapping on server side, to be consistent with
   first advantage);

 4) ACL;

During the next couple of weeks I believe we shall properly unknot client.c
and server.c, thus eliminating #2 to common good.

Decision to do #1 was made largely because at that time (about three years
ago) I did not understand CVS codebase properly, because of lack of #2.
That's why I rewritten about half of CVS "buffers". Mostly this was not
necessary, but I understand it only now.

Someone really should finally do the ssl-buffer.c to use from client, and
use stunnel wrapping from server side.  That will make #3 to go away.

That leaves us mostly with #4 and the second part of #1.

ACL support (#4) in cvs-nserver is very extensive, and very CVS-oriented
(direct support for branches and modules, and many more).  There are some
very strong opponents to this whole idea, but I am now immune to this
discussion.  Let's all hope I shall grow up some day and understand the
incredible error of my ways.  Now that I started to use Andrew Morton's
patch-scripts, maybe some day the talk about integrating nserver ACLs to
CVS will be resumed (the code is surprisingly non-intrusive, and could be
fully #ifdef-protected while in Alpha, but that's a shameless plug).


As for #1b: Ability to do PAM, virtual repositories, and to move
auth-related things out of the cvs binary.  Again, I think that after the
#2 integration is complete, the patch to split away the 'cvs-pserver'
binary will look much more feasible than currently.  At the very least,
PAM patches to cvs server will look much cleaner.


So, the plan looks like this:

 I) complete #2 (me as a worker; Derek as auditor); the job is pretty
     mindless;

 II) ssl-buffer.c (someone else, looking at e.g. log-buffer.c); I could
    consult on SSL stuff and framework, although it's all pretty simple;

 IIIa) [conservative] PAM variant of switch_to_user()/check_password()
 routines; I could consult on PAM stuff and framework, although it's all
 pretty simple;

 IIIb) [modernistic/scary] I prepare patch to extract out the
 'cvs-pserver', and we use checkpassword/checkpassword-pam/vchkpwd to do
 the authentication;

 IV) something needs to be decided about virtual repositories/remote
 management of CVS passwords.  If we use it all, I probably could extract
 appropriate parts of cvs-nserver and produce a nice-looking patch.  If we
 do not use it -- let's just forget it.

 V) ACL support: again, we will need to decide if we need it at all.  If
 yes, I do the appropriate patch.  ACLs will be #ifdef-protected, and will
 need a special option to configure.  Probably, I'll first have to do the
 patch, and only then we could decide. :)


In the minimal case (we do only I, II, and IIIa) I could consider
cvs-nserver' efficiency to be about 30%).  That's six time larger that that
of a steam engine :)

--alexm