Re: SSL pserver, CVS

[Alexey Mahotkin]

>>>>> "BM" == Brian Murphy <brian@murphy.dk> writes:

 >> 1) server side authentication splitted into separate executables;
 >> 
 BM> Why not use SASL instead? This makes authentication modular too but
 BM> allows any SASL plugin to also work for CVS? Then all the kerberos
 BM> code etc can be removed from CVS.

When I was writing that code, I was not aware of SASL.  Maybe the idea to
somehow support SASL in CVS is a good one.  Again, I believe that server.c
split will clarify things a lot.


 >>  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.
 >> 
 BM> What is the advantage of separate binaries? The code will still be a
 BM> part of CVS requiring maintenance. 

Of course.  But the main 'cvs' binary will not have setuid() calls in it,
and anything critical like looking into /etc/shadow. 

Also, not only were the binaries separate, but also they communicated using
'checkpassword' protocol (of qmail fame).

I believe that you could separate the binaries, but do not do the
'checkpassword' part.  At least half of the advantage is here.

And yes, it will require maintenance.  How else? 


 BM> Isn't this just the message-passing
 BM> versus function call based argument again, the winner on this front is
 BM> not clear to me. Do you call external programs (fork) or have
 BM> permanent daemons doing the external work?

No permanent daemons, no fork().  Pure and simple exec().

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

Sorry, but I have not yet started the splitting crusade on server.c, and do
not fully understand what the final infrastructure would be.  So, I'll look
at your patch after it's done.


 BM> How do I get a look at the nserver code?

http://cvs-nserver.sf.net/, as was already pointed out.  Use CVS
repository.  Current HEAD there contains latest cvs-nserver merged with
latest CVS release.

--alexm