Re: [RFC/PATCH] verify-tag: check sig of all tags to given object

Junio C Hamano <gitster@pobox.com<mailto:gitster@pobox.com>> writes:

Tom Grennan <tom.grennan@ericsson.com<mailto:tom.grennan@ericsson.com>> writes:

quoted

If the command argument is a non-tag object, scan and verify all tags to
the given object; for example:

john$ git tag -s -m "I approve" john-README master:README
...
john$ git tag -s -m "I recommend" john-HEAD HEAD
...
john$ git push <url> tag john-README
john$ git push <url> tag john-HEAD

jane$ git fetch --tags <url>
jane$ git tag -s -m "I also approve" jane-README master:README
...
jane$ git push <url> tag jane-README

jeff$ git fetch --tags <url>
jeff$ git verify-tag master:README
tag john-README: OK
tag jane-README: OK
jeff$ git verify-tag HEAD
tag john-HEAD: OK

Signed-off-by: Tom Grennan <tom.grennan@ericsson.com<mailto:tom.grennan@ericsson.com>>

You did not describe what problem you are trying to solve, but the above
tells me that the design of this feature has a lot of room to be improved
to be useful for even a single trivial use scenario I can think of off the
top of my head.

Let's say after tagging v1.7.10, for some reason (as I do not know what
problem you are trying to solve), I decided to ask my back-up maintainers,
let's call them Shawn and Jeff, to sign that tag.  Shawn is expected to do
this:

  spearce$ git fetch tag v1.7.10
  spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce v1.7.10
  spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce

Jeff will do the same, and I'll fetch v1.7.10-spearce and v1.7.10-peff
tags from them.

It is natural for me to be able to ask "I want to verify all tags that
point at the object I asked to be signed, namely, v1.7.10" from this
feature.

But

  gitster$ git verify-tag v1.7.10

would not be a way to do so, as that would check my signature in v1.7.10
tag itself.

It gets even worse.  Suppose Jeff does this instead by mistake:

  peff$ git fetch v1.7.10
  peff$ git tag v1.7.10-peff v1.7.10
  peff$ git push http://example.com/peff/git tags/v1.7.10-peff

Even if you added "git verify-tag --pointed v1.7.10" to disambiguate the
request to use the new feature, the result is unusable, as I would see:

  gitster$ git verify-tag --pointed v1.7.10
  v1.7.10-spearce: OK
  v1.7.10-peff: OK

v1.7.10-spearce and v1.7.10-peff both resolve to my v1.7.10, and they both
are signed by known key, but v1.7.10-peff is a lightweight tag that points
directly at my v1.7.10 and I would be seeing a signature of my own as "OK".

Sorry for messing up this thread. I had remote access trouble with work.

Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
blob) that you had tagged?

   spearce$ git fetch tag v1.7.10
   spearce$ eval $(git verify-tag -v v1.7.10 | sed -n '1s/ /=/p')
   spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce $object
   spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce

Or,

   spearce$ git fetch tag v1.7.10
   spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce --pointed v1.7.10
   spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce

Then,

   gitster$ git verify-tag $object
   tag v1.7.10: OK
   tag v1.7.10-spearce: OK

Or,

   gitster$ git verify-tag --pointed v1.7.10
   tag v1.7.10: OK
   tag v1.7.10-spearce: OK

I hadn't thought of tagging a tag.  As you indicate, this would be
tricky to disambiguate.

So, I intended this to verify all tags of the non-tag object that one
asked to be signed; no sign, no record.

BTW, it may also be convenient to use auto-generated tag names for the
secondary sign-offs, perhaps using the tag SHA as it's refs/tags/SHA.

   spearce$ git tag -s -m "This is Gitster's v1.7.10" -- --pointed v1.7.10

   peff$ git tag -s -m "This is Gitster's v1.7.10" -- --pointed v1.7.10

   gitster$ git verify-tag --pointed v1.7.10
   tag v1.7.10: OK
   tag XXX....XXX: OK
   tag YYY....YYY: OK

`git tag -l` could then ignore refs/tags/SHA with content SHA.

-- 
TomG