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@xxxxxxxxx
-
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