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

Jeff King [off-list ref] writes:

On Mon, Jun 23, 2014 at 09:05:46AM +0200, Michael J Gruber wrote:

quoted

This incorporates all remarks about the test coding guidelines and
rearranging the series.

Open questions:
- There was some debate about (optionally) verifying more than what
git-verify-{commit,tag} currently do, or going for a generic git-verify command.
The former would require both to be changed (in order to treat similar cases similarly),
the latter would need a deprecation for git-verify-tag.

I think that a potential "git verify" doesn't need to block this series,
per the logic I gave elsewhere.

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.

I would imagine that I would not mind too much if "verify-tag"
delegated the verification to "verify-commit" automatically when it
is given a commit object, but for a command fairly low-level to be
useful for scripting, such a DWIMmage may be too unexpected and make
them unnecessarily unreliable.  Using scripts that want strictness
(and who in the right mind that wants to verify things do not want
strictness?) would need to "cat-file -t" upfront to switch on the
object type.

On Mon, Jun 23, 2014 at 10:52:38AM -0700, Junio C Hamano wrote:

quoted

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.

-Peff