a7d2f7e53e
The output of gpgsm changed slightly in gnupg-2.3, causing the git tests for x509 signatures to be skipped. Update the tests to use the machine-parseable --with-colons output. It also appears that we need to reload the gpg-agent in order to pick up the changes the test library makes to the trustlist.txt file. It might be better to store that file with the other gpg files in the test suite rather than generating it. While we're at it, reload all the gpg components rather than just gpg-agent. Adjust the earlier gpgconf kill to use the 'all' keyword as well. Next up, gpgsm removed a debug line from it's output which exposes a problem in git's gpg-interface code. The git code presumes that the '[GNUPG:] SIG_CREATED' line will follow a newline. That is no longer true. The debug line was removed from GnuPG in a6d2f3133 (sm: Replace some debug message by log_error or log_info, 2020-04-21). Finally, a minor bug in gpgsm causes the error message returned when a certificate is not found to differ from previous versions¹. Extend the grep pattern in the test suite to catch both error messages. ¹ https://lists.gnupg.org/pipermail/gnupg-devel/2021-November/034991.html
49 lines
1.9 KiB
Diff
49 lines
1.9 KiB
Diff
From edb5eafc9945b2d400c2d777a9750cee06ab500f Mon Sep 17 00:00:00 2001
|
|
From: Todd Zullinger <tmz@pobox.com>
|
|
Date: Sat, 27 Nov 2021 02:55:47 -0500
|
|
Subject: [PATCH] gpg-interface: match SIG_CREATED if it's the first line
|
|
|
|
In `sign_buffer_gpg`, "\n[GNUPG:] SIG_CREATED " in the gpg status output
|
|
is used to signal a successful signature. This fails if "SIG_CREATED"
|
|
is the first line in the gpg output, as is the case with `gpgsm` in
|
|
GnuPG 2.3.
|
|
|
|
In earlier versions of GnuPG, there was a debug line in the `gpgsm`
|
|
output which allowed the check in `sign_buffer_gpg` to work. This debug
|
|
line was removed from GnuPG in a6d2f3133 (sm: Replace some debug message
|
|
by log_error or log_info, 2020-04-21).
|
|
|
|
The result is the `gpgsm --status-fd` output for a signing operation
|
|
starts with "[GNUPG:] SIG_CREATED" and we mistakenly report "gpg failed
|
|
to sign the data" to the user. The `gpg` command has other `[GNUPG:]`
|
|
output for signing operations, so it is not affected by this issue.
|
|
It's best not to rely on something as subtle and out of our control as
|
|
the order if the gnupg status messages.
|
|
|
|
This likely went unnoticed because the GPGSM test prereq was failing for
|
|
a different reason with GnuPG 2.3. No tests failed, they were simply
|
|
skipped due to the missing GPGSM prereq.
|
|
|
|
Signed-off-by: Todd Zullinger <tmz@pobox.com>
|
|
---
|
|
gpg-interface.c | 6 ++++++
|
|
1 file changed, 6 insertions(+)
|
|
|
|
diff --git a/gpg-interface.c b/gpg-interface.c
|
|
index 3e7255a2a9..d179dfb3ab 100644
|
|
--- a/gpg-interface.c
|
|
+++ b/gpg-interface.c
|
|
@@ -859,6 +859,12 @@ static int sign_buffer_gpg(struct strbuf *buffer, struct strbuf *signature,
|
|
|
|
bottom = signature->len;
|
|
|
|
+ /*
|
|
+ * Ensure gpg_status begins with a newline or we'll fail to match if
|
|
+ * the SIG_CREATED line is at the start of the gpg output.
|
|
+ */
|
|
+ strbuf_addch(&gpg_status, '\n');
|
|
+
|
|
/*
|
|
* When the username signingkey is bad, program could be terminated
|
|
* because gpg exits without reading and then write gets SIGPIPE.
|