Request: Extra case for %G? format

PATCH Superseded Alex 4 participants 16 messages Sep 25, 2016 – Oct 12, 2016 Documentation

lore

Share & tools

lore

Alex

author

2016-09-25 06:06 UTC #0 lore raw

Hello all,

Could the %G? format differentiate between an unsigned commit and a signed commit that you're missing a public key for?

If `git show --format=%GG --no-patch <commit>' produces an output like the following:

gpg: Signature made <date> using RSA key ID <id>
gpg: Can't check signature: public key not found

Then currently %G? results in `N', the same as an unsigned commit.

In this case, could %G? please result in a new character? Perhaps `M' for "missing public key"?

Michael J Gruber

2016-09-26 11:54 UTC #1 lore raw

Alex venit, vidit, dixit 25.09.2016 08:05:

Quoted 10 lines

Hello all,
Could the %G? format differentiate between an unsigned commit and a signed commit that you're missing a public key for?
If `git show --format=%GG --no-patch <commit>' produces an output like the following:
gpg: Signature made <date> using RSA key ID <id>
gpg: Can't check signature: public key not found

That is the "raw verification message from GPG for a signed commit" as per git-log(1).

Quoted 4 lines

Then currently %G? results in `N', the same as an unsigned commit.
In this case, could %G? please result in a new character? Perhaps `M' for "missing public key"?

Yes, and no.

Really, there are many different reasons why a signature couldn't be checked, but gpg itself has these status results:

"For each signature only one of the three codes GOODSIG, BADSIG or ERRSIG will be emitted" (doc/DETAILS in gpg's source).

ERRSIG comes with additional info (RC) that could be parsed for the reason.

Also, in addition to that line, there can be other lines with additional information. So there is a lot that could potentially be shown (and *is* shown with %GG). In the GOODSIG case, we parse the TRUST info to take the trust model into account (and return U for untrusted good).

I wouldn't mind adding E to %G? in the ERRSIG case, even though one has to look at %GG in any case (N or E) if one wants to have more details.

Cheers,
Michael

Alex

author

2016-09-26 17:18 UTC #2 lore raw

Quoted 5 lines · Michael J Gruber

Quoted 4 lines
Then currently %G? results in `N', the same as an unsigned commit.
In this case, could %G? please result in a new character? Perhaps `M' for "missing public key"?

Quoted 7 lines

Yes, and no.
Really, there are many different reasons why a signature couldn't be checked, but gpg itself has these status results:
"For each signature only one of the three codes GOODSIG, BADSIG or ERRSIG will be emitted" (doc/DETAILS in gpg's source).

I see. It seems in GPG2 that got expanded to:

"For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted."

I don't suppose it's worthwhile to support the others? I'm not sure how important the rest are.

Quoted 9 lines

ERRSIG comes with additional info (RC) that could be parsed for the reason.
Also, in addition to that line, there can be other lines with additional information. So there is a lot that could potentially be shown (and *is* shown with %GG). In the GOODSIG case, we parse the TRUST info to take the trust model into account (and return U for untrusted good).
I wouldn't mind adding E to %G? in the ERRSIG case, even though one has to look at %GG in any case (N or E) if one wants to have more details.

That would be great. As long as %G? can tell between a signed but uncheckable commit and an unsigned commit, then it's good for me.

Quoted 3 lines

Cheers,
Michael

Thanks,
Alex

Michael J Gruber

2016-09-27 14:31 UTC #3 lore raw

PATCH 1/1 gpg-interface: use more status letters

According to gpg2's doc/DETAILS:
"For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted."

gpg1 ("classic") behaves the same (although doc/DETAILS differs).

Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier.

git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side.

Introduce additional status codes E, X, R for ERRSIG, EXP*SIG, REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance.

Reported-by Alex <[email protected]>

Signed-off-by Michael J Gruber <[email protected]>

---
I'd be happy to learn are more portable/safer/cooler way to make gpg forget that key in the added test...

 Documentation/pretty-formats.txt |  9 +++++++--
 gpg-interface.c                  |  4 ++++
 pretty.c                         |  3 +++
 t/t7510-signed-commit.sh         | 11 ++++++++++-
 4 files changed, 24 insertions(+), 3 deletions(-)

Documentation/pretty-formats.txt +7 -2

index a942d57..806b47f 100644
@@ -143,8 +143,13 @@ ifndef::git-rev-list[]
 - '%N': commit notes
 endif::git-rev-list[]
 - '%GG': raw verification message from GPG for a signed commit
-- '%G?': show "G" for a good (valid) signature, "B" for a bad signature,
-  "U" for a good signature with unknown validity and "N" for no signature
+- '%G?': show "G" for a good (rather: valid) signature,
+  "B" for a bad signature,
+  "U" for a good signature with unknown validity,
+  "X" for a good expired signature, or good signature made by an expired key,
+  "R" for a good signature made by a revoked key,
+  "E" if the signature cannot be checked (e.g. missing key)
+  and "N" for no signature
 - '%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}` or

gpg-interface.c +4 -0

index 8672eda..8a3e245 100644
@@ -33,6 +33,10 @@ static struct {
 	{ 'B', "\n[GNUPG:] BADSIG " },
 	{ 'U', "\n[GNUPG:] TRUST_NEVER" },
 	{ 'U', "\n[GNUPG:] TRUST_UNDEFINED" },
+	{ 'E', "\n[GNUPG:] ERRSIG "},
+	{ 'X', "\n[GNUPG:] EXPSIG "},
+	{ 'X', "\n[GNUPG:] EXPKEYSIG "},
+	{ 'R', "\n[GNUPG:] REVKEYSIG "},
 };
 
 void parse_gpg_output(struct signature_check *sigc)

pretty.c +3 -0

index 493edb0..39a36cd 100644
@@ -1232,8 +1232,11 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
 			switch (c->signature_check.result) {
 			case 'G':
 			case 'B':
+			case 'E':
 			case 'U':
 			case 'N':
+			case 'X':
+			case 'R':
 				strbuf_addch(sb, c->signature_check.result);
 			}
 			break;

t/t7510-signed-commit.sh +10 -1

index 6e839f5..fd22742 100755
@@ -190,7 +190,7 @@ test_expect_success GPG 'show bad signature with custom format' '
 	test_cmp expect actual
 '
 
-test_expect_success GPG 'show unknown signature with custom format' '
+test_expect_success GPG 'show untrusted signature with custom format' '
 	cat >expect <<-\EOF &&
 	U
 	61092E85B7227189

@@ -200,6 +200,15 @@ test_expect_success GPG 'show unknown signature with custom format' '
 	test_cmp expect actual
 '
 
+test_expect_success GPG 'show unknown signature with custom format' '
+	cat >expect <<-\EOF &&
+	E
+	61092E85B7227189
+	EOF
+	GNUPGHOME=/dev/null git log -1 --format="%G?%n%GK" eighth-signed-alt >actual &&
+	test_cmp expect actual
+'
+
 test_expect_success GPG 'show lack of signature with custom format' '
 	cat >expect <<-\EOF &&
 	N

Signature · 1 line

2.10.0.527.gbcb6904

Junio C Hamano

2016-09-27 17:25 UTC #4 lore raw

Re: [PATCH] gpg-interface: use more status letters

Quoted 15 lines · Michael J Gruber

According to gpg2's doc/DETAILS:
"For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted."
gpg1 ("classic") behaves the same (although doc/DETAILS differs).
Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier.
git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side.

Quoted 6 lines

Introduce additional status codes E, X, R for ERRSIG, EXP*SIG, REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance.
Reported-by Alex <[email protected]>
Signed-off-by Michael J Gruber <[email protected]>

That probably was requested-by, but that's OK.

Quoted 2 lines

I'd be happy to learn are more portable/safer/cooler way to make gpg forget that key in the added test...

We seem to set GNUPGHOME to $HOME/gnupg-home-not-used in test-lib.sh to say "No gnupg keys for you!" for all the tests by default, which is overriden by the signature tests like 7510. I do not know if that is more portable/safer/cooler than setting it to /dev/null but imitating it might be a way for you to push the potential problem away to other people ;-) If it becomes an issue to set it to a directory that does not exist with an updated future version of GPG, this new test will share the same problem with everybody else, and hopefully the solution would be the same ;-)

Having said that, if GNUPGHOME=/dev/null works for you, that's good enough for now, so that people on other platforms can test it and report.

Thanks.

Quoted 29 lines

t/t7510-signed-commit.sh +10 -1

index 6e839f5..fd22742 100755
@@ -190,7 +190,7 @@ test_expect_success GPG 'show bad signature with custom format' '
 	test_cmp expect actual
 '
 
-test_expect_success GPG 'show unknown signature with custom format' '
+test_expect_success GPG 'show untrusted signature with custom format' '
 	cat >expect <<-\EOF &&
 	U
 	61092E85B7227189

@@ -200,6 +200,15 @@ test_expect_success GPG 'show unknown signature with custom format' '
 	test_cmp expect actual
 '
 
+test_expect_success GPG 'show unknown signature with custom format' '
+	cat >expect <<-\EOF &&
+	E
+	61092E85B7227189
+	EOF
+	GNUPGHOME=/dev/null git log -1 --format="%G?%n%GK" eighth-signed-alt >actual &&
+	test_cmp expect actual
+'
+
 test_expect_success GPG 'show lack of signature with custom format' '
 	cat >expect <<-\EOF &&
 	N

Michael J Gruber

2016-09-28 14:24 UTC #5 lore raw

PATCH v2 1/1 gpg-interface: use more status letters

According to gpg2's doc/DETAILS:
"For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted."

gpg1 ("classic") behaves the same (although doc/DETAILS differs).

Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier.

git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side.

Introduce additional status codes E, X, R for ERRSIG, EXP*SIG, REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance.

Requested-by Alex <[email protected]>

Signed-off-by Michael J Gruber <[email protected]>

---
Changes in v2:

- Use GNUPGHOME="$HOME/gnupg-home-not-used" just like in other tests (lib).
- Do not parse for signer UID in the ERRSIG case (and test that we do not).
- Retreat "rather" addition from the doc: good/valid are terms that we use differently from gpg anyways.

 Documentation/pretty-formats.txt |  9 +++++++--
 gpg-interface.c                  | 13 ++++++++++---
 pretty.c                         |  3 +++
 t/t7510-signed-commit.sh         | 12 +++++++++++-
 4 files changed, 31 insertions(+), 6 deletions(-)

Documentation/pretty-formats.txt +7 -2

index a942d57..c28ff2b 100644
@@ -143,8 +143,13 @@ ifndef::git-rev-list[]
 - '%N': commit notes
 endif::git-rev-list[]
 - '%GG': raw verification message from GPG for a signed commit
-- '%G?': show "G" for a good (valid) signature, "B" for a bad signature,
-  "U" for a good signature with unknown validity and "N" for no signature
+- '%G?': show "G" for a good (valid) signature,
+  "B" for a bad signature,
+  "U" for a good signature with unknown validity,
+  "X" for a good expired signature, or good signature made by an expired key,
+  "R" for a good signature made by a revoked key,
+  "E" if the signature cannot be checked (e.g. missing key)
+  and "N" for no signature
 - '%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}` or

gpg-interface.c +10 -3

index 8672eda..6999e7b 100644
@@ -33,6 +33,10 @@ static struct {
 	{ 'B', "\n[GNUPG:] BADSIG " },
 	{ 'U', "\n[GNUPG:] TRUST_NEVER" },
 	{ 'U', "\n[GNUPG:] TRUST_UNDEFINED" },
+	{ 'E', "\n[GNUPG:] ERRSIG "},
+	{ 'X', "\n[GNUPG:] EXPSIG "},
+	{ 'X', "\n[GNUPG:] EXPKEYSIG "},
+	{ 'R', "\n[GNUPG:] REVKEYSIG "},
 };
 
 void parse_gpg_output(struct signature_check *sigc)

@@ -54,9 +58,12 @@ void parse_gpg_output(struct signature_check *sigc)
 		/* The trust messages are not followed by key/signer information */
 		if (sigc->result != 'U') {
 			sigc->key = xmemdupz(found, 16);
-			found += 17;
-			next = strchrnul(found, '\n');
-			sigc->signer = xmemdupz(found, next - found);
+			/* The ERRSIG message is not followed by signer information */
+			if (sigc-> result != 'E') {
+				found += 17;
+				next = strchrnul(found, '\n');
+				sigc->signer = xmemdupz(found, next - found);
+			}
 		}
 	}
 }

pretty.c +3 -0

index 493edb0..39a36cd 100644
@@ -1232,8 +1232,11 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
 			switch (c->signature_check.result) {
 			case 'G':
 			case 'B':
+			case 'E':
 			case 'U':
 			case 'N':
+			case 'X':
+			case 'R':
 				strbuf_addch(sb, c->signature_check.result);
 			}
 			break;

t/t7510-signed-commit.sh +11 -1

index 6e839f5..9f487f9 100755
@@ -190,7 +190,7 @@ test_expect_success GPG 'show bad signature with custom format' '
 	test_cmp expect actual
 '
 
-test_expect_success GPG 'show unknown signature with custom format' '
+test_expect_success GPG 'show untrusted signature with custom format' '
 	cat >expect <<-\EOF &&
 	U
 	61092E85B7227189

@@ -200,6 +200,16 @@ test_expect_success GPG 'show unknown signature with custom format' '
 	test_cmp expect actual
 '
 
+test_expect_success GPG 'show unknown signature with custom format' '
+	cat >expect <<-\EOF &&
+	E
+	61092E85B7227189
+
+	EOF
+	GNUPGHOME="$HOME/gnupg-home-not-used" git log -1 --format="%G?%n%GK%n%GS" eighth-signed-alt >actual &&
+	test_cmp expect actual
+'
+
 test_expect_success GPG 'show lack of signature with custom format' '
 	cat >expect <<-\EOF &&
 	N

Signature · 1 line

2.10.0.527.gbcb6904

Ramsay Jones

2016-09-28 15:10 UTC #6 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

Quoted 40 lines · Michael J Gruber

According to gpg2's doc/DETAILS:
"For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted."
gpg1 ("classic") behaves the same (although doc/DETAILS differs).
Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier.
git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side.
Introduce additional status codes E, X, R for ERRSIG, EXP*SIG, REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance.
Requested-by Alex <[email protected]>
Signed-off-by Michael J Gruber <[email protected]>
---
Changes in v2:
- Use GNUPGHOME="$HOME/gnupg-home-not-used" just like in other tests (lib).
- Do not parse for signer UID in the ERRSIG case (and test that we do not).
- Retreat "rather" addition from the doc: good/valid are terms that we use differently from gpg anyways.
 Documentation/pretty-formats.txt |  9 +++++++--
 gpg-interface.c                  | 13 ++++++++++---
 pretty.c                         |  3 +++
 t/t7510-signed-commit.sh         | 12 +++++++++++-
 4 files changed, 31 insertions(+), 6 deletions(-)
Documentation/pretty-formats.txt +0 -0
index a942d57..c28ff2b 100644

Documentation/pretty-formats.txt ifndef::git-rev-list[] · line 149

Quoted 9 lines

Documentation/pretty-formats.txt +4 -2

@@ -143,8 +143,13 @@ ifndef::git-rev-list[]
 - '%N': commit notes
 endif::git-rev-list[]
 - '%GG': raw verification message from GPG for a signed commit
-- '%G?': show "G" for a good (valid) signature, "B" for a bad signature,
-  "U" for a good signature with unknown validity and "N" for no signature
+- '%G?': show "G" for a good (valid) signature,
+  "B" for a bad signature,
+  "U" for a good signature with unknown validity,
+  "X" for a good expired signature, or good signature made by an expired key,

Hmm, this looks odd. Would the following:

"X" for a good signature made with an expired key,

mean something different?

ATB,
Ramsay Jones

Junio C Hamano

2016-09-28 19:59 UTC #7 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

In reply to Michael J Gruber

Quoted 1 line · Michael J Gruber

- Use GNUPGHOME="$HOME/gnupg-home-not-used" just like in other tests (lib).

If you are not using /dev/null, I expected you to do

	. ./test-lib.sh
	GNUPGHOME_saved=$GNPGHOME
        . "$TEST_DIRECTORY/lib-gpg.sh"

and then use

GNUPGHOME="$GNUPGHOME_saved" git log -1 ...

in the test.

Otherwise, you are not futureproofing your use and only adding to maintenance burden. The gnupg-home-not-used hack may turn out to be a problematic and test-lib.sh may update to point to somewhere else, which will leave your copy still pointing at the old problematic place).

Quoted 1 line

- Do not parse for signer UID in the ERRSIG case (and test that we do not).

Good.

Quoted 2 lines

- Retreat "rather" addition from the doc: good/valid are terms that we use differently from gpg anyways.

OK.

Quoted 1 line

+ "X" for a good expired signature, or good signature made by an expired key,

As an attempt to clarify that we cover both EXPSIG and EXPKEYSIG cases, I think this is good enough. I may have phrased the former slightly differently, though: "a good signature that has expired".

I have no strong opinion if we want to stress that we cover both cases, though, which is I think what Ramsay's comment was about.

Thanks.

Ramsay Jones

2016-09-28 21:10 UTC #8 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

Quoted 10 lines · Junio C Hamano

Quoted 1 line · Michael J Gruber
+ "X" for a good expired signature, or good signature made by an expired key,
As an attempt to clarify that we cover both EXPSIG and EXPKEYSIG cases, I think this is good enough. I may have phrased the former slightly differently, though: "a good signature that has expired".
I have no strong opinion if we want to stress that we cover both cases, though, which is I think what Ramsay's comment was about.

Kinda! ;-)

I'm not sure that it is a good idea to mash both EXPSIG and EXPKEYSIG into one status letter, but I was also fishing for some information about EXPSIG. I was only vaguely aware that a signature could expire _independently_ of the key used to do the signing. Also, according to
https://www.gnupg.org/documentation/manuals/gnupg/Automated-signature-checking.html
for the EXPSIG case 'Note, that this case is currently not implemented.'

Hmm, I guess these are so closely related that a single status letter is OK, but I think I would prefer your phrasing; namely:

"X" for a good signature that has expired, or a good signature made with an expired key,

[Although that is still a bit cumbersome.]

ATB,
Ramsay Jones

Michael J Gruber

2016-09-30 09:41 UTC #9 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

Ramsay Jones venit, vidit, dixit 28.09.2016 23:09:

Quoted 14 lines · Junio C Hamano

Quoted 10 lines
Quoted 1 line · Michael J Gruber
+ "X" for a good expired signature, or good signature made by an expired key,
As an attempt to clarify that we cover both EXPSIG and EXPKEYSIG cases, I think this is good enough. I may have phrased the former slightly differently, though: "a good signature that has expired".
I have no strong opinion if we want to stress that we cover both cases, though, which is I think what Ramsay's comment was about.

Quoted 8 lines

Kinda! ;-)
I'm not sure that it is a good idea to mash both EXPSIG and EXPKEYSIG into one status letter, but I was also fishing for some information about EXPSIG. I was only vaguely aware that a signature could expire _independently_ of the key used to do the signing. Also, according to
https://www.gnupg.org/documentation/manuals/gnupg/Automated-signature-checking.html
for the EXPSIG case 'Note, that this case is currently not implemented.'

A key can have an expiration date.

A signature can have an expiration date.

The "goodness" of a signature is independent of the expiraton dates.

Signature expiration is implemented, I tested that (gpg 1 aka "classic").

Quoted 5 lines

Hmm, I guess these are so closely related that a single status letter is OK, but I think I would prefer your phrasing; namely:
"X" for a good signature that has expired, or a good signature made with an expired key,

I'm open to whatever phrasing you deem clearer.

Also, I'm open to using another letter for EXPKEYSIG but couldn't decide between 'Y', 'Z', 'K'. 'K' could be confused with REVKEYSIG, I'm afraid. 'Y' is next to 'X' and contained in 'KEY', it would be my first choice.

Cheers,
Michael

Junio C Hamano

2016-09-30 16:16 UTC #10 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

Quoted 3 lines · Michael J Gruber

Also, I'm open to using another letter for EXPKEYSIG but couldn't decide between 'Y', 'Z', 'K'. 'K' could be confused with REVKEYSIG, I'm afraid. 'Y' is next to 'X' and contained in 'KEY', it would be my first choice.

Sounds good enough to me. Thanks.

Junio C Hamano

2016-10-06 21:43 UTC #11 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

Quoted 7 lines · Junio C Hamano

Quoted 3 lines · Michael J Gruber
Also, I'm open to using another letter for EXPKEYSIG but couldn't decide between 'Y', 'Z', 'K'. 'K' could be confused with REVKEYSIG, I'm afraid. 'Y' is next to 'X' and contained in 'KEY', it would be my first choice.
Sounds good enough to me. Thanks.

I really do not want to leave too many topics listed in the "What's cooking" report to be in undecided / waiting state. How about squashing this in, with a fully updated log message to replace?

-- >8 --
From: Michael J Gruber <[email protected]>
Date: Wed, 28 Sep 2016 16:24:13 +0200
Subject: [PATCH] SQUASH: gpg-interface: use more status letters

According to gpg2's doc/DETAILS:

For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.

gpg1 ("classic") behaves the same (although doc/DETAILS differs).

Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier.

git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side.

Introduce additional status codes E, X, Y, R for ERRSIG, EXPSIG, EXPKEYSIG, and REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance.

Requested-by Alex <[email protected]>

Signed-off-by Michael J Gruber <[email protected]>

Signed-off-by Junio C Hamano <[email protected]>

---
 Documentation/pretty-formats.txt | 3 ++-
 gpg-interface.c                  | 2 +-
 pretty.c                         | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

Documentation/pretty-formats.txt +2 -1

index c28ff2b919..179c9389aa 100644
@@ -146,7 +146,8 @@ endif::git-rev-list[]
 - '%G?': show "G" for a good (valid) signature,
   "B" for a bad signature,
   "U" for a good signature with unknown validity,
-  "X" for a good expired signature, or good signature made by an expired key,
+  "X" for a good signature that has expired,
+  "Y" for a good signature made by an expired key,
   "R" for a good signature made by a revoked key,
   "E" if the signature cannot be checked (e.g. missing key)
   and "N" for no signature

gpg-interface.c +1 -1

index 6999e7b469..e44cc27da1 100644
@@ -35,7 +35,7 @@ static struct {
 	{ 'U', "\n[GNUPG:] TRUST_UNDEFINED" },
 	{ 'E', "\n[GNUPG:] ERRSIG "},
 	{ 'X', "\n[GNUPG:] EXPSIG "},
-	{ 'X', "\n[GNUPG:] EXPKEYSIG "},
+	{ 'Y', "\n[GNUPG:] EXPKEYSIG "},
 	{ 'R', "\n[GNUPG:] REVKEYSIG "},
 };

pretty.c +1 -0

index 39a36cd825..f98b271069 100644
@@ -1236,6 +1236,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
 			case 'U':
 			case 'N':
 			case 'X':
+			case 'Y':
 			case 'R':
 				strbuf_addch(sb, c->signature_check.result);
 			}

Signature · 1 line

2.10.1-520-ge127bfd383

Michael J Gruber

2016-10-10 13:00 UTC #12 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

Junio C Hamano venit, vidit, dixit 06.10.2016 23:43:

Quoted 8 lines

Quoted 6 lines · Junio C Hamano
Quoted 3 lines · Michael J Gruber
Also, I'm open to using another letter for EXPKEYSIG but couldn't decide between 'Y', 'Z', 'K'. 'K' could be confused with REVKEYSIG, I'm afraid. 'Y' is next to 'X' and contained in 'KEY', it would be my first choice.

Quoted 5 lines

Quoted 1 line
Sounds good enough to me. Thanks.
I really do not want to leave too many topics listed in the "What's cooking" report to be in undecided / waiting state. How about squashing this in, with a fully updated log message to replace?

Sorry, this got "lost in vacation". Before that, I was looking for an easy way to test expired signatures, but gpg1 and gpg2 behave somewhat differently in that respect (2 does not allow to create already expired signatures).

Is there anything I should or could do now?

Michael

Quoted 73 lines

-- >8 --
From: Michael J Gruber <[email protected]>
Date: Wed, 28 Sep 2016 16:24:13 +0200
Subject: [PATCH] SQUASH: gpg-interface: use more status letters
According to gpg2's doc/DETAILS:
For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.
gpg1 ("classic") behaves the same (although doc/DETAILS differs).
Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier.
git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side.
Introduce additional status codes E, X, Y, R for ERRSIG, EXPSIG, EXPKEYSIG, and REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance.
Requested-by Alex <[email protected]>
Signed-off-by Michael J Gruber <[email protected]>
Signed-off-by Junio C Hamano <[email protected]>
---
 Documentation/pretty-formats.txt | 3 ++-
 gpg-interface.c                  | 2 +-
 pretty.c                         | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)
Documentation/pretty-formats.txt +2 -1
index c28ff2b919..179c9389aa 100644
@@ -146,7 +146,8 @@ endif::git-rev-list[]
 - '%G?': show "G" for a good (valid) signature,
   "B" for a bad signature,
   "U" for a good signature with unknown validity,
-  "X" for a good expired signature, or good signature made by an expired key,
+  "X" for a good signature that has expired,
+  "Y" for a good signature made by an expired key,
   "R" for a good signature made by a revoked key,
   "E" if the signature cannot be checked (e.g. missing key)
   and "N" for no signature
gpg-interface.c +1 -1
index 6999e7b469..e44cc27da1 100644
@@ -35,7 +35,7 @@ static struct {
 	{ 'U', "\n[GNUPG:] TRUST_UNDEFINED" },
 	{ 'E', "\n[GNUPG:] ERRSIG "},
 	{ 'X', "\n[GNUPG:] EXPSIG "},
-	{ 'X', "\n[GNUPG:] EXPKEYSIG "},
+	{ 'Y', "\n[GNUPG:] EXPKEYSIG "},
 	{ 'R', "\n[GNUPG:] REVKEYSIG "},
 };
 
pretty.c +1 -0
index 39a36cd825..f98b271069 100644
@@ -1236,6 +1236,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
 			case 'U':
 			case 'N':
 			case 'X':
+			case 'Y':
 			case 'R':
 				strbuf_addch(sb, c->signature_check.result);
 			}

Junio C Hamano

2016-10-10 17:58 UTC #13 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

Quoted 6 lines · Michael J Gruber

Sorry, this got "lost in vacation". Before that, I was looking for an easy way to test expired signatures, but gpg1 and gpg2 behave somewhat differently in that respect (2 does not allow to create already expired signatures).
Is there anything I should or could do now?

I dunno. It's your itch.

You can say "I'll need more time to figure out the way to test what I am not testing here, so do not merge it to 'next' yet".

You can also say "This is good enough for now, so go ahead and merge it to 'next'; more detailed tests can be done as follow-up patches if needed".

You can also say "Thinking about it again, there is no strong reason why we need to differentiate EXPSIG and EXPKEYSIG, so don't do this SQUASH and use my original one as-is".

I'd be happy with any of the above and there may be other ones I'd be happy with that I haven't thought of ;-)

Michael J Gruber

2016-10-12 13:04 UTC #14 lore raw

PATCH v3 1/1 gpg-interface: use more status letters

According to gpg2's doc/DETAILS:

For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.

gpg1 ("classic") behaves the same (although doc/DETAILS differs).

Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier.

git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side.

Introduce additional status codes E, X, Y, R for ERRSIG, EXPSIG, EXPKEYSIG, and REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance.

Requested-by Alex <[email protected]>

Signed-off-by Michael J Gruber <[email protected]>

---
v3 incorporates Junios' changes to the commit message, as well as his suggestion how to use an undefined gpghome the way test-lib does. Also, all Y-related changes (including the if in pretty.c).

Testing X, Y, and R from our test scripts is somewhat problematic (some gpg versions do not allow back-dating, and we cannot ship pre-made signatures easily) but I have tested all of them locally.

 Documentation/pretty-formats.txt | 10 ++++++++--
 gpg-interface.c                  | 13 ++++++++++---
 pretty.c                         |  4 ++++
 t/t7510-signed-commit.sh         | 13 ++++++++++++-
 4 files changed, 34 insertions(+), 6 deletions(-)

Documentation/pretty-formats.txt +8 -2

index a942d57f73..179c9389aa 100644
@@ -143,8 +143,14 @@ ifndef::git-rev-list[]
 - '%N': commit notes
 endif::git-rev-list[]
 - '%GG': raw verification message from GPG for a signed commit
-- '%G?': show "G" for a good (valid) signature, "B" for a bad signature,
-  "U" for a good signature with unknown validity and "N" for no signature
+- '%G?': show "G" for a good (valid) signature,
+  "B" for a bad signature,
+  "U" for a good signature with unknown validity,
+  "X" for a good signature that has expired,
+  "Y" for a good signature made by an expired key,
+  "R" for a good signature made by a revoked key,
+  "E" if the signature cannot be checked (e.g. missing key)
+  and "N" for no signature
 - '%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}` or

gpg-interface.c +10 -3

index 8672edaf48..e44cc27da1 100644
@@ -33,6 +33,10 @@ static struct {
 	{ 'B', "\n[GNUPG:] BADSIG " },
 	{ 'U', "\n[GNUPG:] TRUST_NEVER" },
 	{ 'U', "\n[GNUPG:] TRUST_UNDEFINED" },
+	{ 'E', "\n[GNUPG:] ERRSIG "},
+	{ 'X', "\n[GNUPG:] EXPSIG "},
+	{ 'Y', "\n[GNUPG:] EXPKEYSIG "},
+	{ 'R', "\n[GNUPG:] REVKEYSIG "},
 };
 
 void parse_gpg_output(struct signature_check *sigc)

@@ -54,9 +58,12 @@ void parse_gpg_output(struct signature_check *sigc)
 		/* The trust messages are not followed by key/signer information */
 		if (sigc->result != 'U') {
 			sigc->key = xmemdupz(found, 16);
-			found += 17;
-			next = strchrnul(found, '\n');
-			sigc->signer = xmemdupz(found, next - found);
+			/* The ERRSIG message is not followed by signer information */
+			if (sigc-> result != 'E') {
+				found += 17;
+				next = strchrnul(found, '\n');
+				sigc->signer = xmemdupz(found, next - found);
+			}
 		}
 	}
 }

pretty.c +4 -0

index 25efbcac92..d89ca30911 100644
@@ -1232,8 +1232,12 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
 			switch (c->signature_check.result) {
 			case 'G':
 			case 'B':
+			case 'E':
 			case 'U':
 			case 'N':
+			case 'X':
+			case 'Y':
+			case 'R':
 				strbuf_addch(sb, c->signature_check.result);
 			}
 			break;

t/t7510-signed-commit.sh +12 -1

index 6e839f5489..762135adea 100755
@@ -2,6 +2,7 @@
 
 test_description='signed commit tests'
 . ./test-lib.sh
+GNUPGHOME_NOT_USED=$GNUPGHOME
 . "$TEST_DIRECTORY/lib-gpg.sh"
 
 test_expect_success GPG 'create signed commits' '

@@ -190,7 +191,7 @@ test_expect_success GPG 'show bad signature with custom format' '
 	test_cmp expect actual
 '
 
-test_expect_success GPG 'show unknown signature with custom format' '
+test_expect_success GPG 'show untrusted signature with custom format' '
 	cat >expect <<-\EOF &&
 	U
 	61092E85B7227189

@@ -200,6 +201,16 @@ test_expect_success GPG 'show unknown signature with custom format' '
 	test_cmp expect actual
 '
 
+test_expect_success GPG 'show unknown signature with custom format' '
+	cat >expect <<-\EOF &&
+	E
+	61092E85B7227189
+
+	EOF
+	GNUPGHOME="$GNUPGHOME_NOT_USED" git log -1 --format="%G?%n%GK%n%GS" eighth-signed-alt >actual &&
+	test_cmp expect actual
+'
+
 test_expect_success GPG 'show lack of signature with custom format' '
 	cat >expect <<-\EOF &&
 	N

Signature · 1 line

2.10.1.532.gfe29b57

Michael J Gruber

2016-09-30 09:33 UTC #15 lore raw

Re: [PATCH v2] gpg-interface: use more status letters

In reply to Junio C Hamano

Junio C Hamano venit, vidit, dixit 28.09.2016 21:59:

Quoted 14 lines

Quoted 1 line · Michael J Gruber
- Use GNUPGHOME="$HOME/gnupg-home-not-used" just like in other tests (lib).
If you are not using /dev/null, I expected you to do
	. ./test-lib.sh
	GNUPGHOME_saved=$GNPGHOME
        . "$TEST_DIRECTORY/lib-gpg.sh"
and then use
GNUPGHOME="$GNUPGHOME_saved" git log -1 ...

Quoted 7 lines

in the test.
Otherwise, you are not futureproofing your use and only adding to maintenance burden. The gnupg-home-not-used hack may turn out to be a problematic and test-lib.sh may update to point to somewhere else, which will leave your copy still pointing at the old problematic place).

Well, I understood you told me to do what test-lib.sh does.

You obviously wanted me to piggy-bak on test-lib.sh's behavior instead.

I don't know what's more likely to break - the latter relies on test-lib.sh's setting GNUPGHOME to a non existing gpg home, which is something funny to do if you don't even plan to use gpg.

Quoted 9 lines

Quoted 1 line
- Do not parse for signer UID in the ERRSIG case (and test that we do not).
Good.
Quoted 2 lines
- Retreat "rather" addition from the doc: good/valid are terms that we use differently from gpg anyways.
OK.

Quoted 8 lines

Quoted 1 line
+ "X" for a good expired signature, or good signature made by an expired key,
As an attempt to clarify that we cover both EXPSIG and EXPKEYSIG cases, I think this is good enough. I may have phrased the former slightly differently, though: "a good signature that has expired".
I have no strong opinion if we want to stress that we cover both cases, though, which is I think what Ramsay's comment was about.

I'll comment in the reply to his 2nd e-mail....

Michael