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

Michael J Gruber venit, vidit, dixit 27.06.2014 14:49:

Michael J Gruber venit, vidit, dixit 27.06.2014 14:31:

quoted

Jeff King venit, vidit, dixit 16.06.2014 22:39:

quoted

On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote:

quoted

quoted

Your middle example above did make me think of one other thing, though.
As you noted, we actually have _three_ signature types:

  1. signed tags

  2. signed commits

  3. merges with embedded mergetag headers

We already have a tool for (1). Michael is adding a tool for (2). How
would one check (3) in a similar way?

Hmph, somehow I misread the patch that it was for both 2 & 3 X-<.

I was just assuming it handles only (2) without checking further, so I
may be wrong. But I do not think it makes sense to conflate (2) and (3).
A merge commit may have both, and they are separate signatures.

For that matter, is there a way to expose (3) currently, besides via
--show-signature? It does not trigger "%GG" and friends (nor should it).
It may make sense to add extra format specifiers for mergetag
signatures. Though I do not use them myself, so I am not clear on what
the use case is besides a manual, human verification of a particular
merge.

I'm afraid I'm on a weekly git schedule at best, sorry. Just trying to
catch up on this:

Admittedly, I simply don't know about "3.". I know only 1. and 2. (and
don't remember why they are implemented differently).

Are they documented/decribed somewhere?

Meanwhile, I'm rebasing on top of the %G related patches by Junio and
Jeff and hope to send out a v4 later today.

Michael

OK, found the two commits which "git log -Smergetag" outputs, but no tests.

A merge commit with embedded signed tag it is, then.

The commit could carry it's own commit signature, couldn't it?
That would suggest that we use "git verify-tag" to verify the embedded
signed tag of a merge commit and "git verify-commit" to verify the
commit signature.

OTOH I would like these basic commands to be as strict as possible,
including type-checks. Does that mean having "git verify-mergetag" which
verifies that it is being used on a merge commit with embedded mergetag?

... or an extension <ref>^{mergetag} to our machinery, defaulting to the
tag object containing the mergetag for the 2nd parent, with an optional
version <ref>^{mergetag}<n>?

OTOH, verifying a mergetag involves both looking at the signed tag and
the parent list of the commit. We probably should require signed (merge)
tags on all but the first parent. Oh Can of Worms, oh Can of Worms ("Oh
Can'o'Worms" to the tune of "Oh Canada").

Michael