Re: Commit signing

Andy Parkins [off-list ref] wrote:

On Monday 2007 January 15 10:15, Shawn O. Pearce wrote:
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.

But that might reject cases where one commit has been brought up
from other repositories yet its part of a chain of 1,000 commits
now being pushed into the central repository.  You need to allow
the head that is coming in, and everything in its past.
 

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.

You can't just clip commits out during a push!  Are you going to
reject the push because the trusted SSH-logged in maintainer has
pulled in changes from elsewhere and has decided that they are good
enough for inclusion?

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.

Yes, that's very valid.  But if you trust me and I've gone and
built 100 commits on top of something I got from someone else I
trust but that you don't trust, you are going to reject all of my
changes and ask that I rewrite them?  That's quite paranoid.
 

quoted

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.

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.

Actually I'm checking for exact matching against the committer
string.  Every UNIX uid has exactly one (and only one) committer
string associated with it.  The name on their payroll and security
paperwork, and the corporate email that was assigned to them.
So you *cannot* push something which was committed by another user
or which you committed for them on their behalf.  But you can set
the author field to anything you want; indeeded I often copy in
changes from other people and mark them as the author will retaining
the committer line as myself.

This causes a huge problem with our local mirror of git.git.
Normally I would just run git-fetch on the server to update the
mirror (thus bypassing the update hook, which screams out that I'm
not Junio) but that system doesn't have cURL or expat built and I
can only fetch over HTTP from there.  So I wind up having to go
through extra hoops to update commits which came from someone I
trust, but which ain't me.

-- 
Shawn.