Re: SSL pserver, CVS

Alexey Mahotkin wrote:

>>>>>>"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;
>  
>
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?

/Brian