{"thread":{"id":"50927","subject":"[RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","startedAt":"2019-04-12T20:14:44Z","lastAt":"2019-04-23T02:13:16Z","messageCount":9,"participants":["santiago@nyu.edu","Santiago Torres Arias","Jeff King","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"373763","messageId":"20190412201432.11328-1-santiago@nyu.edu","threadId":"50927","inReplyTo":null,"subject":"[RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"","fromEmail":"santiago@nyu.edu","sentAt":"2019-04-12T20:14:32Z","receivedAt":"2019-04-12T20:14:44Z","isPatch":true,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"From: Santiago Torres \n\nOn the git tag -v code, there is a guard to suppress gpg output if a\npretty format is provided. The rationale for this is that the gpg output\n*and* the pretty formats together may conflict with each other. However,\nboth outputs are directed to different output streams and, as such,\nthey can safely coexist. Drop the guard clause and use\nGPG_VERIFY_VERBOSE regardless of the pretty format\n\nSigned-off-by: Santiago Torres \n---\n builtin/tag.c | 3 ---\n 1 file changed, 3 deletions(-)\n\ndiff --git a/builtin/tag.c b/builtin/tag.c\nindex 8c493a569..4b91c769c 100644\n--- a/builtin/tag.c\n+++ b/builtin/tag.c\n@@ -110,9 +110,6 @@ static int verify_tag(const char *name, const char *ref,\n \tconst struct ref_format *format = cb_data;\n \tflags = GPG_VERIFY_VERBOSE;\n \n-\tif (format->format)\n-\t\tflags = GPG_VERIFY_OMIT_STATUS;\n-\n \tif (gpg_verify_tag(oid, name, flags))\n \t\treturn -1;\n \n-- \n2.21.0\n\n"},{"id":"373764","messageId":"20190412201609.hivppg2l37b6pzze@LykOS.localdomain","threadId":"50927","inReplyTo":"20190412201432.11328-1-santiago@nyu.edu","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-04-12T20:16:10Z","receivedAt":"2019-04-12T20:16:20Z","isPatch":true,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"On Fri, Apr 12, 2019 at 04:14:32PM -0400, santiago@nyu.edu wrote:\n> From: Santiago Torres \n> \n> On the git tag -v code, there is a guard to suppress gpg output if a\n> pretty format is provided. The rationale for this is that the gpg output\n> *and* the pretty formats together may conflict with each other. However,\n> both outputs are directed to different output streams and, as such,\n> they can safely coexist. Drop the guard clause and use\n> GPG_VERIFY_VERBOSE regardless of the pretty format\n\nI tried digging for the rationale for this, but I couldn't figure it\nout. I noticed that the output of gpg verification is sent to stderr,\nwhile the pretty format goes towards stdout, and they can thus be\nmultiplexed accordingly.\n\nWhat do you guys think?\n\nThanks!\n-Santiago.\n"},{"id":"374246","messageId":"20190422152726.GB1633@sigill.intra.peff.net","threadId":"50927","inReplyTo":"20190412201432.11328-1-santiago@nyu.edu","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-04-22T15:27:26Z","receivedAt":"2019-04-22T15:27:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 12, 2019 at 04:14:32PM -0400, santiago@nyu.edu wrote:\n\n> From: Santiago Torres \n> \n> On the git tag -v code, there is a guard to suppress gpg output if a\n> pretty format is provided. The rationale for this is that the gpg output\n> *and* the pretty formats together may conflict with each other. However,\n> both outputs are directed to different output streams and, as such,\n> they can safely coexist. Drop the guard clause and use\n> GPG_VERIFY_VERBOSE regardless of the pretty format\n\nI think this makes sense. My first worry was whether this would be\nsurprising to any callers, but as you note, they go to different\nstreams.\n\nHowever, I don't think this patch is quite right, as it causes us to\ndump the whole tag contents to stdout, as well. E.g.:\n\n [before]\n $ git tag -v --format='foo %(tag)' v2.21.0\n foo v2.21.0\n\n [after]\n $ git tag -v --format='foo %(tag)' v2.21.0\n object 8104ec994ea3849a968b4667d072fedd1e688642\n type commit\n tag v2.21.0\n tagger Junio C Hamano 1551023739 -0800\n \n Git 2.21\n gpg: Signature made Sun Feb 24 10:55:39 2019 EST\n gpg: using RSA key E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB\n gpg: Good signature from \"Junio C Hamano \" [full]\n gpg: aka \"Junio C Hamano \" [full]\n gpg: aka \"Junio C Hamano \" [full]\n foo v2.21.0\n\nI think \"git verify-tag\" would need similar treatment, too:\n\n $ git verify-tag v2.21.0\n gpg: Signature made Sun Feb 24 10:55:39 2019 EST\n gpg: using RSA key E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB\n gpg: Good signature from \"Junio C Hamano \" [full]\n gpg: aka \"Junio C Hamano \" [full]\n gpg: aka \"Junio C Hamano \" [full]\n\n $ git verify-tag --format='foo %(tag)' v2.21.0\n foo v2.21.0\n\nIn some ways I'm less concerned about verify-tag, though, because the\npoint is that it should be scriptable. And scraping gpg's stderr is not\nideal there. We should be parsing --status-fd ourselves and making the\nresult available via format specifier, similar to the way \"log\n--format=%G?\" works.\n\nSo I think ultimately that's the direction we want to go, but I think\nin the meantime restoring the gpg output to stderr especially for the\nporcelain \"git tag -v\" makes sense for human eyes.\n\n-Peff\n"},{"id":"374248","messageId":"20190422154655.sxyrkee7rnywoh2w@LykOS.localdomain","threadId":"50927","inReplyTo":"20190422152726.GB1633@sigill.intra.peff.net","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-04-22T15:46:56Z","receivedAt":"2019-04-22T15:47:02Z","isPatch":true,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"> However, I don't think this patch is quite right, as it causes us to\n> dump the whole tag contents to stdout, as well. E.g.:\n> \n> [before]\n> $ git tag -v --format='foo %(tag)' v2.21.0\n> foo v2.21.0\n> \n> [after]\n> $ git tag -v --format='foo %(tag)' v2.21.0\n> object 8104ec994ea3849a968b4667d072fedd1e688642\n> type commit\n> tag v2.21.0\n> tagger Junio C Hamano 1551023739 -0800\n> \n> Git 2.21\n> gpg: Signature made Sun Feb 24 10:55:39 2019 EST\n> gpg: using RSA key E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB\n> gpg: Good signature from \"Junio C Hamano \" [full]\n> gpg: aka \"Junio C Hamano \" [full]\n> gpg: aka \"Junio C Hamano \" [full]\n> foo v2.21.0\n> \n> I think \"git verify-tag\" would need similar treatment, too:\n> \n> $ git verify-tag v2.21.0\n> gpg: Signature made Sun Feb 24 10:55:39 2019 EST\n> gpg: using RSA key E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB\n> gpg: Good signature from \"Junio C Hamano \" [full]\n> gpg: aka \"Junio C Hamano \" [full]\n> gpg: aka \"Junio C Hamano \" [full]\n> \n> $ git verify-tag --format='foo %(tag)' v2.21.0\n> foo v2.21.0\n> \n\nAh, let me look into these issues. I'm almost sure I also need to review\nthe test suite and adapt it to this behavior.\n\n> In some ways I'm less concerned about verify-tag, though, because the\n> point is that it should be scriptable. And scraping gpg's stderr is not\n> ideal there. We should be parsing --status-fd ourselves and making the\n> result available via format specifier, similar to the way \"log\n> --format=%G?\" works.\n\nI think that would be great, as we could make it simpler for verifiers\nto parse gpg output.\n\n> So I think ultimately that's the direction we want to go, but I think\n> in the meantime restoring the gpg output to stderr especially for the\n> porcelain \"git tag -v\" makes sense for human eyes.\n\nGreat! let me re-roll and make a more formal take on this.\n\nThanks!\n-Santiago\n"},{"id":"374251","messageId":"20190422160211.GB9680@sigill.intra.peff.net","threadId":"50927","inReplyTo":"20190422154655.sxyrkee7rnywoh2w@LykOS.localdomain","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-04-22T16:02:11Z","receivedAt":"2019-04-22T16:02:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:\n\n> > In some ways I'm less concerned about verify-tag, though, because the\n> > point is that it should be scriptable. And scraping gpg's stderr is not\n> > ideal there. We should be parsing --status-fd ourselves and making the\n> > result available via format specifier, similar to the way \"log\n> > --format=%G?\" works.\n> \n> I think that would be great, as we could make it simpler for verifiers\n> to parse gpg output.\n\nAlternatively, we could make it an option to dump the --status-fd output\nto stderr (or to a custom fd). That still leaves the caller with the\nresponsibility to parse gpg's output, but at least they're parsing the\nmachine-readable bits and not the regular human-readable stderr.\n\n-Peff\n"},{"id":"374277","messageId":"20190422230701.GD6316@genre.crustytoothpaste.net","threadId":"50927","inReplyTo":"20190422160211.GB9680@sigill.intra.peff.net","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-04-22T23:07:01Z","receivedAt":"2019-04-22T23:07:11Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:\n> On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:\n> \n> > > In some ways I'm less concerned about verify-tag, though, because the\n> > > point is that it should be scriptable. And scraping gpg's stderr is not\n> > > ideal there. We should be parsing --status-fd ourselves and making the\n> > > result available via format specifier, similar to the way \"log\n> > > --format=%G?\" works.\n> > \n> > I think that would be great, as we could make it simpler for verifiers\n> > to parse gpg output.\n> \n> Alternatively, we could make it an option to dump the --status-fd output\n> to stderr (or to a custom fd). That still leaves the caller with the\n> responsibility to parse gpg's output, but at least they're parsing the\n> machine-readable bits and not the regular human-readable stderr.\n\nDon't we already have that for verify-tag and verify-commit? I recall\nadding \"--raw\" for that very reason:\n\ngenre ok % git verify-tag --raw v2.21.0\n[GNUPG:] NEWSIG\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] SIG_ID NZHib/GfN4TzXBhuI9ABwYXqluE 2019-02-24 1551023739\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] EXPKEYSIG B0B5E88696AFE6CB Junio C Hamano \n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] VALIDSIG E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB 2019-02-24 1551023739 0 4 0 1 8 00 96E07AF25771955980DAD10020D04E5A713660A7\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] KEYEXPIRED 1442879137\n[GNUPG:] KEYEXPIRED 1505842336\n[GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n[GNUPG:] TOFU_USER 96E07AF25771955980DAD10020D04E5A713660A7 gitster@pobox.com\n[GNUPG:] TOFU_STATS 2 1 0 auto 1555974073 1555974073 0 0 2 1 0\n[GNUPG:] TOFU_STATS_LONG gitster@pobox.com: Verified 1~signature in the past 0~seconds. Encrypted%0A0 messages.\n[GNUPG:] TOFU_USER 96E07AF25771955980DAD10020D04E5A713660A7 jch@google.com\n[GNUPG:] TOFU_STATS 2 1 0 auto 1555974073 1555974073 0 0 2 1 0\n[GNUPG:] TOFU_STATS_LONG jch@google.com: Verified 1~signature in the past 0~seconds. Encrypted 0%0Amessages.\n[GNUPG:] TOFU_USER 96E07AF25771955980DAD10020D04E5A713660A7 junio@pobox.com\n[GNUPG:] TOFU_STATS 2 1 0 auto 1555974073 1555974073 0 0 2 1 0\n[GNUPG:] TOFU_STATS_LONG junio@pobox.com: Verified 1~signature in the past 0~seconds. Encrypted%0A0 messages.\n[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23\n\nThe idea was that users might want to restrict signatures to using\nsubkeys or certain algorithms or what-have-you, and this was the easiest\nway to let people have all of that power.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"374278","messageId":"20190422232627.3mw3rejbjp5tb7zy@LykOS.localdomain","threadId":"50927","inReplyTo":"20190422230701.GD6316@genre.crustytoothpaste.net","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-04-22T23:26:29Z","receivedAt":"2019-04-22T23:26:37Z","isPatch":true,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"On Mon, Apr 22, 2019 at 11:07:01PM +0000, brian m. carlson wrote:\n> On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:\n> > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:\n> > \n> > > I think that would be great, as we could make it simpler for verifiers\n> > > to parse gpg output.\n> > \n> > Alternatively, we could make it an option to dump the --status-fd output\n> > to stderr (or to a custom fd). That still leaves the caller with the\n> > responsibility to parse gpg's output, but at least they're parsing the\n> > machine-readable bits and not the regular human-readable stderr.\n> \n> Don't we already have that for verify-tag and verify-commit? I recall\n> adding \"--raw\" for that very reason:\n> \n> genre ok % git verify-tag --raw v2.21.0\n> [GNUPG:] NEWSIG\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] SIG_ID NZHib/GfN4TzXBhuI9ABwYXqluE 2019-02-24 1551023739\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] EXPKEYSIG B0B5E88696AFE6CB Junio C Hamano \n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] VALIDSIG E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB 2019-02-24 1551023739 0 4 0 1 8 00 96E07AF25771955980DAD10020D04E5A713660A7\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] KEYEXPIRED 1442879137\n> [GNUPG:] KEYEXPIRED 1505842336\n> [GNUPG:] KEY_CONSIDERED 96E07AF25771955980DAD10020D04E5A713660A7 0\n> [GNUPG:] TOFU_USER 96E07AF25771955980DAD10020D04E5A713660A7 gitster@pobox.com\n> [GNUPG:] TOFU_STATS 2 1 0 auto 1555974073 1555974073 0 0 2 1 0\n> [GNUPG:] TOFU_STATS_LONG gitster@pobox.com: Verified 1~signature in the past 0~seconds. Encrypted%0A0 messages.\n> [GNUPG:] TOFU_USER 96E07AF25771955980DAD10020D04E5A713660A7 jch@google.com\n> [GNUPG:] TOFU_STATS 2 1 0 auto 1555974073 1555974073 0 0 2 1 0\n> [GNUPG:] TOFU_STATS_LONG jch@google.com: Verified 1~signature in the past 0~seconds. Encrypted 0%0Amessages.\n> [GNUPG:] TOFU_USER 96E07AF25771955980DAD10020D04E5A713660A7 junio@pobox.com\n> [GNUPG:] TOFU_STATS 2 1 0 auto 1555974073 1555974073 0 0 2 1 0\n> [GNUPG:] TOFU_STATS_LONG junio@pobox.com: Verified 1~signature in the past 0~seconds. Encrypted%0A0 messages.\n> [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23\n\nI think this interface only shows you raw gpg output, but not any\n--format= specifiers that you may want. The idea would be to support\nboth. Or am I missing something?\n\nThanks,\n-Santiago.\n"},{"id":"374279","messageId":"20190423000026.GE6316@genre.crustytoothpaste.net","threadId":"50927","inReplyTo":"20190422232627.3mw3rejbjp5tb7zy@LykOS.localdomain","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-04-23T00:00:26Z","receivedAt":"2019-04-23T00:00:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Apr 22, 2019 at 07:26:29PM -0400, Santiago Torres Arias wrote:\n> On Mon, Apr 22, 2019 at 11:07:01PM +0000, brian m. carlson wrote:\n> > On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:\n> > > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:\n> > > \n> > > > I think that would be great, as we could make it simpler for verifiers\n> > > > to parse gpg output.\n> > > \n> > > Alternatively, we could make it an option to dump the --status-fd output\n> > > to stderr (or to a custom fd). That still leaves the caller with the\n> > > responsibility to parse gpg's output, but at least they're parsing the\n> > > machine-readable bits and not the regular human-readable stderr.\n> > \n> > Don't we already have that for verify-tag and verify-commit? I recall\n> > adding \"--raw\" for that very reason:\n> \n> I think this interface only shows you raw gpg output, but not any\n> --format= specifiers that you may want. The idea would be to support\n> both. Or am I missing something?\n\nMy response was mostly in reply to Peff's suggestion that we have an\noption to dump the --status-fd output, which we have. I think that\nbehavior properly belongs to verify-tag and verify-commit, which are\nplumbing.\n\nI'm not so sure that it's necessary to have the --status-fd output in git\ntag -v, which is more for interactive use, although I don't feel\nstrongly about it. I think of --format as a tool I typically want to use\non multiple of something, and while it's theoretically possible to\ndistinguish multiple signatures by GnuPG's \"NEWSIG\", parsing multiple\ntags' worth of output between standard output and standard error is\ngoing to be pretty unpleasant.\n\nAs I said, I don't feel strongly about it, so if you want to implement\nit, feel free.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"374286","messageId":"20190423021312.GC16369@sigill.intra.peff.net","threadId":"50927","inReplyTo":"20190422230701.GD6316@genre.crustytoothpaste.net","subject":"Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-04-23T02:13:12Z","receivedAt":"2019-04-23T02:13:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 22, 2019 at 11:07:01PM +0000, brian m. carlson wrote:\n\n> On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:\n> > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:\n> > \n> > > > In some ways I'm less concerned about verify-tag, though, because the\n> > > > point is that it should be scriptable. And scraping gpg's stderr is not\n> > > > ideal there. We should be parsing --status-fd ourselves and making the\n> > > > result available via format specifier, similar to the way \"log\n> > > > --format=%G?\" works.\n> > > \n> > > I think that would be great, as we could make it simpler for verifiers\n> > > to parse gpg output.\n> > \n> > Alternatively, we could make it an option to dump the --status-fd output\n> > to stderr (or to a custom fd). That still leaves the caller with the\n> > responsibility to parse gpg's output, but at least they're parsing the\n> > machine-readable bits and not the regular human-readable stderr.\n> \n> Don't we already have that for verify-tag and verify-commit? I recall\n> adding \"--raw\" for that very reason:\n\nHeh. Today I learned about \"--raw\". :)\n\nThanks for pointing it out. I do still think it would be nice for some\ncases to have --format specifiers to get the basic info, but I am glad\nthat we already have a reasonable method that scripts can use.\n\nIt might make sense to make it available from the git-tag porcelain,\ntoo, but since the point is scripting, I'm not sure it's all that\nimportant.\n\nIt looks like using \"--format\" suppresses it, too, which we'd probably\nwant to fix (presumably it's the same as the fix for the non-raw\noutput).\n\n> The idea was that users might want to restrict signatures to using\n> subkeys or certain algorithms or what-have-you, and this was the easiest\n> way to let people have all of that power.\n\nYeah, that makes perfect sense.\n\n-Peff\n"}]}