Re: git tag -v should verify that the tag signer intended the same tag name as the user is verifying

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Mar 22, 2019, 05:19 UTC
Message-ID: <87imwbmqpg.fsf@fifthhorseman.net>
In-Reply-To: <xmqq1s31ui5s.fsf@gitster-ct.c.googlers.com>

Thanks for the thoughtful feedback, Junio!

On Thu 2019-03-21 10:31:59 +0900, Junio C Hamano wrote:

> The other point still stands; there are legitimate reasons people
> would want to have a tag with v1.0.0 tagname in somewhere that is
> not refs/tags/v1.0.0 and an extra validation must need to make sure
> it won't error out, even though warning is probably acceptable.

It would be great if "git tag -v" would present a warning by default in case of a tag name mismatch! I would not want to rule out making it possible to return an error though.

I don't personally have any use case for doing such a tag rename -- you mention two:

 a) wanting to call tag "foo" that you found on remote "origin" by the
    name of "origin/foo"

 b) wanting to call "v2.20.0" by the name "g2.20.0"

And Ævar mentions a third:

 c) mapping versioned tags (e.g. "v2.20.0") to tags with a date name
    ("2018-03-22")

I'm not sure how realistic or useful any of these patterns are. While (a) seems the most plausible of the lot to me, none of them are things i've ever seen in practice.

So i'd say that anyone in such a scenario is the outlier, and i wouldn't want the existence of that edge case to make git less useful in the much more common case.

Here's a revised proposal:

Consider a config setting named tag.verifyNameMatch, which can be true, false, or some sort of sed expression name mangler.

 - If set to true, it would do the thing that naive users probably
   expect when they do "git tag -v foo" -- show a warning *and* return
   an error if the tag message itself doesn't have "tag foo" in the
   "header section" of the signed tag.

 - If set to false, it wouldn't error out (though maybe it would still
   show the warning).

 - If set to a sed expression, it would feed the name being checked
   through the sed expression and ensure that the resultant value was
   present in the signed tag's "header section".

The mangler would work in a pretty straightforward way for (a) (e.g. "s_origin/(.*)_\1_") and (b) (e.g. "s_v(.*)_g\1_").

i don't see how it would handle (c), but i think there are probably better ways to handle (c) (if i'm understanding Ævar's scenario correctly) than just trying to replay the upstream author's tags with different names. For example, the curator of the repository could just make their own signed tags, based on whatever policy they wanted. Or, they could just ignore the warnings :P

As you can probably guess, i'd say that such a tag.verifyNameMatch should default to true, but i'd also be ok if it started off defaulting to false, to gather feedback about its impact, and eventually consider transitioning it to true by default.

      --dkg