{"thread":{"id":"29539","subject":"[RFC/PATCH] verify-tag: check sig of all tags to given object","startedAt":"2012-02-04T01:25:51Z","lastAt":"2012-02-04T06:49:42Z","messageCount":8,"participants":["Tom Grennan","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"183792","messageId":"1328318751-4470-1-git-send-email-tom.grennan@ericsson.com","threadId":"29539","inReplyTo":null,"subject":"[RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Tom Grennan","fromEmail":"tom.grennan@ericsson.com","sentAt":"2012-02-04T01:25:51Z","receivedAt":"2012-02-04T01:25:51Z","isPatch":true,"sender":{"key":"tom.grennan@ericsson.com","avatar":null},"body":"If the command argument is a non-tag object, scan and verify all tags to\nthe given object; for example:\n\njohn$ git tag -s -m \"I approve\" john-README master:README\n...\njohn$ git tag -s -m \"I recommend\" john-HEAD HEAD\n...\njohn$ git push <url> tag john-README\njohn$ git push <url> tag john-HEAD\n\njane$ git fetch --tags <url>\njane$ git tag -s -m \"I also approve\" jane-README master:README\n...\njane$ git push <url> tag jane-README\n\njeff$ git fetch --tags <url>\njeff$ git verify-tag master:README\ntag john-README: OK\ntag jane-README: OK\njeff$ git verify-tag HEAD\ntag john-HEAD: OK\n\nSigned-off-by: Tom Grennan <tom.grennan@ericsson.com>\n---\n Documentation/git-verify-tag.txt |    6 +++-\n builtin/verify-tag.c             |   53 +++++++++++++++++++++++++++++++++++---\n 2 files changed, 53 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt\nindex 5ff76e8..ce47f95 100644\n--- a/Documentation/git-verify-tag.txt\n+++ b/Documentation/git-verify-tag.txt\n@@ -8,7 +8,7 @@ git-verify-tag - Check the GPG signature of tags\n SYNOPSIS\n --------\n [verse]\n-'git verify-tag' <tag>...\n+'git verify-tag' <object>...\n \n DESCRIPTION\n -----------\n@@ -20,8 +20,10 @@ OPTIONS\n --verbose::\n \tPrint the contents of the tag object before validating it.\n \n-<tag>...::\n+<object>...::\n \tSHA1 identifiers of git tag objects.\n+\tFor non-tag objects, scan and verify all tags to the given\n+\tobject.\n \n GIT\n ---\ndiff --git a/builtin/verify-tag.c b/builtin/verify-tag.c\nindex 28c2174..df9e93c 100644\n--- a/builtin/verify-tag.c\n+++ b/builtin/verify-tag.c\n@@ -7,6 +7,7 @@\n  */\n #include \"cache.h\"\n #include \"builtin.h\"\n+#include \"refs.h\"\n #include \"tag.h\"\n #include \"run-command.h\"\n #include <signal.h>\n@@ -14,7 +15,7 @@\n #include \"gpg-interface.h\"\n \n static const char * const verify_tag_usage[] = {\n-\t\t\"git verify-tag [-v|--verbose] <tag>...\",\n+\t\t\"git verify-tag [-v|--verbose] <object>...\",\n \t\tNULL\n };\n \n@@ -32,6 +33,46 @@ static int run_gpg_verify(const char *buf, unsigned long size, int verbose)\n \treturn verify_signed_buffer(buf, len, buf + len, size - len, NULL);\n }\n \n+struct obj_filter {\n+\tconst unsigned char *sha1;\n+\tint verbose;\n+\tstruct strbuf sb;\n+};\n+\n+static int verify_tag_of_obj(const char *refname, const unsigned char *sha1,\n+\t\t\t     int flag, void *cb_data)\n+{\n+\tstruct obj_filter *obj = cb_data;\n+\tenum object_type type;\n+\tunsigned long size;\n+\tint len, ret;\n+\tchar *buf = NULL;\n+\tunsigned char tagged_sha1[20];\n+\n+\tif ((type = sha1_object_info(sha1, NULL), type == OBJ_TAG) \\\n+\t    && (buf = read_sha1_file(sha1, &type, &size), buf) \\\n+\t    && !memcmp(\"object \", buf, 7) \\\n+\t    && !get_sha1_hex(buf + 7, tagged_sha1) \\\n+\t    && buf[47] == '\\n' \\\n+\t    && !memcmp(obj->sha1, tagged_sha1, 20) \\\n+\t    && (len = parse_signature(buf, size), len != size)) {\n+\t\tstrbuf_reset(&obj->sb);\n+\t\tret = verify_signed_buffer(buf, len, buf + len, size - len,\n+\t\t\t\t\t   &obj->sb);\n+\t\tif (obj->verbose) {\n+\t\t\twrite_in_full(1, buf, len);\n+\t\t\twrite_in_full(1, obj->sb.buf, obj->sb.len);\n+\t\t} else if (ret) {\n+\t\t\tprintf(\"tag %s: FAILED\\n\", refname);\n+\t\t\twrite_in_full(1, obj->sb.buf, obj->sb.len);\n+\t\t} else\n+\t\t\tprintf(\"tag %s: OK\\n\", refname);\n+\t}\n+\tif (buf)\n+\t\tfree(buf);\n+\treturn 0;\n+}\n+\n static int verify_tag(const char *name, int verbose)\n {\n \tenum object_type type;\n@@ -44,9 +85,13 @@ static int verify_tag(const char *name, int verbose)\n \t\treturn error(\"tag '%s' not found.\", name);\n \n \ttype = sha1_object_info(sha1, NULL);\n-\tif (type != OBJ_TAG)\n-\t\treturn error(\"%s: cannot verify a non-tag object of type %s.\",\n-\t\t\t\tname, typename(type));\n+\tif (type != OBJ_TAG) {\n+\t\tstruct obj_filter obj = { sha1, verbose };\n+\t\tstrbuf_init(&obj.sb, 4096);\n+\t\tfor_each_tag_ref(verify_tag_of_obj, (void *) &obj);\n+\t\tstrbuf_release(&obj.sb);\n+\t\treturn 0;\n+\t}\n \n \tbuf = read_sha1_file(sha1, &type, &size);\n \tif (!buf)\n-- \n1.7.9.dirty\n"},{"id":"183795","messageId":"7v8vkjl24d.fsf@alter.siamese.dyndns.org","threadId":"29539","inReplyTo":"1328318751-4470-1-git-send-email-tom.grennan@ericsson.com","subject":"Re: [RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-04T03:16:18Z","receivedAt":"2012-02-04T03:16:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tom Grennan <tom.grennan@ericsson.com> writes:\n\n> If the command argument is a non-tag object, scan and verify all tags to\n> the given object; for example:\n>\n> john$ git tag -s -m \"I approve\" john-README master:README\n> ...\n> john$ git tag -s -m \"I recommend\" john-HEAD HEAD\n> ...\n> john$ git push <url> tag john-README\n> john$ git push <url> tag john-HEAD\n>\n> jane$ git fetch --tags <url>\n> jane$ git tag -s -m \"I also approve\" jane-README master:README\n> ...\n> jane$ git push <url> tag jane-README\n>\n> jeff$ git fetch --tags <url>\n> jeff$ git verify-tag master:README\n> tag john-README: OK\n> tag jane-README: OK\n> jeff$ git verify-tag HEAD\n> tag john-HEAD: OK\n>\n> Signed-off-by: Tom Grennan <tom.grennan@ericsson.com>\n\nYou did not describe what problem you are trying to solve, but the above\ntells me that the design of this feature has a lot of room to be improved\nto be useful for even a single trivial use scenario I can think of off the\ntop of my head.\n\nLet's say after tagging v1.7.10, for some reason (as I do not know what\nproblem you are trying to solve), I decided to ask my back-up maintainers,\nlet's call them Shawn and Jeff, to sign that tag.  Shawn is expected to do\nthis:\n\n    spearce$ git fetch tag v1.7.10\n    spearce$ git tag -s -m \"This tag is Gitster's\" v1.7.10-spearce v1.7.10\n    spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce\n\nJeff will do the same, and I'll fetch v1.7.10-spearce and v1.7.10-peff\ntags from them.\n\nIt is natural for me to be able to ask \"I want to verify all tags that\npoint at the object I asked to be signed, namely, v1.7.10\" from this\nfeature.\n\nBut\n\n    gitster$ git verify-tag v1.7.10\n\nwould not be a way to do so, as that would check my signature in v1.7.10\ntag itself.\n\nIt gets even worse.  Suppose Jeff does this instead by mistake:\n\n    peff$ git fetch v1.7.10\n    peff$ git tag v1.7.10-peff v1.7.10\n    peff$ git push http://example.com/peff/git tags/v1.7.10-peff\n\nEven if you added \"git verify-tag --pointed v1.7.10\" to disambiguate the\nrequest to use the new feature, the result is unusable, as I would see:\n\n    gitster$ git verify-tag --pointed v1.7.10\n    v1.7.10-spearce: OK\n    v1.7.10-peff: OK\n\nv1.7.10-spearce and v1.7.10-peff both resolve to my v1.7.10, and they both\nare signed by known key, but v1.7.10-peff is a lightweight tag that points\ndirectly at my v1.7.10 and I would be seeing a signature of my own as \"OK\".\n"},{"id":"183799","messageId":"20120204050818.GA2477@tgrennan-laptop","threadId":"29539","inReplyTo":"D140688E-B86C-4A67-9AD6-56160C26884D@ericsson.com","subject":"Re: [RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Tom Grennan","fromEmail":"tmgrennan@gmail.com","sentAt":"2012-02-04T05:08:18Z","receivedAt":"2012-02-04T05:08:18Z","isPatch":true,"sender":{"key":"tmgrennan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/422771?v=4"},"body":"Junio C Hamano <gitster@pobox.com<mailto:gitster@pobox.com>> writes:\n>Tom Grennan <tom.grennan@ericsson.com<mailto:tom.grennan@ericsson.com>> writes:\n>>\n>>If the command argument is a non-tag object, scan and verify all tags to\n>>the given object; for example:\n>>\n>>john$ git tag -s -m \"I approve\" john-README master:README\n>>...\n>>john$ git tag -s -m \"I recommend\" john-HEAD HEAD\n>>...\n>>john$ git push <url> tag john-README\n>>john$ git push <url> tag john-HEAD\n>>\n>>jane$ git fetch --tags <url>\n>>jane$ git tag -s -m \"I also approve\" jane-README master:README\n>>...\n>>jane$ git push <url> tag jane-README\n>>\n>>jeff$ git fetch --tags <url>\n>>jeff$ git verify-tag master:README\n>>tag john-README: OK\n>>tag jane-README: OK\n>>jeff$ git verify-tag HEAD\n>>tag john-HEAD: OK\n>>\n>>Signed-off-by: Tom Grennan <tom.grennan@ericsson.com<mailto:tom.grennan@ericsson.com>>\n>\n>You did not describe what problem you are trying to solve, but the above\n>tells me that the design of this feature has a lot of room to be improved\n>to be useful for even a single trivial use scenario I can think of off the\n>top of my head.\n>\n>Let's say after tagging v1.7.10, for some reason (as I do not know what\n>problem you are trying to solve), I decided to ask my back-up maintainers,\n>let's call them Shawn and Jeff, to sign that tag.  Shawn is expected to do\n>this:\n>\n>   spearce$ git fetch tag v1.7.10\n>   spearce$ git tag -s -m \"This tag is Gitster's\" v1.7.10-spearce v1.7.10\n>   spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce\n>\n>Jeff will do the same, and I'll fetch v1.7.10-spearce and v1.7.10-peff\n>tags from them.\n>\n>It is natural for me to be able to ask \"I want to verify all tags that\n>point at the object I asked to be signed, namely, v1.7.10\" from this\n>feature.\n>\n>But\n>\n>   gitster$ git verify-tag v1.7.10\n>\n>would not be a way to do so, as that would check my signature in v1.7.10\n>tag itself.\n>\n>It gets even worse.  Suppose Jeff does this instead by mistake:\n>\n>   peff$ git fetch v1.7.10\n>   peff$ git tag v1.7.10-peff v1.7.10\n>   peff$ git push http://example.com/peff/git tags/v1.7.10-peff\n>\n>Even if you added \"git verify-tag --pointed v1.7.10\" to disambiguate the\n>request to use the new feature, the result is unusable, as I would see:\n>\n>   gitster$ git verify-tag --pointed v1.7.10\n>   v1.7.10-spearce: OK\n>   v1.7.10-peff: OK\n>\n>v1.7.10-spearce and v1.7.10-peff both resolve to my v1.7.10, and they both\n>are signed by known key, but v1.7.10-peff is a lightweight tag that points\n>directly at my v1.7.10 and I would be seeing a signature of my own as \"OK\".\n\nSorry for messing up this thread. I had remote access trouble with work.\n\nWouldn't you want Shawn and Jeff to tag the object (commit, tree, or\nblob) that you had tagged?\n\n   spearce$ git fetch tag v1.7.10\n   spearce$ eval $(git verify-tag -v v1.7.10 | sed -n '1s/ /=/p')\n   spearce$ git tag -s -m \"This tag is Gitster's\" v1.7.10-spearce $object\n   spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce\n\nOr,\n\n   spearce$ git fetch tag v1.7.10\n   spearce$ git tag -s -m \"This tag is Gitster's\" v1.7.10-spearce --pointed v1.7.10\n   spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce\n\nThen,\n\n   gitster$ git verify-tag $object\n   tag v1.7.10: OK\n   tag v1.7.10-spearce: OK\n\nOr,\n\n   gitster$ git verify-tag --pointed v1.7.10\n   tag v1.7.10: OK\n   tag v1.7.10-spearce: OK\n\nI hadn't thought of tagging a tag.  As you indicate, this would be\ntricky to disambiguate.\n\nSo, I intended this to verify all tags of the non-tag object that one\nasked to be signed; no sign, no record.\n\nBTW, it may also be convenient to use auto-generated tag names for the\nsecondary sign-offs, perhaps using the tag SHA as it's refs/tags/SHA.\n\n   spearce$ git tag -s -m \"This is Gitster's v1.7.10\" -- --pointed v1.7.10\n\n   peff$ git tag -s -m \"This is Gitster's v1.7.10\" -- --pointed v1.7.10\n\n   gitster$ git verify-tag --pointed v1.7.10\n   tag v1.7.10: OK\n   tag XXX....XXX: OK\n   tag YYY....YYY: OK\n\n`git tag -l` could then ignore refs/tags/SHA with content SHA.\n\n-- \nTomG\n"},{"id":"183800","messageId":"7vwr83jhzn.fsf@alter.siamese.dyndns.org","threadId":"29539","inReplyTo":"7v8vkjl24d.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-04T05:16:28Z","receivedAt":"2012-02-04T05:16:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> You did not describe what problem you are trying to solve, but the above\n> tells me that the design of this feature has a lot of room to be improved\n> to be useful for even a single trivial use scenario I can think of off the\n> top of my head.\n\nHaving said all that, the biggest problem I have with the approach of this\npatch is that it does not decompose the necessary functionalities in a way\nthat allows combinations of options people naturally would expect from the\ndescription of the feature.\n\n\"git tag\" can be used to create (-a), delete (-d), show (-l) and verify\n(-v).  Among these modes, creation has to work on a single tag, so it is a\nbit special. But the other three modes could also use the filtering\nfeature of what \"show\" supports among themselves.\n\nThe mode to show tags (-l) starts from _all_ tags, but limits the output\nto those that match given patterns, and the output can further be limited\nto the ones that contain a given commit. The verify mode and the delete\nmode do not offer this behaviour and require the user to specify exact tag\nnames. If you are adding \"I want to do X on all tags that point at this\nobject\" feature, in which X happens to be \"verification\" in your case,\ndon't you think other people would naturally want to use the feature with\nX=show instead?\n\nThe right first step to do this would be to enhance the \"filter\" logic so\nthat it not just lets \"--contains\", but also \"--points-at\", be specified.\nOnce that is done, you could just say:\n\n\t$ git tag -l --points-at master:README\n\nto list all the tags that point at the blob, and then your original\nexample becomes:\n\n\t$ git tag --points-at master:README | xargs git tag -v\n\nIt even allows something like this:\n\n\t$ git tag --points-at master:README 'v1.[0-4].?' |\n          xargs git tag -v\n\nto work on tags that point at the blob but only those whose names match\nthe given pattern, i.e. versions from v1.0 series up to v1.4 series but\nnot later.\n\nAfter that is done, you could teach the --verify mode to also accept the\npatterns, not exact names, so that the above could become:\n\n\t$ git tag --verify --points-at master:README\n        $ git tag --verify --points-at master:README 'v1.[0-4].?'\n\nTheoretically, the \"start from all and then filter\" feature could be\nshared also with \"delete\" mode, but I would not recommend doing so for\nsafety reasons (i.e. \"delete\" is destructive). Even so, if somebody does\nwant to do a bulk delete, it is just a simple matter of:\n\n\t$ git tag --points-at master:README 'v1.[0-4].?' |\n          xargs git tag -d\n\nSo it is not a big deal if you did not to teach --delete to share the\nfiltering logic with \"show\".\n\nFor exactly the same reason, --verify mode does not have to share the\nlogic, either. Not having to use \"| xargs\" is merely an icing on the cake.\n\nHmm?\n"},{"id":"183801","messageId":"7vsjirjhp7.fsf@alter.siamese.dyndns.org","threadId":"29539","inReplyTo":"20120204050818.GA2477@tgrennan-laptop","subject":"Re: [RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-04T05:22:44Z","receivedAt":"2012-02-04T05:22:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tom Grennan <tmgrennan@gmail.com> writes:\n\n> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or\n> blob) that you had tagged?\n\nNo.\n\nWe _designed_ our tag objects so that they are capable of pointing at\nanother tag, not the object that is pointed at that other tag.  And that\nis the example usage I gave you.\n\nThe statement by Shawn and Jeff, \"This tag is Gitster's\" is exactly that.\nIt was not about asserting the authenticity of the commit. It was about\nthe tag object I created.\n\n>    gitster$ git verify-tag --pointed v1.7.10\n>    tag v1.7.10: OK\n\nJust saying \"$name: OK\" will *never* be acceptable. \"A signature made by\nany key in my keychain is fine\" is not the usual use case. At least the\noutput needs to be \"Good signature from X\".\n"},{"id":"183803","messageId":"20120204055656.GC2477@tgrennan-laptop","threadId":"29539","inReplyTo":"7vsjirjhp7.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Tom Grennan","fromEmail":"tmgrennan@gmail.com","sentAt":"2012-02-04T05:56:56Z","receivedAt":"2012-02-04T05:56:56Z","isPatch":true,"sender":{"key":"tmgrennan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/422771?v=4"},"body":"On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:\n>Tom Grennan <tmgrennan@gmail.com> writes:\n>\n>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or\n>> blob) that you had tagged?\n>\n>No.\n>\n>We _designed_ our tag objects so that they are capable of pointing at\n>another tag, not the object that is pointed at that other tag.  And that\n>is the example usage I gave you.\n>\n>The statement by Shawn and Jeff, \"This tag is Gitster's\" is exactly that.\n>It was not about asserting the authenticity of the commit. It was about\n>the tag object I created.\n\nHmm, how about \"git verify-tag [[-v] [--to]] <tag|object>\"?\nWith \"--to\", all tags to the given tag (or object) are verified.\nWithout \"--to\" just the given <tag> is verified.\n\n>>    gitster$ git verify-tag --pointed v1.7.10\n>>    tag v1.7.10: OK\n>\n>Just saying \"$name: OK\" will *never* be acceptable. \"A signature made by\n>any key in my keychain is fine\" is not the usual use case. At least the\n>output needs to be \"Good signature from X\".\n\nOK, I'll have to play with the gpg --verify-options.\n\n-- \nTomG\n"},{"id":"183805","messageId":"7vhaz7jf1d.fsf@alter.siamese.dyndns.org","threadId":"29539","inReplyTo":"20120204055656.GC2477@tgrennan-laptop","subject":"Re: [RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-04T06:20:14Z","receivedAt":"2012-02-04T06:20:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tom Grennan <tmgrennan@gmail.com> writes:\n\n> On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:\n>>Tom Grennan <tmgrennan@gmail.com> writes:\n>>\n>>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or\n>>> blob) that you had tagged?\n>>\n>>No.\n>>\n>>We _designed_ our tag objects so that they are capable of pointing at\n>>another tag, not the object that is pointed at that other tag.  And that\n>>is the example usage I gave you.\n>>\n>>The statement by Shawn and Jeff, \"This tag is Gitster's\" is exactly that.\n>>It was not about asserting the authenticity of the commit. It was about\n>>the tag object I created.\n>\n> Hmm, how about \"git verify-tag [[-v] [--to]] <tag|object>\"?\n> With \"--to\", all tags to the given tag (or object) are verified.\n> Without \"--to\" just the given <tag> is verified.\n>\n>>>    gitster$ git verify-tag --pointed v1.7.10\n>>>    tag v1.7.10: OK\n>>\n>>Just saying \"$name: OK\" will *never* be acceptable. \"A signature made by\n>>any key in my keychain is fine\" is not the usual use case. At least the\n>>output needs to be \"Good signature from X\".\n>\n> OK, I'll have to play with the gpg --verify-options.\n\nIf it wasn't clear enough from my other message, I would rather not to see\nany change to --verify codepath as the first step.  Don't you think that\nthe simplest and cleanest first step is to add --points-at to the list\nmode, so that with help from \"| xargs git tag -v\" you can bulk-verify\nwithout any other change?\n"},{"id":"183809","messageId":"20120204064942.GD2477@tgrennan-laptop","threadId":"29539","inReplyTo":"7vhaz7jf1d.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] verify-tag: check sig of all tags to given object","fromName":"Tom Grennan","fromEmail":"tmgrennan@gmail.com","sentAt":"2012-02-04T06:49:42Z","receivedAt":"2012-02-04T06:49:42Z","isPatch":true,"sender":{"key":"tmgrennan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/422771?v=4"},"body":"On Fri, Feb 03, 2012 at 10:20:14PM -0800, Junio C Hamano wrote:\n>Tom Grennan <tmgrennan@gmail.com> writes:\n>\n>> On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:\n>>>Tom Grennan <tmgrennan@gmail.com> writes:\n>>>\n>>>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or\n>>>> blob) that you had tagged?\n>>>\n>>>No.\n>>>\n>>>We _designed_ our tag objects so that they are capable of pointing at\n>>>another tag, not the object that is pointed at that other tag.  And that\n>>>is the example usage I gave you.\n>>>\n>>>The statement by Shawn and Jeff, \"This tag is Gitster's\" is exactly that.\n>>>It was not about asserting the authenticity of the commit. It was about\n>>>the tag object I created.\n>>\n>> Hmm, how about \"git verify-tag [[-v] [--to]] <tag|object>\"?\n>> With \"--to\", all tags to the given tag (or object) are verified.\n>> Without \"--to\" just the given <tag> is verified.\n>>\n>>>>    gitster$ git verify-tag --pointed v1.7.10\n>>>>    tag v1.7.10: OK\n>>>\n>>>Just saying \"$name: OK\" will *never* be acceptable. \"A signature made by\n>>>any key in my keychain is fine\" is not the usual use case. At least the\n>>>output needs to be \"Good signature from X\".\n>>\n>> OK, I'll have to play with the gpg --verify-options.\n>\n>If it wasn't clear enough from my other message, I would rather not to see\n>any change to --verify codepath as the first step.  Don't you think that\n>the simplest and cleanest first step is to add --points-at to the list\n>mode, so that with help from \"| xargs git tag -v\" you can bulk-verify\n>without any other change?\n\nNo, I missed that. So you're suggesting,\ngit tag [-n[<num>]] -l [--contains <commit>] [--points-at <object>] [<pattern>...]\n\nIf so, I'll look into it tomorrow.\n\nthanks,\nTomG\n"}]}