[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSL pserver, CVS

From: Brian Murphy
Subject: Re: SSL pserver, CVS
Date: Sat, 10 May 2003 13:52:44 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1

Alexey Mahotkin wrote:

"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;
Why not use SASL instead? This makes authentication modular too but
allows any SASL plugin to also work for CVS? Then all the kerberos code
etc can be removed from CVS.

2) code reorganization;
No argument here.

3) SSL support (with stunnel wrapping on server side, to be consistent with
  first advantage);
I will take a look at this. I will also take a look at SASL at the same time.

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.
What is the advantage of separate binaries? The code will still be a part of CVS requiring maintenance. Isn't this just the message-passing versus function call based argument again, the winner on this front is not clear to me. Do you call
external programs (fork) or have permanent daemons doing the external work?

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;
You have not commented on the PAM stuff I have submitted though it seems
relevant to your work, could you take a look at it.

How do I get a look at the nserver code?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]