Re: [PATCH 3/3] verify-commit: scriptable commit signature verification

[Jeff King <peff@peff.net>]

On Fri, Jun 27, 2014 at 11:36:47AM -0700, Junio C Hamano wrote:

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
> > A merge commit with embedded signed tag it is, then.
> >
> > The commit could carry it's own commit signature, couldn't it?
> 
> Yes, an integrator can choose to sign a merge he creates, merging
> the work by a contributor who gave him a pull-request for a tag
> signed by the contributor.  The resulting commit will embed the
> contributor's signature to let historians verify the second parent,
> as well as the integrator's signature to allow verification of the
> merge result.  The integrator does not need to keep the signed tag
> used as an implementation detail of transferring the signature of
> the contributor, and in general such a signed tag used only to
> request pulls is not available to the general public and historians
> after such a merge is created.
> 
> As these signatures are part of a commit object, "git verify-commit"
> would be the logical place to validate them, if we were to do so.

We already disagreed on this earlier in the discussion, but I have given
it some more thought, and somehow using "verify-commit" for mergetags
still feels wrong to me. Let me see if I can put it into words.

First off, I agree that "verify-tag" is probably not the right place.
There _is_ no tag object to verify anymore (the only reason it is a tag
at all is that the signature came out of what once was a tag).

Let us imagine that we have a "verify-commit" that verifies commit
signatures made by "commit -S". If I run "verify-commit foo", that
implies to me two things:

  1. I am verifying the signature over the contents of "foo".

     But the mergetag is _not_ a statement about "foo"; the person who
     signed it never saw "foo". It is a statement about foo^2 at best,
     or possibly about the whole history of foo^1..foo^2.

  2. I am verifying _only_ the contents of foo. That is, I expect people
     to use "commit -S" to cryptographically claim authorship of a
     commit. Whereas with tags, I think we have typically taken them to
     mean "I have signed the tip of a segment of history, and I am
     taking responsibility for the final state" (e.g., signing release
     tags).

     I realize that this claim is somewhat tenuous. It's not something
     inherent in the crypto, but rather in the social convention of what
     it means to sign a commit. One could easily say "signing a commit
     is about signing the whole tree state". But I would ask, then: what
     is the point of signing a commit versus signing a tag?  I think
     that people who wanted commit signatures wanted them to give a
     stronger guarantee of authorship of individual commits.

     Git has largely stayed agnostic about what such signatures mean.
     But if we accept that some projects _are_ going to make that
     distinction, I think conflating verification of the two within the
     same command leads to a potential for confusion.

So for that reason, I think I'd be in favor of simply treating mergetag
signatures as a separate, third entity. Give them their own
%G-specifiers, and give them a separate plumbing command. Let projects
work out how they want to use them, but do not create any particular
affiliation between mergetags and commit signatures (nor between tag
signatures and mergetag signatures).

-Peff