Re: Commit signing

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 15, 2007, 10:56 UTC
Message-ID: <20070115105616.GE12257@spearce.org>
In-Reply-To: <200701151042.12753.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> 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.

Show 7 quoted lines

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

Show 7 quoted lines

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

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