Skip to contentSkip to conversation

Veryfing signatures in git log fails when language is not english

BUG In review XANi 3 participants 14 messages Jun 15, 2016 Documentation

lore
Share & tools
lore

XANi

author
#0 lore raw

Hi,

any functionality that depends on exact exit msg of program
can potentially fail because of that
ᛯ export |grep LANG
declare -x LANG="pl_PL.UTF-8"

ᛯ ~/src/os/git/git log --format="%G? %h" |head -2
0d19377
5b9d7f8

ᛯ unset LANG
ᛯ ~/src/os/git/git log --format="%G? %h" |head -2
G 0d19377
G 5b9d7f8

tested against maint (d32805d) and master (5bf72ed)

maybe git should set up some output-changing variables before calling external programs? I think setting LC_ALL=C should be enougth.

Signature · 2 lines
Mariusz Gronczewski (XANi) <[email protected]>
GnuPG: 0xEA8ACE64
#1 lore raw

XANi venit, vidit, dixit 14.02.2013 01:18:

Quoted 16 lines

Hi,

any functionality that depends on exact exit msg of program
can potentially fail because of that
ᛯ export |grep LANG
declare -x LANG="pl_PL.UTF-8"

ᛯ ~/src/os/git/git log --format="%G? %h" |head -2
0d19377
5b9d7f8

ᛯ unset LANG
ᛯ ~/src/os/git/git log --format="%G? %h" |head -2
G 0d19377
G 5b9d7f8

Quoted 5 lines

tested against maint (d32805d) and master (5bf72ed)

maybe git should set up some output-changing variables before calling external programs? I think setting LC_ALL=C should be enougth.

There are really multiple problems here:

1. git calls gpg without setting LANG but expects output in LANG=C

2. git looks at the textual output from gpg to check the validity.

3. In fact, it does so only for %G and the display of signed merge commits, in all other cases it checks the return code only.

gpg is not supposed to be used like that.

Since the callers of verify_signed_buffer do that craziness there is some refactoring to be done.

A false hotfix would be to set LANG=C when calling gpg from git, but that wouldn't solve the real problem. Besides, we do want LANG dependent output for the user.

I'll have a closer look.

BTW: Thanks for the clear report :)

Michael

#2 lore raw

2013/2/14 Michael J Gruber <[email protected]>:

Quoted 41 lines

XANi venit, vidit, dixit 14.02.2013 01:18:

Quoted 16 lines

Hi,

any functionality that depends on exact exit msg of program
can potentially fail because of that
ᛯ export |grep LANG
declare -x LANG="pl_PL.UTF-8"

ᛯ ~/src/os/git/git log --format="%G? %h" |head -2
0d19377
5b9d7f8

ᛯ unset LANG
ᛯ ~/src/os/git/git log --format="%G? %h" |head -2
G 0d19377
G 5b9d7f8

Quoted 5 lines

tested against maint (d32805d) and master (5bf72ed)

maybe git should set up some output-changing variables before calling external programs? I think setting LC_ALL=C should be enougth.

There are really multiple problems here:

1. git calls gpg without setting LANG but expects output in LANG=C

2. git looks at the textual output from gpg to check the validity.

3. In fact, it does so only for %G and the display of signed merge commits, in all other cases it checks the return code only.

gpg is not supposed to be used like that.

Since the callers of verify_signed_buffer do that craziness there is some refactoring to be done.

A false hotfix would be to set LANG=C when calling gpg from git, but that wouldn't solve the real problem. Besides, we do want LANG dependent output for the user.

Quoted 5 lines

I'll have a closer look.

BTW: Thanks for the clear report :)

Michael

What is really missing is an ability to display used key ID without hammering git log output with regexps, it would be much easier to validate incoming commits if there was format option to just display key ID instead of signer name. %GS isn't really good solution for that because it will show only one of email addresses used in the key and script checking signatures would have to always pick "right" one.

Signature · 2 lines
Mariusz Gronczewski (XANi) <[email protected]>
GnuPG: 0xEA8ACE64
#3 lore raw

PATCH 1/5 gpg-interface: check good signature in a reliable way

Currently, verify_signed_buffer() only checks the return code of gpg, and some callers implement additional unreliable checks for "Good signature" in the gpg output meant for the user.

Use the status output instead and parse for a line beinning with "[GNUPG:] GOODSIG ". This is the only reliable way of checking for a good gpg signature.

If needed we can change this easily to "[GNUPG:] VALIDSIG " if we want to take into account the trust model.

---
 gpg-interface.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
gpg-interface.c +11 -2
index 4559033..c582b2e 100644
@@ -96,15 +96,17 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig
 /*
  * Run "gpg" to see if the payload matches the detached signature.
  * gpg_output, when set, receives the diagnostic output from GPG.
+ * gpg_status, when set, receives the status output from GPG.
  */
 int verify_signed_buffer(const char *payload, size_t payload_size,
 			 const char *signature, size_t signature_size,
 			 struct strbuf *gpg_output)
 {
 	struct child_process gpg;
-	const char *args_gpg[] = {NULL, "--verify", "FILE", "-", NULL};
+	const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", "-", NULL};
 	char path[PATH_MAX];
 	int fd, ret;
+	struct strbuf buf = STRBUF_INIT;
 
 	args_gpg[0] = gpg_program;
 	fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
@@ -119,9 +121,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 	memset(&gpg, 0, sizeof(gpg));
 	gpg.argv = args_gpg;
 	gpg.in = -1;
+	gpg.out = -1;
 	if (gpg_output)
 		gpg.err = -1;
-	args_gpg[2] = path;
+	args_gpg[3] = path;
 	if (start_command(&gpg)) {
 		unlink(path);
 		return error(_("could not run gpg."));
@@ -134,9 +137,15 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 		strbuf_read(gpg_output, gpg.err, 0);
 		close(gpg.err);
 	}
+	strbuf_read(&buf, gpg.out, 0);
+	close(gpg.out);
+
 	ret = finish_command(&gpg);
 
 	unlink_or_warn(path);
 
+	ret |= !strstr(buf.buf, "\n[GNUPG:] GOODSIG ");
+	strbuf_release(&buf);
+
 	return ret;
 }
Signature · 1 line
1.8.1.3.797.ge0260c7
#4 lore raw

Re: [PATCH 1/5] gpg-interface: check good signature in a reliable way

Quoted 10 lines · Michael J Gruber

Currently, verify_signed_buffer() only checks the return code of gpg, and some callers implement additional unreliable checks for "Good signature" in the gpg output meant for the user.

Use the status output instead and parse for a line beinning with "[GNUPG:] GOODSIG ". This is the only reliable way of checking for a good gpg signature.

If needed we can change this easily to "[GNUPG:] VALIDSIG " if we want to take into account the trust model.

Thanks. I didn't look beyond "man gpg" nor bother looking at DETAILS file in its source, which the manpage refers to.

I think GOODSIG is a good starting point. Depending on the context (e.g. "%G?") we may also want to consider EXPSIG (but not EXPKEYSIG or REVKEYSIG) acceptable, while reading "log --show-signature" on ancient part of the history, no?

Quoted 56 lines
---
 gpg-interface.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
gpg-interface.c +11 -2
index 4559033..c582b2e 100644
@@ -96,15 +96,17 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig
 /*
  * Run "gpg" to see if the payload matches the detached signature.
  * gpg_output, when set, receives the diagnostic output from GPG.
+ * gpg_status, when set, receives the status output from GPG.
  */
 int verify_signed_buffer(const char *payload, size_t payload_size,
 			 const char *signature, size_t signature_size,
 			 struct strbuf *gpg_output)
 {
 	struct child_process gpg;
-	const char *args_gpg[] = {NULL, "--verify", "FILE", "-", NULL};
+	const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", "-", NULL};
 	char path[PATH_MAX];
 	int fd, ret;
+	struct strbuf buf = STRBUF_INIT;
 
 	args_gpg[0] = gpg_program;
 	fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
@@ -119,9 +121,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 	memset(&gpg, 0, sizeof(gpg));
 	gpg.argv = args_gpg;
 	gpg.in = -1;
+	gpg.out = -1;
 	if (gpg_output)
 		gpg.err = -1;
-	args_gpg[2] = path;
+	args_gpg[3] = path;
 	if (start_command(&gpg)) {
 		unlink(path);
 		return error(_("could not run gpg."));
@@ -134,9 +137,15 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 		strbuf_read(gpg_output, gpg.err, 0);
 		close(gpg.err);
 	}
+	strbuf_read(&buf, gpg.out, 0);
+	close(gpg.out);
+
 	ret = finish_command(&gpg);
 
 	unlink_or_warn(path);
 
+	ret |= !strstr(buf.buf, "\n[GNUPG:] GOODSIG ");
+	strbuf_release(&buf);
+
 	return ret;
 }
#5 lore raw

Re: [PATCH 1/5] gpg-interface: check good signature in a reliable way

Junio C Hamano venit, vidit, dixit 14.02.2013 18:22:

Quoted 13 lines
Quoted 10 lines · Michael J Gruber

Currently, verify_signed_buffer() only checks the return code of gpg, and some callers implement additional unreliable checks for "Good signature" in the gpg output meant for the user.

Use the status output instead and parse for a line beinning with "[GNUPG:] GOODSIG ". This is the only reliable way of checking for a good gpg signature.

If needed we can change this easily to "[GNUPG:] VALIDSIG " if we want to take into account the trust model.

Quoted 7 lines

Thanks. I didn't look beyond "man gpg" nor bother looking at DETAILS file in its source, which the manpage refers to.

I think GOODSIG is a good starting point. Depending on the context (e.g. "%G?") we may also want to consider EXPSIG (but not EXPKEYSIG or REVKEYSIG) acceptable, while reading "log --show-signature" on ancient part of the history, no?

Yes, we could certainly return a more detailed status to the callers. Currently, "0" is OK (GOODSIG) and everything else is a fail. We would need to change the callers to allow more details on the "fail" as well as the "OK" so that they can decide what is good enough, say:

-1: fail for technical reasons (no sig, can't run gpg etc.) 0: sig present bad (cryptographically) BAD
1: REVKEYSIG
2: EXPKEYSIG
3: EXPSIG
4: GOODSIG
5: VALIDSIG

I'd have to recheck whether a bitmask or ordered values make more sense.

Quoted 56 lines
Quoted 56 lines
---
 gpg-interface.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
gpg-interface.c +11 -2
index 4559033..c582b2e 100644
@@ -96,15 +96,17 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig
 /*
  * Run "gpg" to see if the payload matches the detached signature.
  * gpg_output, when set, receives the diagnostic output from GPG.
+ * gpg_status, when set, receives the status output from GPG.
  */
 int verify_signed_buffer(const char *payload, size_t payload_size,
 			 const char *signature, size_t signature_size,
 			 struct strbuf *gpg_output)
 {
 	struct child_process gpg;
-	const char *args_gpg[] = {NULL, "--verify", "FILE", "-", NULL};
+	const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", "-", NULL};
 	char path[PATH_MAX];
 	int fd, ret;
+	struct strbuf buf = STRBUF_INIT;
 
 	args_gpg[0] = gpg_program;
 	fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
@@ -119,9 +121,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 	memset(&gpg, 0, sizeof(gpg));
 	gpg.argv = args_gpg;
 	gpg.in = -1;
+	gpg.out = -1;
 	if (gpg_output)
 		gpg.err = -1;
-	args_gpg[2] = path;
+	args_gpg[3] = path;
 	if (start_command(&gpg)) {
 		unlink(path);
 		return error(_("could not run gpg."));
@@ -134,9 +137,15 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 		strbuf_read(gpg_output, gpg.err, 0);
 		close(gpg.err);
 	}
+	strbuf_read(&buf, gpg.out, 0);
+	close(gpg.out);
+
 	ret = finish_command(&gpg);
 
 	unlink_or_warn(path);
 
+	ret |= !strstr(buf.buf, "\n[GNUPG:] GOODSIG ");
+	strbuf_release(&buf);
+
 	return ret;
 }
#6 lore raw

PATCH 2/5 log-tree: rely upon the check in the gpg_interface

In reply to Mariusz Gronczewski

It's just so much betterer.

---
 log-tree.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)
log-tree.c +11 -14
index 5dc45c4..912fe08 100644
@@ -508,20 +508,17 @@ static void show_one_mergetag(struct rev_info *opt,
 	gpg_message_offset = verify_message.len;
 
 	payload_size = parse_signature(extra->value, extra->len);
-	if ((extra->len <= payload_size) ||
-	    (verify_signed_buffer(extra->value, payload_size,
-				  extra->value + payload_size,
-				  extra->len - payload_size,
-				  &verify_message) &&
-	     verify_message.len <= gpg_message_offset)) {
-		strbuf_addstr(&verify_message, "No signature\n");
-		status = -1;
-	}
-	else if (strstr(verify_message.buf + gpg_message_offset,
-			": Good signature from "))
-		status = 0;
-	else
-		status = -1;
+	status = -1;
+	if (extra->len > payload_size)
+		if (verify_signed_buffer(extra->value, payload_size,
+					 extra->value + payload_size,
+					 extra->len - payload_size,
+					 &verify_message)) {
+			if (verify_message.len <= gpg_message_offset)
+				strbuf_addstr(&verify_message, "No signature\n");
+			else
+				status = 0;
+		}
 
 	show_sig_lines(opt, status, verify_message.buf);
 	strbuf_release(&verify_message);
Signature · 1 line
1.8.1.3.797.ge0260c7
#7 lore raw

PATCH 3/5 gpg_interface: allow to request status return

In reply to Mariusz Gronczewski

Currently, verify_signed_buffer() returns the user facing output only.

Allow callers to request the status output also.

---
 builtin/fmt-merge-msg.c |  2 +-
 builtin/verify-tag.c    |  2 +-
 gpg-interface.c         | 11 +++++++----
 gpg-interface.h         |  2 +-
 log-tree.c              |  4 ++--
 pretty.c                |  2 +-
 6 files changed, 13 insertions(+), 10 deletions(-)
builtin/fmt-merge-msg.c +1 -1
index b49612f..265a925 100644
@@ -492,7 +492,7 @@ static void fmt_merge_msg_sigs(struct strbuf *out)
 
 		if (size == len)
 			; /* merely annotated */
-		else if (verify_signed_buffer(buf, len, buf + len, size - len, &sig)) {
+		else if (verify_signed_buffer(buf, len, buf + len, size - len, &sig, NULL)) {
 			if (!sig.len)
 				strbuf_addstr(&sig, "gpg verification failed.\n");
 		}
builtin/verify-tag.c +1 -1
index a8eee88..9cdf332 100644
@@ -29,7 +29,7 @@ static int run_gpg_verify(const char *buf, unsigned long size, int verbose)
 	if (size == len)
 		return error("no signature found");
 
-	return verify_signed_buffer(buf, len, buf + len, size - len, NULL);
+	return verify_signed_buffer(buf, len, buf + len, size - len, NULL, NULL);
 }
 
 static int verify_tag(const char *name, int verbose)
gpg-interface.c +7 -4
index c582b2e..8b0e874 100644
@@ -100,13 +100,14 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig
  */
 int verify_signed_buffer(const char *payload, size_t payload_size,
 			 const char *signature, size_t signature_size,
-			 struct strbuf *gpg_output)
+			 struct strbuf *gpg_output, struct strbuf *gpg_status)
 {
 	struct child_process gpg;
 	const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", "-", NULL};
 	char path[PATH_MAX];
 	int fd, ret;
 	struct strbuf buf = STRBUF_INIT;
+	struct strbuf *pbuf = &buf;
 
 	args_gpg[0] = gpg_program;
 	fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
@@ -137,15 +138,17 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
 		strbuf_read(gpg_output, gpg.err, 0);
 		close(gpg.err);
 	}
-	strbuf_read(&buf, gpg.out, 0);
+	if (gpg_status)
+		pbuf = gpg_status;
+	strbuf_read(pbuf, gpg.out, 0);
 	close(gpg.out);
 
 	ret = finish_command(&gpg);
 
 	unlink_or_warn(path);
 
-	ret |= !strstr(buf.buf, "\n[GNUPG:] GOODSIG ");
-	strbuf_release(&buf);
+	ret |= !strstr(pbuf->buf, "\n[GNUPG:] GOODSIG ");
+	strbuf_release(&buf); /* no matter it was used or not */
 
 	return ret;
 }
gpg-interface.h +1 -1
index b9c3608..cf99021 100644
@@ -2,7 +2,7 @@
 #define GPG_INTERFACE_H
 
 extern int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *signing_key);
-extern int verify_signed_buffer(const char *payload, size_t payload_size, const char *signature, size_t signature_size, struct strbuf *gpg_output);
+extern int verify_signed_buffer(const char *payload, size_t payload_size, const char *signature, size_t signature_size, struct strbuf *gpg_output, struct strbuf *gpg_status);
 extern int git_gpg_config(const char *, const char *, void *);
 extern void set_signing_key(const char *);
 extern const char *get_signing_key(void);
log-tree.c +2 -2
index 912fe08..3d88823 100644
@@ -444,7 +444,7 @@ static void show_signature(struct rev_info *opt, struct commit *commit)
 
 	status = verify_signed_buffer(payload.buf, payload.len,
 				      signature.buf, signature.len,
-				      &gpg_output);
+				      &gpg_output, NULL);
 	if (status && !gpg_output.len)
 		strbuf_addstr(&gpg_output, "No signature\n");
 
@@ -513,7 +513,7 @@ static void show_one_mergetag(struct rev_info *opt,
 		if (verify_signed_buffer(extra->value, payload_size,
 					 extra->value + payload_size,
 					 extra->len - payload_size,
-					 &verify_message)) {
+					 &verify_message, NULL)) {
 			if (verify_message.len <= gpg_message_offset)
 				strbuf_addstr(&verify_message, "No signature\n");
 			else
pretty.c +1 -1
index eae57ad..2a1e174 100644
@@ -984,7 +984,7 @@ static void parse_commit_signature(struct format_commit_context *ctx)
 		goto out;
 	status = verify_signed_buffer(payload.buf, payload.len,
 				      signature.buf, signature.len,
-				      &gpg_output);
+				      &gpg_output, NULL);
 	if (status && !gpg_output.len)
 		goto out;
 	ctx->signature.gpg_output = strbuf_detach(&gpg_output, NULL);
Signature · 1 line
1.8.1.3.797.ge0260c7
#8 lore raw
In reply to Mariusz Gronczewski
Quoted 6 lines · Mariusz Gronczewski

What is really missing is an ability to display used key ID without hammering git log output with regexps, it would be much easier to validate incoming commits if there was format option to just display key ID instead of signer name. %GS isn't really good solution for that because it will show only one of email addresses used in the key and script checking signatures would have to always pick "right" one.

The %G<anything> pretty modifiers other than %GG were done mostly as placeholders.

I think the following would be a good way to refine them:

- %GG, and possibly "log --show-signature" should run GPG under the user's LANG.

- %G? is mostly useless, unless it is made to always mean "does it verify crypto-wise" and nothing else. One bit is simply too small to represent all the cases where you may or may not have the signer's key, or you may have the key but you do not have enough trust in it (e.g. the key may be expired, revoked, or not enough confidence in your web of trust).

- The "right" one you mention for %GS is easier than you might think. If you just verify against the accompanying "tagger" identity, that should be sufficient. It of course cannot be generally solved, as you could tag as person A while signing with key for person B, but a simple social convention would help us out there: if you tag as Mariusz Gronczewski, your signature should also say so.

#9 lore raw

2013/2/14 Junio C Hamano <[email protected]>:

Quoted 8 lines

- The "right" one you mention for %GS is easier than you might think. If you just verify against the accompanying "tagger" identity, that should be sufficient. It of course cannot be generally solved, as you could tag as person A while signing with key for person B, but a simple social convention would help us out there: if you tag as Mariusz Gronczewski, your signature should also say so.

unless there is someone else with same name, which happens more often (so far i've seen it happen twice) than same GPG IDs. It's all fine if you just have one keyring that you can use to validate against all repos but when there are multiple projects each with different persons responsible for deploying it can get messy ;].

my use-case is basically "allow only commits signed by person X Y or Z to be deployed on production" and "allow only persons A, B, C, X, Y, Z to commit", while latter case can be solved by software like gitolite, credential validation is messy at best as you have to validate:
- ssh key
- if ssh key owner matches commiter name
- if commiter name =! author name, if a given person can do that (project architect or some other person accepting patches) or can't and I'm trying to implement GPG signing so if someone does something malicious i can say "OK that commit was signed by your key ID, why you did it?"

Signature · 2 lines
Mariusz Gronczewski (XANi) <[email protected]>
GnuPG: 0xEA8ACE64
#10 lore raw
Quoted 11 lines · Mariusz Gronczewski

2013/2/14 Junio C Hamano <[email protected]>:

Quoted 8 lines

- The "right" one you mention for %GS is easier than you might think. If you just verify against the accompanying "tagger" identity, that should be sufficient. It of course cannot be generally solved, as you could tag as person A while signing with key for person B, but a simple social convention would help us out there: if you tag as Mariusz Gronczewski, your signature should also say so.

unless there is someone else with same name, which happens more often (so far i've seen it happen twice) than same GPG IDs.

Oh, I didn't mean to say "ignore email part", which of course will make the result more likely to be ambiguous.

I thought you meant by "have to show right one" the following scenario:

The tag v1.8.1 has a GPG signature. The key 96AFE6CB was used to sign it. The key is associated with more than one identities. One of them is "Junio C Hamano <[email protected]>", but that is not the only one. I also have combinations of other e-mail addresses and names spelled differently (e.g. "Junio Hamano <[email protected]>") that are _not_ associated with that key.

GPG may say "good signature from A aka B aka C"; which one of A, B, or C should we choose?

I was suggesting that among the identities associated with the key used to sign the tag, we should show the one that matches the identity on the tagger field.

    object 5d417842efeafb6e109db7574196901c4e95d273
    type commit
    tag v1.8.1
    tagger Junio C Hamano <[email protected]> 1356992771 -0800

    Git 1.8.1
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (GNU/Linux)

    iQIc...
    =v706
    -----END PGP SIGNATURE-----

Because it is clear from the context where the signature appears that that identity is what matters for me as a signer in the project the tag appears in.

I may have other e-mail addresses that are not associated with that key, but it would be insane to put that on the tagger field of the tag, while GPG-signing with that key.

#11 lore raw

PATCH 4/5 pretty: parse the gpg status lines rather than the output

In reply to Mariusz Gronczewski

Currently, parse_signature_lines() parses the gpg output for strings which depend on LANG so it fails to recognize good commit signatures (and thus does not fill in %G? and the like) in most locales.

Make it parse the status lines from gpg instead, which are the proper machine interface. This fixes the problem described above.

There is a change in behavior for "%GS" which we intentionally do not work around: "%GS" used to put quotes around the signer's uid (or
rather: it inherited from the gpg user output). We output the uid without quotes now, just like author and committer names.

---
 pretty.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)
pretty.c +9 -5
index 2a1e174..973b912 100644
@@ -759,6 +759,7 @@ struct format_commit_context {
 	unsigned commit_signature_parsed:1;
 	struct {
 		char *gpg_output;
+		char *gpg_status;
 		char good_bad;
 		char *signer;
 	} signature;
@@ -948,13 +949,13 @@ static struct {
 	char result;
 	const char *check;
 } signature_check[] = {
-	{ 'G', ": Good signature from " },
-	{ 'B', ": BAD signature from " },
+	{ 'G', "\n[GNUPG:] GOODSIG " },
+	{ 'B', "\n[GNUPG:] BADSIG " },
 };
 
 static void parse_signature_lines(struct format_commit_context *ctx)
 {
-	const char *buf = ctx->signature.gpg_output;
+	const char *buf = ctx->signature.gpg_status;
 	int i;
 
 	for (i = 0; i < ARRAY_SIZE(signature_check); i++) {
@@ -963,7 +964,7 @@ static void parse_signature_lines(struct format_commit_context *ctx)
 		if (!found)
 			continue;
 		ctx->signature.good_bad = signature_check[i].result;
-		found += strlen(signature_check[i].check);
+		found += strlen(signature_check[i].check)+17;
 		next = strchrnul(found, '\n');
 		ctx->signature.signer = xmemdupz(found, next - found);
 		break;
@@ -975,6 +976,7 @@ static void parse_commit_signature(struct format_commit_context *ctx)
 	struct strbuf payload = STRBUF_INIT;
 	struct strbuf signature = STRBUF_INIT;
 	struct strbuf gpg_output = STRBUF_INIT;
+	struct strbuf gpg_status = STRBUF_INIT;
 	int status;
 
 	ctx->commit_signature_parsed = 1;
@@ -984,13 +986,15 @@ static void parse_commit_signature(struct format_commit_context *ctx)
 		goto out;
 	status = verify_signed_buffer(payload.buf, payload.len,
 				      signature.buf, signature.len,
-				      &gpg_output, NULL);
+				      &gpg_output, &gpg_status);
 	if (status && !gpg_output.len)
 		goto out;
 	ctx->signature.gpg_output = strbuf_detach(&gpg_output, NULL);
+	ctx->signature.gpg_status = strbuf_detach(&gpg_status, NULL);
 	parse_signature_lines(ctx);
 
  out:
+	strbuf_release(&gpg_status);
 	strbuf_release(&gpg_output);
 	strbuf_release(&payload);
 	strbuf_release(&signature);
Signature · 1 line
1.8.1.3.797.ge0260c7
#12 lore raw

cover gpg_interface: use the status

In reply to Mariusz Gronczewski

Currently, we look at the user facing output of gpg, which is LANG dependent as well as insecure.

After this series, we look at the status output (--status-fd) which is designed for that purpose. As an additional benefit, we can read off the key which was used for the signature, which is important for assigning trust.

All existing tests pass with this.

BTW: git branch --set-upstream-to= coredumps when on a detached head.

Michael J Gruber (5):
gpg-interface: check good signature in a reliable way
log-tree: rely upon the check in the gpg_interface
gpg_interface: allow to request status return
pretty: parse the gpg status lines rather than the output
pretty: make %GK output the signing key for signed commits

 Documentation/pretty-formats.txt |  1 +
 builtin/fmt-merge-msg.c          |  2 +-
 builtin/verify-tag.c             |  2 +-
 gpg-interface.c                  | 18 +++++++++++++++---
 gpg-interface.h                  |  2 +-
 log-tree.c                       | 27 ++++++++++++---------------
 pretty.c                         | 19 +++++++++++++++----
 7 files changed, 46 insertions(+), 25 deletions(-)
Signature · 1 line
1.8.1.3.797.ge0260c7
#13 lore raw

PATCH 5/5 pretty: make %GK output the signing key for signed commits

In reply to Mariusz Gronczewski

Because we can.

No, really: In order to employ signed keys in an automated way it is absolutely necessary to check which keys the signatures come from. Now you can.

---
 Documentation/pretty-formats.txt | 1 +
 pretty.c                         | 9 ++++++++-
 2 files changed, 9 insertions(+), 1 deletion(-)
Documentation/pretty-formats.txt +1 -0
index 105f18a..2939655 100644
@@ -133,6 +133,7 @@ The placeholders are:
 - '%GG': raw verification message from GPG for a signed commit
 - '%G?': show either "G" for Good or "B" for Bad for a signed commit
 - '%GS': show the name of the signer for a signed commit
+- '%GK': show the key used to sign a signed commit
 - '%gD': reflog selector, e.g., `refs/stash@{1}`
 - '%gd': shortened reflog selector, e.g., `stash@{1}`
 - '%gn': reflog identity name
pretty.c +8 -1
index 973b912..b57adef 100644
@@ -762,6 +762,7 @@ struct format_commit_context {
 		char *gpg_status;
 		char good_bad;
 		char *signer;
+		char *key;
 	} signature;
 	char *message;
 	size_t width, indent1, indent2;
@@ -964,7 +965,9 @@ static void parse_signature_lines(struct format_commit_context *ctx)
 		if (!found)
 			continue;
 		ctx->signature.good_bad = signature_check[i].result;
-		found += strlen(signature_check[i].check)+17;
+		found += strlen(signature_check[i].check);
+		ctx->signature.key = xmemdupz(found, 16);
+		found += 17;
 		next = strchrnul(found, '\n');
 		ctx->signature.signer = xmemdupz(found, next - found);
 		break;
@@ -1204,6 +1207,10 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
 			if (c->signature.signer)
 				strbuf_addstr(sb, c->signature.signer);
 			break;
+		case 'K':
+			if (c->signature.key)
+				strbuf_addstr(sb, c->signature.key);
+			break;
 		}
 		return 2;
 	}
Signature · 1 line
1.8.1.3.797.ge0260c7