>>>>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> Pserver authentication is extremely bogus. Better authentication can
NLY> be done using SSH (if people really cared about it). If people didn't
NLY> care too much about it, they'd rely on client login as enough
NLY> authentication.
Pserver authentication is completely adequate :) It just runs over the
insecure channel and has unclean mixage of various subsystems in its
current, non-nserver form.
Nserver has the following three-layered structure:
+ cvs-pserver, cvs-kserver or cvs-sslserver setup the secure (or not)
communication channel and get CVS user name and CVS password from client
(the CVS user and CVS password could match system user and system password
for that user on server machine).
+ checkpassword, checkpassword-pam or vchkpw (for virtual repositories) do
the authentication and switch to the appropriate system accounts on server
machine (CVS-user ==> system user mapping is done at this point. Please
note that cvs pserver in the third step uses only CVS usernames (which
could be the same as system usernames)).
+ if successful, they run the "cvs pserver" itself which just talks to
client using the standard protocol over the secure (or not) channel.
As the matter of fact, cvs-sslserver could be made as just a wrapper around
cvs-pserver. sslserver will check the certificates, setup secure channel
and run the pserver that will receive the BEGIN AUTH...END AUTH request and
pass it to the checkpassword level.
server.c should be cleaned from various kerberos and gssapi-related parts
that should be split into separate binaries for the first level.
NLY> If people are really against such a change, another
NLY> $CVSROOT/CVSROOT/config parameter (eg UseRemoteUserName) can be
NLY> created.
methinks CVSROOT/config should be evaporated.
dash dash alexm
