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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2019, 01:21 UTC
Message-ID: <xmqq5zsduinf.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <875zsdu41d.fsf@fifthhorseman.net>

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

Show 9 quoted lines

> I understand that git tags can be easily renamed.  for example:
>
>     git tag push origin refs/tags/v0.0.3:refs/tags/v2.3.4
>
> However, for tags signed with any recent version of git, the tag name is
> also included in the signed material:
> ...
> But git tag doesn't verify that the internal name is the same as the
> external name (note that it still returns an exit code of zero):

That is all very much deliberate. A few additional things you may want to consider while assessing the proposal in your message are:

 * "git tag -v $(git rev-parse v1.0.0)" should work, but the command
   would not even see which ref the 40-hex object name it is
   verifying came from.  As "tag --verify" is about verifying the
   crypto signature over the data in the tag object, the lack of the
   information (and verification) is perfectly fine when "tag -v"
   does not begin with a refname but works from an object name.

   I.e. your proposal to additionally check the refname of a signed
   tag must be made optional, something like "only when a refname is
   given, teach 'tag -v' to additionally check that the refname
   matches the tagname".

 * There are movements to push tags you obtain from upstream to a
   somewhere not directly underneath refs/tags/.  Instead of your
   artificial "confuse users by calling 2.3.4 what in reality is a
   mere 0.0.3" example, what would more likely to happen in the real
   world is "we see v2.3.4 at the upstream repository; copy it at
   refs/tags/origin/v2.3.4 in our repository".  If you literally
   followed your proposal, your users will be hit with "You told me
   to verify origin/v2.3.4 but the data in the tag itself claims
   that it is v2.3.4 without 'origin/' prefix--this is an error".

   Perhaps checking only the tail-match is good enough?  It is when
   you consider only this example, but that is merely one example
   and is far from exhaustive.  Your proposal needs to be fine tuned
   after thinking these details through.

 * "git describe" knows that the path under refs/tags/ and the
   tagname could be different, so after you rename v2.20.0 to
   g2.20.0, you would see something like this:

   $ git checkout --detach v2.20.0
   $ git update-ref refs/tags/g2.20.0 refs/tags/v2.20.0
   $ git update-ref -d refs/tags/v2.20.0
   $ git describe
   warning: tag 'v2.20.0' is really 'g2.20.0' here
   v2.20.0

   in today's Git already.  Porting this warning logic (which is a
   dumb one that reports any non-exact match) to "tag -v" might be
   sufficient, as long as you do not make it an error.

We may want to teach "git fsck" to notice discrepancy between the tagname and the refname, but the same care needs to be taken to allow sensible renaming as the second point above.

Thanks.