gpg-interface: prefer "long" key format output when verifying pgp signatures

Yes, gpg2 already uses the long format by default, but most
distributions seem to still have "gpg" be the older 1.x version due to
compatibility reasons.  And older versions of gpg only show the 32-bit
short ID, which is quite insecure.

This doesn't actually matter for the _verification_ itself: if the
verification passes, the pgp signature is good.  But if you don't
actually have the key yet, and want to fetch it, or you want to check
exactly which key was used for verification and want to check it, we
should specify the key with more precision.

In fact, we should preferentially specify the whole key fingerprint, but
gpg doesn't actually support that.  Which is really quite sad.

Showing the "long" format improves things to at least show 64 bits of
the fingerprint.  That's a lot better, even if it's not perfect.

This change the log format for "git log --show-signature" from

    commit 2376d317
    merged tag 'v2.9.3'
    gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT using RSA key ID 96AFE6CB
    gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
    gpg:                 aka "Junio C Hamano <jch@google.com>"
    gpg:                 aka "Junio C Hamano <junio@pobox.com>"
    Merge: 2807cd7b e0c1ceaf
    Author: Junio C Hamano <gitster@pobox.com>
    Date:   Fri Aug 12 10:02:18 2016 -0700

to

    commit 2376d317
    merged tag 'v2.9.3'
    gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT
    gpg:                using RSA key B0B5E88696AFE6CB
    gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
    gpg:                 aka "Junio C Hamano <jch@google.com>"
    gpg:                 aka "Junio C Hamano <junio@pobox.com>"
    Merge: 2807cd7b e0c1ceaf
    Author: Junio C Hamano <gitster@pobox.com>
    Date:   Fri Aug 12 10:02:18 2016 -0700

(note the longer key ID, but also the reflowing of the text) and also
changes the format in the merge messages when merging a signed
tag.

If you already use gpg2 (either because it's installed by default, or
because you have set your gpg_program configuration to point to gpg2),
that already used the long format, you'll also see a change: it will now
have the same formatting as gpg 1.x, and the verification string looks
something like

    gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT
    gpg:                using RSA key 79BE3E4300411886
    gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]

where it used to be on one line:

    gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT using RSA key ID 79BE3E4300411886
    gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]

so there is certainly a chance this could break some automated scripting.
But the 32-bit key ID's really are broken. Also note that because of the
differences between gpg-1.x and gpg-2.x, hopefully any scripted key ID
parsing code (if such code exists) is already flexible enough to not care.

This was triggered by the fact that the "evil32" project keys ended up
leaking to the public key servers, so now there are 32-bit aliases for
just about every open source developer that you can easily get by
mistake if you use the 32-bit short ID format.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

gpg-interface.c

@@ -210,7 +210,7 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 			 struct strbuf *gpg_output, struct strbuf *gpg_status)
 {
 	struct child_process gpg = CHILD_PROCESS_INIT;
-	const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", "-", NULL};
+	const char *args_gpg[] = {NULL, "--status-fd=1", "--keyid-format=long", "--verify", "FILE", "-", NULL};
 	char path[PATH_MAX];
 	int fd, ret;
 	struct strbuf buf = STRBUF_INIT;
@@ -231,7 +231,7 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 	gpg.out = -1;
 	if (gpg_output)
 		gpg.err = -1;
-	args_gpg[3] = path;
+	args_gpg[4] = path;
 	if (start_command(&gpg)) {
 		unlink(path);
 		return error(_("could not run gpg."));