Verify Mercurial Checkins

Question

Hi,

Is there any way to verify/authenticate checkins in Mercurial? I'd like to roll out HG across our organisation (60+ developers) and I'd like a way to ensure everyone's checkins are from the correct user and that they are all in the correct format.

During trials we found that some users checked in under completely different usernames (copied someone else's .hgrc file) and others checked in under a number of different versions of their name (first name, full name, email address, etc) using different clients.

We could add a hook to enforce the format of the username but it still doesn't guarantee that it's the correct user. Does Mercurial have anything to manage this or am I just stuck in a CVS/SVN way of thinking?

Thanks, Dave.

Answer 1

Mostly you're in a CVS/SVN way of thinking -- if your employees are dishonest you're screwed anyway. :) However, there are a few ways that other folks have handled this using a variety of techniques:

• mozilla and some others have added a viewable pushlog that shows who moved each cset into each repo, so you get an implicit approval step along the way
• using the gpg extension you can make sure that csets are signed and write a quick changegroup hook to make sure that an csets entering a protected repo were signed by their author
• you can write a hook that compares the email portion of the name to the $REMOTE_USER variable (for http) or to $USER (for ssh) and require that it match the push-ing user.

None of those prevent a false commit, but you can stop a false commit from entering a thusly guarded repo.

Again though, in practice, it's just not the problem that everyone (including me) imagines it will be. One does end up with many variants of the same name from different machines, but any command that works by usernames (churn, etc.) will take an alias map to help you group them if it matters.

Answer 2

First off, you cannot verify this at commit time, because you only have access to the changeset once it gets pushed to one of your central repositories.

So you could verify that whoever is pushing the cset is also the committer (by matching http or ssh authentication). This is somewhat limiting because it can be useful when people push other developer's changesets.

You could use the pgp extension (from hgext) to explicitly sign changesets after committing, but it's kind of a drag if you want to do it for every changeset.

commitsigs is another extension, which takes a different tack to signing. It embeds the signature directly in the changeset, thereby avoiding the clutter of an extra changeset. This adds an overhead of about 2 KB to each changeset.

Mozilla uses a pushlog which just tracks who pushed what. This lets you look in the commit history on the server (but only there) to see who pushed what group of changesets, giving you a better paper trail than you normally get. This can also be provided by changegroup notifications, if you include the guy who did the push in the email (this is what Python will do once their conversion is done).

So these are the technical solutions. On the other hand, think about this some more: you've already given a group of people push access to your central repositories. If they want, they can muck about with your tree already. If you trust them to push stuff into your central tree, can't you also trust them to have the best intentions about putting their own names on their changesets?