CVS Interface Notes

Some random notes on the CVS interface, or, how to make proper usernames appear in CVS ID strings.

Bottom line is, it's hard. There are only two ways (as far as I know) to get your username into CVS:

• Be a real user with an entry in /etc/passwd
• Be a virtual user with an entry in CVSROOT/passwd

The virtual user trick might work if it were possible to forward the plaintext password from a CGI, but Apache very sensibly strips it out of the environment before the CGI sees it. You could simply eliminate passwords, but then you wouldn't be able to make the pserver available off-site. Storing plaintext passwords in a database is not an option.

In any case, we can make password entries for the users, by copying them from the adduser and passwd CGI's while they're still in plaintext. This may or may not be useful: it doesn't look easy to protect parts of the repository separately against different virtual users.

On the other hand, you probably don't want to allow external, anonymous CVS access except on a developer site, in which case the developers would have real ssh access and there's no need to protect parts of the tree anyway.

So here are the viable options, as I see them. Note that most -- maybe all -- require that the Combo server do the actual permission-checking, and then do something a little sleazy to pass the Combo UserName to CVS.

• single real user: Just use the real user that the web server is running as, e.g. apache or nobody. Put the actual Combo UserName in the log comment. We don't have to use the password server at all in this case, or we could make it available externally (though in that case it would be hard to protect individual subdirectories properly).
• single virtual user: Like ``single real user'' except use the pserver -- this means that we don't have to give nobody free run of the repository, and can even put the repository on another machine, which gives good redundancy (i.e. automagic backups). By using multiple CVS password files (selected by setting $ENV{CVS_PASSFILE} in the CGI) we can avoid actually having to log in.
• descriptive virtual user: Use only a small, fixed set of virtual users: e.g., owner, subscriber, contributor, member, and visitor. Put the actual UserName into the log comment. Don't make the password server accessible outside -- this has the possibly-desirable effect of forcing real users to use ssh.
• private password files: Give each user their own CVS identity, and generate a random CVS password for them. There's no way we can make non-anonymous CVS available through the pserver, of course. Probably ends up lowercasing the UserName, which is ugly and means that the crosslinker won't work on CVS Id's.

I rather like private password files, but it's complicated and requires making frequent changes to the global passwd file. Single and descriptive virtual users are simpler; all three allow the repository to live on another machine where it can be made available via ssh if desired. Descriptive virtual user has the virtue of putting a little extra information into the CVS Id string.

Note that we can password-protect the various virtual users and even change their passwords frequently if desired.

Bottom line: descriptive virtual user looks like the winner. Eventually Subversion may make all this irrelevant, but I'm not going to hold my breath.