Andy Parkins <andyparkins@xxxxxxxxx> 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.
> > 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html