Mercurial and the case for signatures
Authentication with Distributed version control systems (DVCS) poses a challenge not seen with centralized systems. Centralized systems can enforce simple password checking, and you can trust the identities if the system is configured correctly. Distributed systems lack the ‘identiy oracle’, and cannot securely enforce simple password checking. Many systems allow you to specify any string as your username and email address without any verification. This has some obvious security holes - They need to use signatures.
Mercurial and git currently lack inherent cryptographic signatures on commits. One can optionally sign code, but if one commit is lacking a signature, the scheme fails. The system needs to be automatic.
The solution is to have an optional mode where every commit is automatically signed using GPG or an equivalent, and branches with unsigned commits in their history are not allowed to be merged. For open source, this would be sufficient just to log identities (which can still be anonymous). To limit usage to a set of known keys, one could use an authorized_keys file to limit the acceptable signatures.
Signatures provide a very limited definition of identity. You don’t know who is really behind the keyboard, or if that person has multiple keys. But, if you trust that person, you can decide to trust whatever they sign, and trust that they will keep good control over their keychain.
March 6th, 2009 at 1:49 pm
First, for commits to appear in canonical repository they have to be either pulled by someone with access rights (assuming that he/she trusts the repository he/she pulls from), or have rights to push to repository (with hooks providing additional access control).
Second, if you are really paranoid like IPsec guys, and require for each comit to be signed, why not use Mototone distributed version control system?
March 16th, 2009 at 10:06 pm
Monotone looks interesting - thanks for the suggestion.
I want to do this for the same reason that /var/log/* is not world-writeable. Just because someone is trusted to log in doesn’t mean they should have write-access to the log, which is used to analyze security post-facto if something happens.
The identification and logging scheme should be one ’security level’ higher than users. For unix logins, it’s done with file permissions. Ditto for SVN and CVS. For a DVCS, it likely has to be done with crypto if at all.