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 <avarab@gmail.com>
Date: Mar 21, 2019, 11:43 UTC
Message-ID: <87r2b0cv1q.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq1s31ui5s.fsf@gitster-ct.c.googlers.com>

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

Show 20 quoted lines

> Junio C Hamano <gitster@pobox.com> 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=GyVELg@mail.gmail.com/
>
> 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.