[Cvs-dev] Poll regarding the 'cvs passwd' command implementation

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Folks,

Your response to this message is desirable.

As you may or may not be aware, there is a patch currently being worked
on by Prasad to implement a 'cvs passwd' command which is compatible to
the one in CVSNT and extends it slightly to allow for an encrypted
password.

I have suggested that it is a requirement that the command be able to be
used to update the CVSROOT/passwd file regardless of the connection
method. This is primarily for use by cvs administrators.

Could you please respond to this message with your opinions on the
following topics?

Call for cvs-dev opinions:

Poll A: Is it required/desirable/undesirable that an administrator be
        able to use non-:pserver: connections to the cvs server in order
        to manage passwords of all the :pserver: user passwords?

Poll B: Is it required/desirable/undesriable that a CVS user who has
        both a :pserver: as well as a non-:pserver: connection method be
        able to manage their password using the non-:pserver: connection
        method?

Poll C: Is it required/desirable/undesirable that a user who has
        successfully done a server_start() wherein their password has
        been sent to the server once already (by reading the .cvspass
        file) be prompted for their old password when setting a new
        password?

Poll D: If #C is required, then if the client is connecting over a
        non-:pserver: method, how should the user's old password be
        validated?

Poll E: If CVSROOT/config has a 'SystemAuth=no' then it is clear that
        all passwords must be in the CVSROOT/passwd file. However, if
        SystemAuth=yes, then there is the possibility that the
        administrator is using the /etc/passwd file or PAM to
        authenticate the :pserver: user's password. In these cases,
        should the 'cvs passwd' command try to change the system
        password or should it only do so for users with CVSROOT/passwd
        entries? This has implications in leaking information to an
        attacker that the password for a particular user might have more
        applicability than just CVS use. So, should SystemAuth=yes
        behave by telling the user that the "passwd" command is
        administratively unavailable? If so, should there also be a new
        CVSROOT/config item of some kind to administratively disable the
        "passwd" command? Or, do we assume that since the user had to
        authenicate in any case a 'cvs co -p CVSROOT/config' will tell
        them the story about the SystemAuth value?

The answers you provide will serve as a guide for the implementor of
this patch.

        Thank you,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFFQNXxCg7APGsDnFERAiOyAJ9Eqz/ti2OPHbRL0vaduZm/spa0zgCfWBTp
X9tNTL9OjjwdN493Gf/4S0E=
=HA3h
-----END PGP SIGNATURE-----