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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jun 27, 2014, 13:50 UTC
Message-ID: <53AD76C3.3060702@drmicha.warpmail.net>
In-Reply-To: <53AD685A.1030401@drmicha.warpmail.net>

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

Show 54 quoted lines

> Michael J Gruber venit, vidit, dixit 27.06.2014 14:31:
>> Jeff King venit, vidit, dixit 16.06.2014 22:39:
>>> On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote:
>>>
>>>>> 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