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

[Tom Grennan <tmgrennan@gmail.com>]

Junio C Hamano <gitster@pobox.com<mailto:gitster@pobox.com>> writes:
>Tom Grennan <tom.grennan@ericsson.com<mailto:tom.grennan@ericsson.com>> writes:
>>
>>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