Re: Commit signing

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 15, 2007, 10:15 UTC
Message-ID: <20070115101529.GB12257@spearce.org>
In-Reply-To: <200701151000.58609.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> wrote:

Show 18 quoted lines

> I was just talking to another developer in my office about version control.  
> He's working with Windows so has chosen Monotone for a version control 
> system.  I didn't have any huge objections, as I'm sure monotone can be 
> migrated to git without much trouble (they look to support the same features 
> from my brief reading).
> 
> Of course my favourite is git, but we were talking about the certificates 
> needed by monotone for each developer.  I assume that monotone therefore 
> signs every commit.  It obviously crossed my mind as to how one would do that 
> with git?  We obviously already have the ability to sign a tag, but is there 
> a way in which one could sign every commit.
> 
> The more I think about it, the more it could be a reasonable question.  In my 
> own repository I can obviously create whatever commits i like, claiming them 
> to be from whomever I like just by altering a few config settings.  If I put 
> a few of those in my own repository and then managed to persuade Junio to 
> pull from me - wouldn't I have faked commits from another developer?  
> However, I wouldn't be able to fake a gpg signature.

You could sign the content of the raw commit and include the signature in the payload, much like we do with tags. E.g.:

	tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
	parent 5064201cfd47822e567456fb1d6a76a5e81da800
	parent e6987d056595deace8cba91ce0a2524bb91770a9
	author Shawn O. Pearce <spearce.org> 1168855184 -0400
	committer Shawn O. Pearce <spearce.org> 1168855184 -0400

	Merge branch 'branch' into 'master'.

	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.4.6 (GNU/Linux)

	iD8DBQBFiY2zwMbZpPMRm5oRAll0AJ0ZR+Bu8zjMVe8eEKR8Xr+3QMtndACcC2Kl
	aWSkKLptN0LAOpDinq+aqOc=
	=dZlu
	-----END PGP SIGNATURE-----

But that's horribly ugly and probably vast overkill. Plus the only way to really verify each commit is to have the complete database of PGP public keys handy. A commit-msg hook could probably implement the signing.

What I'm actually doing in one particular environment is checking the committer string against a database of known committer strings associated with the current UNIX uid. My update hook[*1*] performs a `git log --pretty=raw $3 --not --all` query to determine any commits which are coming in as part of this push and which are not already referenced by an existing head or tag in this repository. For each of those the committer line *must* match one stored in the allowed-committers file for the current user, as these are brand new commits being introduced to the repository.

This works well as everyone has a UNIX account on the same system and logs in via SSH. The easiest way for us to share changes is to just push them to a single central repository. That repository is performing the checking. And since every commit signs the entire chain of commits which came before it, we're in effect implicitly signing our commits by pushing them to that server. And other developers are agreeing by building on top of that work.

[*1*] If anyone wants the hook, let me know.  I'd be happy to
      share it.  But since its undocumented I haven't offered it
      up as a contrib in git.git yet.

-- 
Shawn.