Re: Commit signing

From: Andy Parkins <andyparkins@gmail.com>
Date: Jan 15, 2007, 10:42 UTC
Message-ID: <200701151042.12753.andyparkins@gmail.com>
In-Reply-To: <20070115101529.GB12257@spearce.org>

On Monday 2007 January 15 10:15, Shawn O. Pearce wrote:

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

That looks good to me.

> 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.

Not such overkill. I wasn't thinking of verifying every commit ever made every time the repository changes. I was thinking more of a situation when a particular commit is identified as being troublesome (like introducing a backdoor), and the person listed as comitter denies all knowledge. At that point one would verify the signature.

As an added extra, the host of the central repository could have a list of "allowed keys" so that only correctly signed commits would be allowed into the repository.

As an example of why this would be useful: let's say we have a developer committing to a maintainer repository who then merges those changes into mainline and pushes up to the central repository (like what happens with Linux). The commits to the central repository are made using the ssh login of the maintainer, but they are adding commits by someone else. What if that someone else isn't allowed to commit to the central? With signed commits the option is available to exclude them.

I don't think the argument that Matthias offered ("You just explained why no one should pull from people he does not trust.") is a good one. One might not want trust to be transitive. Just because I trust you, doesn't not mean that I trust those who you trust. The path of getting commits in via a trusted person, perhaps even via multiple levels of transitive trust might not be something that is wanted in every project. Having signed commits would at least give the option.

Show 9 quoted lines

> 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 addresses the problem somewhat. However, the problem I'm talking about is where a commit identity has been faked by someone committing to a secondary (or tertiary) level repository. While you are ensuring that the current user is allowed to commit on behalf of someone else to your repository, you haven't protected anything, because they could simply fake their ID to one of the "allowed" set and your test will pass.

> performing the checking.  And since every commit signs the entire
> chain of commits which came before it, we're in effect implicitly

While true, on a big project, with changes mainly in different areas, the fact that I committed a/file1.c after you committed b/file2.c doesn't mean I've signed off on your b/file2.c changes being non-malicious.

This is all just paranoia obviously. It's nothing that is in the remotest bit urgent, or perhaps even practical.

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com