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

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Thu, 21 Mar 2019 12:43:13 +0100

On Thu, Mar 21 2019, Junio C Hamano wrote:

> Junio C Hamano <[email-masked]> writes:
>
>>  * "git tag -v $(git rev-parse v1.0.0)" should work, but the command
>
> Sorry, forget about this part of my message.  I completely forgot the
> discussion we had a few years ago:
>
> https://public-inbox.org/git/CAPc5daV9ZvHqFtdzr565vp6Mv7O66ySr-p5Vi8o6bd6=[email-masked]/
>
> In short, "git tag -v TAGNAME" does not take an arbitrary object
> name, TAGNAME does not go through the usual ref dwimming rules
> (i.e. checking for .git/%s, .git/tag/%s, .git/heads/%s, ... to find
> one) but only looks at refs/tags/TAGNAME alone.  So we always have
> the refname it came from when inspecting tag contents that tells
> what tagname the tag has.
>
> 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.

One such example, which I don't know is actually used, but we might be
careful to break is:

 * Someone (e.g. Junio) is producing signed tags of a project like
   git.git

 * Someone else has a git repo where only upstream (signed by Junio)
   releases are allowed, but they decide *which* release.

 * Some system auto-deploys whatever the latest sorted tag in that repo
   is, after verifying that Junio tagged them.

Thus e.g. v2.21.0 might be pushed as refs/tags/2018-03-21, and if it
doesn't work out a new refs/tags/2018-03-22 might be tagged tomorrow
using the v2.20.0 tag.