{"thread":{"id":"43865","subject":"[PATCH] Prefer \"long\" key format output when verifying pgp signatures","startedAt":"2016-08-16T20:35:55Z","lastAt":"2016-08-16T22:15:14Z","messageCount":2,"participants":["Linus Torvalds","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"299505","messageId":"alpine.LFD.2.20.1608161309350.14878@i7","threadId":"43865","inReplyTo":null,"subject":"[PATCH] Prefer \"long\" key format output when verifying pgp signatures","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2016-08-16T20:35:46Z","receivedAt":"2016-08-16T20:35:55Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nFrom: Linus Torvalds <torvalds@linux-foundation.org>\nDate: Tue, 16 Aug 2016 13:10:24 -0700\nSubject: [PATCH] Prefer \"long\" key format output when verifying pgp signatures\n\nYes, gpg2 already uses the long format by default, but most\ndistributions seem to still have \"gpg\" be the older 1.x version due to\ncompatibility reasons.  And older versions of gpg only show the 32-bit\nshort ID, which is quite insecure.\n\nThis doesn't actually matter for the _verification_ itself: if the\nverification passes, the pgp signature is good.  But if you don't\nactually have the key yet, and want to fetch it, or you want to check\nexactly which key was used for verification and want to check it, we\nshould specify the key with more precision.\n\nIn fact, we should preferentially specify the whole key fingerprint, but \ngpg doesn't actually support that.  Which is really quite sad.\n\nShowing the \"long\" format improves things to at least show 64 bits of\nthe fingerprint.  That's a lot better, even if it's not perfect.\n\nThis change the log format for \"git log --show-signature\" from\n\n    commit 2376d31787760af598db23bb3982a57419854e5c\n    merged tag 'v2.9.3'\n    gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT using RSA key ID 96AFE6CB\n    gpg: Good signature from \"Junio C Hamano <gitster@pobox.com>\"\n    gpg:                 aka \"Junio C Hamano <jch@google.com>\"\n    gpg:                 aka \"Junio C Hamano <junio@pobox.com>\"\n    Merge: 2807cd7b25af e0c1ceafc5be\n    Author: Junio C Hamano <gitster@pobox.com>\n    Date:   Fri Aug 12 10:02:18 2016 -0700\n\nto\n\n    commit 2376d31787760af598db23bb3982a57419854e5c\n    merged tag 'v2.9.3'\n    gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT\n    gpg:                using RSA key B0B5E88696AFE6CB\n    gpg: Good signature from \"Junio C Hamano <gitster@pobox.com>\"\n    gpg:                 aka \"Junio C Hamano <jch@google.com>\"\n    gpg:                 aka \"Junio C Hamano <junio@pobox.com>\"\n    Merge: 2807cd7b25af e0c1ceafc5be\n    Author: Junio C Hamano <gitster@pobox.com>\n    Date:   Fri Aug 12 10:02:18 2016 -0700\n\n(note the longer key ID, but also the reflowing of the text) and also \nchanges the format in the merge messages when merging a signed \ntag.\n\nIf you already use gpg2 (either because it's installed by default, or \nbecause you have set your gpg_program configuration to point to gpg2), \nthat already used the long format, you'll also see a change: it will now \nhave the same formatting as gpg 1.x, and the verification string looks \nsomething like\n\n    gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT\n    gpg:                using RSA key 79BE3E4300411886\n    gpg: Good signature from \"Linus Torvalds <torvalds@linux-foundation.org>\" [ultimate]\n\nwhere it used to be on one line:\n\n    gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT using RSA key ID 79BE3E4300411886\n    gpg: Good signature from \"Linus Torvalds <torvalds@linux-foundation.org>\" [ultimate]\n\nso there is certainly a chance this could break some automated scripting.  \nBut the 32-bit key ID's really are broken. Also note that because of the \ndifferences between gpg-1.x and gpg-2.x, hopefully any scripted key ID \nparsing code (if such code exists) is already flexible enough to not care.\n\nThis was triggered by the fact that the \"evil32\" project keys ended up\nleaking to the public key servers, so now there are 32-bit aliases for\njust about every open source developer that you can easily get by\nmistake if you use the 32-bit short ID format.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n\nThat's a very long commit message for a very trivial patch.\n\nI'm not particularly happy with the 64-bit long format either, but it's \nbetter than what we have now, and appears to be as good as it gets.\n\n gpg-interface.c | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/gpg-interface.c b/gpg-interface.c\nindex 08356f92e7b3..8672edaf4823 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -217,6 +217,7 @@ int verify_signed_buffer(const char *payload, size_t payload_size,\n \targv_array_pushl(&gpg.args,\n \t\t\t gpg_program,\n \t\t\t \"--status-fd=1\",\n+\t\t\t \"--keyid-format=long\",\n \t\t\t \"--verify\", temp.filename.buf, \"-\",\n \t\t\t NULL);\n \n-- \n2.10.0.rc0.dirty\n\n"},{"id":"299521","messageId":"xmqqinv0bc2j.fsf@gitster.mtv.corp.google.com","threadId":"43865","inReplyTo":"alpine.LFD.2.20.1608161309350.14878@i7","subject":"Re: [PATCH] Prefer \"long\" key format output when verifying pgp signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-16T22:09:40Z","receivedAt":"2016-08-16T22:15:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> From: Linus Torvalds <torvalds@linux-foundation.org>\n> Date: Tue, 16 Aug 2016 13:10:24 -0700\n> Subject: [PATCH] Prefer \"long\" key format output when verifying pgp signatures\n>\n> Yes, gpg2 already uses the long format by default, but most\n> distributions seem to still have \"gpg\" be the older 1.x version due to\n> compatibility reasons.  And older versions of gpg only show the 32-bit\n> short ID, which is quite insecure.\n> ...\n> But the 32-bit key ID's really are broken. Also note that because of the \n> differences between gpg-1.x and gpg-2.x, hopefully any scripted key ID \n> parsing code (if such code exists) is already flexible enough to not care.\n>\n> This was triggered by the fact that the \"evil32\" project keys ended up\n> leaking to the public key servers, so now there are 32-bit aliases for\n> just about every open source developer that you can easily get by\n> mistake if you use the 32-bit short ID format.\n>\n> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n> ---\n>\n> That's a very long commit message for a very trivial patch.\n>\n> I'm not particularly happy with the 64-bit long format either, but it's \n> better than what we have now, and appears to be as good as it gets.\n\nThanks.  Will queue.\n\n>\n>  gpg-interface.c | 1 +\n>  1 file changed, 1 insertion(+)\n>\n> diff --git a/gpg-interface.c b/gpg-interface.c\n> index 08356f92e7b3..8672edaf4823 100644\n> --- a/gpg-interface.c\n> +++ b/gpg-interface.c\n> @@ -217,6 +217,7 @@ int verify_signed_buffer(const char *payload, size_t payload_size,\n>  \targv_array_pushl(&gpg.args,\n>  \t\t\t gpg_program,\n>  \t\t\t \"--status-fd=1\",\n> +\t\t\t \"--keyid-format=long\",\n>  \t\t\t \"--verify\", temp.filename.buf, \"-\",\n>  \t\t\t NULL);\n"}]}