Re: Commit signing

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.

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