[PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Michał Górny]

GnuPG supports creating signatures consisting of multiple signature
packets.  If such a signature is verified, it outputs all the status
messages for each signature separately.  However, git currently does not
account for such scenario and gets terribly confused over getting
multiple *SIG statuses.

For example, if a malicious party alters a signed commit and appends
a new untrusted signature, git is going to ignore the original bad
signature and report untrusted commit instead.  However, %GK and %GS
format strings may still expand to the data corresponding
to the original signature, potentially tricking the scripts into
trusting the malicious commit.

Given that the use of multiple signatures is quite rare, git does not
support creating them without jumping through a few hoops, and finally
supporting them properly would require extensive API improvement, it
seems reasonable to just reject them at the moment.

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 gpg-interface.c          | 90 +++++++++++++++++++++++++++-------------
 t/t7510-signed-commit.sh | 26 ++++++++++++
 2 files changed, 87 insertions(+), 29 deletions(-)

Changes in v4:
* switched to using skip_prefix(),
* renamed the variable to seen_exclusive_status,
* made the loop terminate early on first duplicate status seen.

diff --git a/gpg-interface.c b/gpg-interface.c
index db17d65f8..efe2c0d38 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -75,48 +75,80 @@ void signature_check_clear(struct signature_check *sigc)
 	FREE_AND_NULL(sigc->key);
 }
 
+/* An exclusive status -- only one of them can appear in output */
+#define GPG_STATUS_EXCLUSIVE	(1<<0)
+
 static struct {
 	char result;
 	const char *check;
+	unsigned int flags;
 } sigcheck_gpg_status[] = {
-	{ 'G', "\n[GNUPG:] GOODSIG " },
-	{ '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 "},
+	{ 'G', "GOODSIG ", GPG_STATUS_EXCLUSIVE },
+	{ 'B', "BADSIG ", GPG_STATUS_EXCLUSIVE },
+	{ 'U', "TRUST_NEVER", 0 },
+	{ 'U', "TRUST_UNDEFINED", 0 },
+	{ 'E', "ERRSIG ", GPG_STATUS_EXCLUSIVE },
+	{ 'X', "EXPSIG ", GPG_STATUS_EXCLUSIVE },
+	{ 'Y', "EXPKEYSIG ", GPG_STATUS_EXCLUSIVE },
+	{ 'R', "REVKEYSIG ", GPG_STATUS_EXCLUSIVE },
 };
 
 static void parse_gpg_output(struct signature_check *sigc)
 {
 	const char *buf = sigc->gpg_status;
+	const char *line, *next;
 	int i;
-
-	/* Iterate over all search strings */
-	for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
-		const char *found, *next;
-
-		if (!skip_prefix(buf, sigcheck_gpg_status[i].check + 1, &found)) {
-			found = strstr(buf, sigcheck_gpg_status[i].check);
-			if (!found)
-				continue;
-			found += strlen(sigcheck_gpg_status[i].check);
-		}
-		sigc->result = sigcheck_gpg_status[i].result;
-		/* The trust messages are not followed by key/signer information */
-		if (sigc->result != 'U') {
-			next = strchrnul(found, ' ');
-			sigc->key = xmemdupz(found, next - found);
-			/* The ERRSIG message is not followed by signer information */
-			if (*next && sigc-> result != 'E') {
-				found = next + 1;
-				next = strchrnul(found, '\n');
-				sigc->signer = xmemdupz(found, next - found);
+	int seen_exclusive_status = 0;
+
+	/* Iterate over all lines */
+	for (line = buf; *line; line = strchrnul(line+1, '\n')) {
+		while (*line == '\n')
+			line++;
+		/* Skip lines that don't start with GNUPG status */
+		if (!skip_prefix(line, "[GNUPG:] ", &line))
+			continue;
+
+		/* Iterate over all search strings */
+		for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
+			if (skip_prefix(line, sigcheck_gpg_status[i].check, &line)) {
+				if (sigcheck_gpg_status[i].flags & GPG_STATUS_EXCLUSIVE) {
+					if (++seen_exclusive_status > 1)
+						goto found_duplicate_status;
+				}
+
+				sigc->result = sigcheck_gpg_status[i].result;
+				/* The trust messages are not followed by key/signer information */
+				if (sigc->result != 'U') {
+					next = strchrnul(line, ' ');
+					free(sigc->key);
+					sigc->key = xmemdupz(line, next - line);
+					/* The ERRSIG message is not followed by signer information */
+					if (*next && sigc->result != 'E') {
+						line = next + 1;
+						next = strchrnul(line, '\n');
+						free(sigc->signer);
+						sigc->signer = xmemdupz(line, next - line);
+					}
+				}
+
+				break;
 			}
 		}
 	}
+	return;
+
+found_duplicate_status:
+	/*
+	 * GOODSIG, BADSIG etc. can occur only once for each signature.
+	 * Therefore, if we had more than one then we're dealing with multiple
+	 * signatures.  We don't support them currently, and they're rather
+	 * hard to create, so something is likely fishy and we should reject
+	 * them altogether.
+	 */
+	sigc->result = 'E';
+	/* Clear partial data to avoid confusion */
+	FREE_AND_NULL(sigc->signer);
+	FREE_AND_NULL(sigc->key);
 }
 
 int check_signature(const char *payload, size_t plen, const char *signature,
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
index 4e37ff8f1..180f0be91 100755
--- a/t/t7510-signed-commit.sh
+++ b/t/t7510-signed-commit.sh
@@ -234,4 +234,30 @@ test_expect_success GPG 'check config gpg.format values' '
 	test_must_fail git commit -S --amend -m "fail"
 '
 
+test_expect_success GPG 'detect fudged commit with double signature' '
+	sed -e "/gpgsig/,/END PGP/d" forged1 >double-base &&
+	sed -n -e "/gpgsig/,/END PGP/p" forged1 | \
+		sed -e "s/^gpgsig//;s/^ //" | gpg --dearmor >double-sig1.sig &&
+	gpg -o double-sig2.sig -u 29472784 --detach-sign double-base &&
+	cat double-sig1.sig double-sig2.sig | gpg --enarmor >double-combined.asc &&
+	sed -e "s/^\(-.*\)ARMORED FILE/\1SIGNATURE/;1s/^/gpgsig /;2,\$s/^/ /" \
+		double-combined.asc > double-gpgsig &&
+	sed -e "/committer/r double-gpgsig" double-base >double-commit &&
+	git hash-object -w -t commit double-commit >double-commit.commit &&
+	test_must_fail git verify-commit $(cat double-commit.commit) &&
+	git show --pretty=short --show-signature $(cat double-commit.commit) >double-actual &&
+	grep "BAD signature from" double-actual &&
+	grep "Good signature from" double-actual
+'
+
+test_expect_success GPG 'show double signature with custom format' '
+	cat >expect <<-\EOF &&
+	E
+
+
+	EOF
+	git log -1 --format="%G?%n%GK%n%GS" $(cat double-commit.commit) >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.19.1

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Junio C Hamano]

Michał Górny <mgorny@gentoo.org> writes:

> GnuPG supports creating signatures consisting of multiple signature
> packets.  If such a signature is verified, it outputs all the status
> messages for each signature separately.  However, git currently does not
> account for such scenario and gets terribly confused over getting
> multiple *SIG statuses.
>
> For example, if a malicious party alters a signed commit and appends
> a new untrusted signature, git is going to ignore the original bad
> signature and report untrusted commit instead.  However, %GK and %GS
> format strings may still expand to the data corresponding
> to the original signature, potentially tricking the scripts into
> trusting the malicious commit.
>
> Given that the use of multiple signatures is quite rare, git does not
> support creating them without jumping through a few hoops, and finally
> supporting them properly would require extensive API improvement, it
> seems reasonable to just reject them at the moment.
>
> Signed-off-by: Michał Górny <mgorny@gentoo.org>
> ---
>  gpg-interface.c          | 90 +++++++++++++++++++++++++++-------------
>  t/t7510-signed-commit.sh | 26 ++++++++++++
>  2 files changed, 87 insertions(+), 29 deletions(-)
>
> Changes in v4:
> * switched to using skip_prefix(),
> * renamed the variable to seen_exclusive_status,
> * made the loop terminate early on first duplicate status seen.

Thanks for sticking to the topic and polishing it further.  Looks
very good.  

Will replace.

> +	int seen_exclusive_status = 0;
> +
> +	/* Iterate over all lines */
> +	for (line = buf; *line; line = strchrnul(line+1, '\n')) {
> +		while (*line == '\n')
> +			line++;
> +		/* Skip lines that don't start with GNUPG status */
> +		if (!skip_prefix(line, "[GNUPG:] ", &line))
> +			continue;
> +
> +		/* Iterate over all search strings */
> +		for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
> +			if (skip_prefix(line, sigcheck_gpg_status[i].check, &line)) {
> +				if (sigcheck_gpg_status[i].flags & GPG_STATUS_EXCLUSIVE) {
> +					if (++seen_exclusive_status > 1)
> +						goto found_duplicate_status;

Very minor point but by not using pre-increment, i.e.

		if (seen_exclusive_status++)
			goto found_duplicate_status;

you can use the expression as a "have we already seen?" boolean,
whic may probably be more idiomatic.

The patch is good in the way written as-is, and this is so minor
that it is not worth rerolling to only update this part.

Thanks.

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

On Sun, 2018-10-21 at 08:57 +0900, Junio C Hamano wrote:
> Michał Górny <mgorny@gentoo.org> writes:
> 
> > GnuPG supports creating signatures consisting of multiple signature
> > packets.  If such a signature is verified, it outputs all the status
> > messages for each signature separately.  However, git currently does not
> > account for such scenario and gets terribly confused over getting
> > multiple *SIG statuses.
> > 
> > For example, if a malicious party alters a signed commit and appends
> > a new untrusted signature, git is going to ignore the original bad
> > signature and report untrusted commit instead.  However, %GK and %GS
> > format strings may still expand to the data corresponding
> > to the original signature, potentially tricking the scripts into
> > trusting the malicious commit.
> > 
> > Given that the use of multiple signatures is quite rare, git does not
> > support creating them without jumping through a few hoops, and finally
> > supporting them properly would require extensive API improvement, it
> > seems reasonable to just reject them at the moment.
> > 
> > Signed-off-by: Michał Górny <mgorny@gentoo.org>
> > ---
> >  gpg-interface.c          | 90 +++++++++++++++++++++++++++-------------
> >  t/t7510-signed-commit.sh | 26 ++++++++++++
> >  2 files changed, 87 insertions(+), 29 deletions(-)
> > 
> > Changes in v4:
> > * switched to using skip_prefix(),
> > * renamed the variable to seen_exclusive_status,
> > * made the loop terminate early on first duplicate status seen.
> 
> Thanks for sticking to the topic and polishing it further.  Looks
> very good.  
> 
> Will replace.
> 
> > +	int seen_exclusive_status = 0;
> > +
> > +	/* Iterate over all lines */
> > +	for (line = buf; *line; line = strchrnul(line+1, '\n')) {
> > +		while (*line == '\n')
> > +			line++;
> > +		/* Skip lines that don't start with GNUPG status */
> > +		if (!skip_prefix(line, "[GNUPG:] ", &line))
> > +			continue;
> > +
> > +		/* Iterate over all search strings */
> > +		for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
> > +			if (skip_prefix(line, sigcheck_gpg_status[i].check, &line)) {
> > +				if (sigcheck_gpg_status[i].flags & GPG_STATUS_EXCLUSIVE) {
> > +					if (++seen_exclusive_status > 1)
> > +						goto found_duplicate_status;
> 
> Very minor point but by not using pre-increment, i.e.
> 
> 		if (seen_exclusive_status++)
> 			goto found_duplicate_status;
> 
> you can use the expression as a "have we already seen?" boolean,
> whic may probably be more idiomatic.
> 
> The patch is good in the way written as-is, and this is so minor
> that it is not worth rerolling to only update this part.
> 

Sure, thanks.  For the record, I've been taught to use pre-increment
whenever possible to avoid copying the variable but I suppose it doesn't
really matter here.  Just a habit.

I'll start working on my next ideas once this is merged and I rebase.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Junio C Hamano]

Michał Górny <mgorny@gentoo.org> writes:

>> Very minor point but by not using pre-increment, i.e.
>> 
>> 		if (seen_exclusive_status++)
>> 			goto found_duplicate_status;
>> 
>> you can use the expression as a "have we already seen?" boolean,
>> whic may probably be more idiomatic.
>> 
>> The patch is good in the way written as-is, and this is so minor
>> that it is not worth rerolling to only update this part.
>> 
>
> Sure, thanks.  For the record, I've been taught to use pre-increment
> whenever possible to avoid copying the variable but I suppose it doesn't
> really matter here.  Just a habit.

Yes, it's a habit many C++ trained people spread; it just looks
weird to see a pre-increment of a "have we done this once?" variable
and end up comparing to see if it is strictly greater than 1
(i.e. have we reached 2 or more?).

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Michał Górny]

Dnia October 20, 2018 11:57:36 PM UTC, Junio C Hamano <gitster@pobox.com> napisał(a):
>Michał Górny <mgorny@gentoo.org> writes:
>
>> GnuPG supports creating signatures consisting of multiple signature
>> packets.  If such a signature is verified, it outputs all the status
>> messages for each signature separately.  However, git currently does
>not
>> account for such scenario and gets terribly confused over getting
>> multiple *SIG statuses.
>>
>> For example, if a malicious party alters a signed commit and appends
>> a new untrusted signature, git is going to ignore the original bad
>> signature and report untrusted commit instead.  However, %GK and %GS
>> format strings may still expand to the data corresponding
>> to the original signature, potentially tricking the scripts into
>> trusting the malicious commit.
>>
>> Given that the use of multiple signatures is quite rare, git does not
>> support creating them without jumping through a few hoops, and
>finally
>> supporting them properly would require extensive API improvement, it
>> seems reasonable to just reject them at the moment.
>>
>> Signed-off-by: Michał Górny <mgorny@gentoo.org>
>> ---
>>  gpg-interface.c          | 90
>+++++++++++++++++++++++++++-------------
>>  t/t7510-signed-commit.sh | 26 ++++++++++++
>>  2 files changed, 87 insertions(+), 29 deletions(-)
>>
>> Changes in v4:
>> * switched to using skip_prefix(),
>> * renamed the variable to seen_exclusive_status,
>> * made the loop terminate early on first duplicate status seen.
>
>Thanks for sticking to the topic and polishing it further.  Looks
>very good.  
>
>Will replace.
>
>> +	int seen_exclusive_status = 0;
>> +
>> +	/* Iterate over all lines */
>> +	for (line = buf; *line; line = strchrnul(line+1, '\n')) {
>> +		while (*line == '\n')
>> +			line++;
>> +		/* Skip lines that don't start with GNUPG status */
>> +		if (!skip_prefix(line, "[GNUPG:] ", &line))
>> +			continue;
>> +
>> +		/* Iterate over all search strings */
>> +		for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
>> +			if (skip_prefix(line, sigcheck_gpg_status[i].check, &line)) {
>> +				if (sigcheck_gpg_status[i].flags & GPG_STATUS_EXCLUSIVE) {
>> +					if (++seen_exclusive_status > 1)
>> +						goto found_duplicate_status;
>
>Very minor point but by not using pre-increment, i.e.
>
>		if (seen_exclusive_status++)
>			goto found_duplicate_status;
>
>you can use the expression as a "have we already seen?" boolean,
>whic may probably be more idiomatic.
>
>The patch is good in the way written as-is, and this is so minor
>that it is not worth rerolling to only update this part.

Please don't merge it yet. I gave it some more thought and I think the loop refactoring may cause TRUST_* to override BADSIG (i.e. upgrade from 'bad' to 'untrusted'). I'm going to verify this when I get home.

>
>Thanks.


--
Best regards, 
Michał Górny

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3775 bytes --]

On Mon, 2018-10-22 at 08:04 +0000, Michał Górny wrote:
> Dnia October 20, 2018 11:57:36 PM UTC, Junio C Hamano <gitster@pobox.com> napisał(a):
> > Michał Górny <mgorny@gentoo.org> writes:
> > 
> > > GnuPG supports creating signatures consisting of multiple signature
> > > packets.  If such a signature is verified, it outputs all the status
> > > messages for each signature separately.  However, git currently does
> > 
> > not
> > > account for such scenario and gets terribly confused over getting
> > > multiple *SIG statuses.
> > > 
> > > For example, if a malicious party alters a signed commit and appends
> > > a new untrusted signature, git is going to ignore the original bad
> > > signature and report untrusted commit instead.  However, %GK and %GS
> > > format strings may still expand to the data corresponding
> > > to the original signature, potentially tricking the scripts into
> > > trusting the malicious commit.
> > > 
> > > Given that the use of multiple signatures is quite rare, git does not
> > > support creating them without jumping through a few hoops, and
> > 
> > finally
> > > supporting them properly would require extensive API improvement, it
> > > seems reasonable to just reject them at the moment.
> > > 
> > > Signed-off-by: Michał Górny <mgorny@gentoo.org>
> > > ---
> > >  gpg-interface.c          | 90
> > 
> > +++++++++++++++++++++++++++-------------
> > >  t/t7510-signed-commit.sh | 26 ++++++++++++
> > >  2 files changed, 87 insertions(+), 29 deletions(-)
> > > 
> > > Changes in v4:
> > > * switched to using skip_prefix(),
> > > * renamed the variable to seen_exclusive_status,
> > > * made the loop terminate early on first duplicate status seen.
> > 
> > Thanks for sticking to the topic and polishing it further.  Looks
> > very good.  
> > 
> > Will replace.
> > 
> > > +	int seen_exclusive_status = 0;
> > > +
> > > +	/* Iterate over all lines */
> > > +	for (line = buf; *line; line = strchrnul(line+1, '\n')) {
> > > +		while (*line == '\n')
> > > +			line++;
> > > +		/* Skip lines that don't start with GNUPG status */
> > > +		if (!skip_prefix(line, "[GNUPG:] ", &line))
> > > +			continue;
> > > +
> > > +		/* Iterate over all search strings */
> > > +		for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
> > > +			if (skip_prefix(line, sigcheck_gpg_status[i].check, &line)) {
> > > +				if (sigcheck_gpg_status[i].flags & GPG_STATUS_EXCLUSIVE) {
> > > +					if (++seen_exclusive_status > 1)
> > > +						goto found_duplicate_status;
> > 
> > Very minor point but by not using pre-increment, i.e.
> > 
> > 		if (seen_exclusive_status++)
> > 			goto found_duplicate_status;
> > 
> > you can use the expression as a "have we already seen?" boolean,
> > whic may probably be more idiomatic.
> > 
> > The patch is good in the way written as-is, and this is so minor
> > that it is not worth rerolling to only update this part.
> 
> Please don't merge it yet. I gave it some more thought and I think the loop refactoring may cause TRUST_* to override BADSIG (i.e. upgrade from 'bad' to 'untrusted'). I'm going to verify this when I get home.
> 

I was wrong.  I'm sorry about the noise.  I've reverified the logic,
and it correct.  That is:

1) for trusted signature, only GOODSIG is emitted and 'G' is returned
correctly,

2) for untrusted signature, GOODSIG is followed by TRUST_* messages,
so line-wise TRUST_* check replaces the 'G' with 'U',

3) for bad signature, only BADSIG is emitted without TRUST_* messages.

Furthermore, GnuPG documentation confirms that TRUST_* is only emitted
for good signatures [1].

[1]:https://github.com/gpg/gnupg/blob/master/doc/DETAILS#trust_

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Duy Nguyen]

On Sat, Oct 20, 2018 at 9:31 PM Michał Górny <mgorny@gentoo.org> wrote:
> +test_expect_success GPG 'detect fudged commit with double signature' '
> +       sed -e "/gpgsig/,/END PGP/d" forged1 >double-base &&
> +       sed -n -e "/gpgsig/,/END PGP/p" forged1 | \
> +               sed -e "s/^gpgsig//;s/^ //" | gpg --dearmor >double-sig1.sig &&
> +       gpg -o double-sig2.sig -u 29472784 --detach-sign double-base &&
> +       cat double-sig1.sig double-sig2.sig | gpg --enarmor >double-combined.asc &&
> +       sed -e "s/^\(-.*\)ARMORED FILE/\1SIGNATURE/;1s/^/gpgsig /;2,\$s/^/ /" \
> +               double-combined.asc > double-gpgsig &&
> +       sed -e "/committer/r double-gpgsig" double-base >double-commit &&
> +       git hash-object -w -t commit double-commit >double-commit.commit &&
> +       test_must_fail git verify-commit $(cat double-commit.commit) &&
> +       git show --pretty=short --show-signature $(cat double-commit.commit) >double-actual &&
> +       grep "BAD signature from" double-actual &&
> +       grep "Good signature from" double-actual
> +'

This test fails on 'master' today for me

gpg: WARNING: multiple signatures detected.  Only the first will be checked.
gpg: Signature made Sat Nov  3 15:13:28 2018 UTC
gpg:                using DSA key 13B6F51ECDDE430D
gpg:                issuer "committer@example.com"
gpg: BAD signature from "C O Mitter <committer@example.com>" [ultimate]
gpg: BAD signature from "C O Mitter <committer@example.com>" [ultimate]
not ok 16 - detect fudged commit with double signature

Perhaps my gpg is too old?

$ gpg --version
gpg (GnuPG) 2.1.15
libgcrypt 1.7.3
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/pclouds/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
-- 
Duy

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

On Sat, 2018-11-03 at 16:17 +0100, Duy Nguyen wrote:
> On Sat, Oct 20, 2018 at 9:31 PM Michał Górny <mgorny@gentoo.org> wrote:
> > +test_expect_success GPG 'detect fudged commit with double signature' '
> > +       sed -e "/gpgsig/,/END PGP/d" forged1 >double-base &&
> > +       sed -n -e "/gpgsig/,/END PGP/p" forged1 | \
> > +               sed -e "s/^gpgsig//;s/^ //" | gpg --dearmor >double-sig1.sig &&
> > +       gpg -o double-sig2.sig -u 29472784 --detach-sign double-base &&
> > +       cat double-sig1.sig double-sig2.sig | gpg --enarmor >double-combined.asc &&
> > +       sed -e "s/^\(-.*\)ARMORED FILE/\1SIGNATURE/;1s/^/gpgsig /;2,\$s/^/ /" \
> > +               double-combined.asc > double-gpgsig &&
> > +       sed -e "/committer/r double-gpgsig" double-base >double-commit &&
> > +       git hash-object -w -t commit double-commit >double-commit.commit &&
> > +       test_must_fail git verify-commit $(cat double-commit.commit) &&
> > +       git show --pretty=short --show-signature $(cat double-commit.commit) >double-actual &&
> > +       grep "BAD signature from" double-actual &&
> > +       grep "Good signature from" double-actual
> > +'
> 
> This test fails on 'master' today for me
> 
> gpg: WARNING: multiple signatures detected.  Only the first will be checked.
> gpg: Signature made Sat Nov  3 15:13:28 2018 UTC
> gpg:                using DSA key 13B6F51ECDDE430D
> gpg:                issuer "committer@example.com"
> gpg: BAD signature from "C O Mitter <committer@example.com>" [ultimate]
> gpg: BAD signature from "C O Mitter <committer@example.com>" [ultimate]
> not ok 16 - detect fudged commit with double signature
> 
> Perhaps my gpg is too old?
> 
> $ gpg --version
> gpg (GnuPG) 2.1.15
> libgcrypt 1.7.3
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Home: /home/pclouds/.gnupg
> Supported algorithms:
> Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
> Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
>         CAMELLIA128, CAMELLIA192, CAMELLIA256
> Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2

Perhaps this is indeed specific to this version of GnuPG.  The tests
pass for me with both 1.4.21 and 2.2.10.  We don't have 2.1* in Gentoo
anymore.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Duy Nguyen]

On Sat, Nov 3, 2018 at 4:32 PM Michał Górny <mgorny@gentoo.org> wrote:
> > Perhaps my gpg is too old?
> >
> > $ gpg --version
> > gpg (GnuPG) 2.1.15
> > libgcrypt 1.7.3
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> >
> > Home: /home/pclouds/.gnupg
> > Supported algorithms:
> > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
> > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
> >         CAMELLIA128, CAMELLIA192, CAMELLIA256
> > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> > Compression: Uncompressed, ZIP, ZLIB, BZIP2
>
> Perhaps this is indeed specific to this version of GnuPG.  The tests
> pass for me with both 1.4.21 and 2.2.10.  We don't have 2.1* in Gentoo
> anymore.

Yeah I have not really used gpg and neglected updating it. Will try it
now. The question remains though whether we need to support 2.1* (I
don't know at all about gnupg status, maybe 2.1* is indeed too
old/buggy that nobody should use it and so we don't need to support
it).
-- 
Duy

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

On Sat, 2018-11-03 at 16:36 +0100, Duy Nguyen wrote:
> On Sat, Nov 3, 2018 at 4:32 PM Michał Górny <mgorny@gentoo.org> wrote:
> > > Perhaps my gpg is too old?
> > > 
> > > $ gpg --version
> > > gpg (GnuPG) 2.1.15
> > > libgcrypt 1.7.3
> > > Copyright (C) 2016 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.
> > > 
> > > Home: /home/pclouds/.gnupg
> > > Supported algorithms:
> > > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
> > > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
> > >         CAMELLIA128, CAMELLIA192, CAMELLIA256
> > > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> > > Compression: Uncompressed, ZIP, ZLIB, BZIP2
> > 
> > Perhaps this is indeed specific to this version of GnuPG.  The tests
> > pass for me with both 1.4.21 and 2.2.10.  We don't have 2.1* in Gentoo
> > anymore.
> 
> Yeah I have not really used gpg and neglected updating it. Will try it
> now. The question remains though whether we need to support 2.1* (I
> don't know at all about gnupg status, maybe 2.1* is indeed too
> old/buggy that nobody should use it and so we don't need to support
> it).

GnuPG upstream considers 2.2 as continuation/mature version of 2.1
branch.  They currently support running either newest version of 1.4
(legacy) or newest version of 2.2 [1].  In other words, this might have
been a bug that was fixed in newer release (possibly 2.2.x).

[1]:https://gnupg.org/download/index.html#text-end-of-life

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

[Duy Nguyen]

On Sat, Nov 3, 2018 at 4:32 PM Michał Górny <mgorny@gentoo.org> wrote:
> Perhaps this is indeed specific to this version of GnuPG.  The tests
> pass for me with both 1.4.21 and 2.2.10.  We don't have 2.1* in Gentoo
> anymore.

Updated to 2.2.8 and the test is passed.
-- 
Duy