[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSL pserver, CVS
From: |
Alexey Mahotkin |
Subject: |
Re: SSL pserver, CVS |
Date: |
Sat, 10 May 2003 03:40:16 +0400 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-debian-linux) |
>>>>> "DRP" == Derek Robert Price <derek@ximbiot.com> 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
- SSL pserver, CVS, Brian Murphy, 2003/05/09
- Re: SSL pserver, CVS, Mark D. Baushke, 2003/05/09
- Re: SSL pserver, CVS, Max Bowsher, 2003/05/09
- Re: SSL pserver, CVS, Brian Murphy, 2003/05/09
- Re: SSL pserver, CVS, Derek Robert Price, 2003/05/09
- Re: SSL pserver, CVS, Derek Robert Price, 2003/05/09
- Re: SSL pserver, CVS, Alexey Mahotkin, 2003/05/09
- Re: SSL pserver, CVS,
Alexey Mahotkin <=
- Re: SSL pserver, CVS, Brian Murphy, 2003/05/10
- Re: SSL pserver, CVS, Mark D. Baushke, 2003/05/10
- Re: SSL pserver, CVS, Alexey Mahotkin, 2003/05/10
- Re: SSL pserver, CVS, Alexey Mahotkin, 2003/05/10
- Re: SSL pserver, CVS, Derek Robert Price, 2003/05/29
- Re: SSL pserver, CVS, Alexey Mahotkin, 2003/05/29