Re: [PATCHv3 0/5] verify-commit: verify commit signatures

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 23, 2014, 21:23 UTC
Message-ID: <xmqqoaxjb9rr.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140623210930.GB15766@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 19 quoted lines

> On Mon, Jun 23, 2014 at 10:52:38AM -0700, Junio C Hamano wrote:
>
>> > The one thing that does give me pause is that we do not seem to have any
>> > way of accessing mergetag signatures. We should perhaps stop and think
>> > for a second about how we might expose those (and whether it would fit
>> > into the "git-verify-{commit,tag}" paradigm). I am tempted to say that
>> > "git verify-tag" on a commit should verify the mergetag (right now it
>> > would simply be an error). But I haven't though that hard on it.
>> 
>> I agree that "verify-commit" that lives next to "verify-tag" is fine
>> and does not have to wait for a unified "verify" that may not even
>> be a good idea, but if we were to verify the mergetags in one of
>> these "verify-$OBJECTTYPE" commands, I would think "verify-commit"
>> should be the one to check them, for the simple reason that they
>> appear in "commit" objects, not in "tag" objects.
>
> My thinking was the opposite: it is a signature on a tag, but that
> signature happens to be stuffed into a commit object. But I do not have
> a strong feeling either way.

Well, the whole point of storing mergetag inside commit objects is so that these transient "please pull, here is a tag to prove you that it is from me" tags do not have to be kept in the history; hence people who are following along only see commits and not tags. The signature being sent via a signed tag from the requestor to the integrator is merely an implementation detail after the mergetag is recorded and when people would want to verify them.

So...