Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> writes: > 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.
