User authentication in non-CVS repositories

How to grant access to repositories at all is an important issue, and it potentially comes with a slight regression compared to the current work flow for managing CVS accounts. One advantage of CVS is that it's easy to administer - in terms of user accounts, that would be a simple "passwd" file that contains all usernames that are allowed to commit. Dead easy to generate, and at least possible to keep in sync even in an automated way. However, more recent version control systems are less nice to handle - also caused by a better eye on security concerns. An overview.

Options for the administrator

Compared to the straight-forward approach of CVS, pretty every other version control system has a multitude of ways to access the repository. Both Subversion and all relevant distributed version control systems are providing SSH and HTTP(S)/WebDAV as proposed solution, and maybe even a proprietary protocol (svn://, git://) for quick private projects. Depending on the access method, that requires one or more of the following configuration options:

• For the proprietary protocols, it's relatively easy. The git:// protocol doesn't provide any authentication at all (so it should only be used read-only) and Subversion has a simple text file that specifies users and their passwords - although this requires passwords to be stored as plaintext (baaad!) and is thus highly unsafe and not recommended as well. Might be the only choice for servers with many restrictions, though.
• HTTP(S)/WebDAV requires configuration of Apache, which in turn can involve any authentication mechanism that Apache supports. The most widely used of these mechanisms is definitely an .htpasswd file... so that too would involve only one file to be maintained for user account management. This approach is also the preferred solution for Subversion, and for Subversion one can even have an even more detailed access control list that is stored in a separate file and controls how and which directories may be accessed by which user.
• SSH (the preferred way of authentication for all the distributed VCS) is arguably the most difficult authentication method to administer in an automated fashion, as it normally involves creating real system users on the server, and assigning them the right privileges. When taking this approach, one would also need unique groups to each repository so that different project maintainers can write to the same repository. I imagine this insanely hard to manage and integrate this with Drupal.
• As a further alternative when using SSH, it's also possible to retrieve users' ssh-keys instead of creating new system accounts and granting them shell access. There's a bit of effort involved in setting this up ("Shared SSH" docs for Mercurial, Gitosis daemon for Git) but once it's up and running, this should be easier on the administrator than the real system accounts.

Options for the Version Control API

As you can see, that's loads of possible ways on how to set up user authentication. I'm asking myself whether we should
a) try to support them all, and have a switch in each repository configuration that tells us which one to use (the most work intensive of all options), or
b) just try to support the ones that involve one or two files at maximum which can be generated automatically by a cronjob-called script, or
c) write up a howto that exactly explains how the admin has to set everything up, and depend on this, or
d) leave all of this crap to the site administrator and don't interfere with authentication at all - just provide the means to associate accounts with committer names and be done with it (current state of the non-CVS backends for Version Control API).

One more thing that might need further thought is the current per-repository view on accounts - with SSH's approach involving multiple users, it's much rather one user account on the whole server that enables access to further repositories. So instead of applying to each repository separately, there would be just one "SSH access" tab in user/*/edit instead of a "[repository] access" for each repo. And for distributed VCS, the "Commit access" tab on a project would not let one more directory through the access check but rather add or remove the user's system account to the user group of the repository.

The discomforting thing is that there's so many possible combinations, some behaviour depending on how they're combined, and that many of the differences are not even similar between multiple usages of the same VCS (or backend, for that matter). I can't tell the answer to all of that, just wanted to have everything written up in one place so that people with good ideas have a grasp of the scope of this issue. As always, input is highly appreciated.