From: Junio C Hamano <gitster@pobox.com>
To: Fabian Stelzer <fs@gigacodes.de>
Cc: git@vger.kernel.org, Henning Schild <henning.schild@siemens.com>,
"brian m . carlson" <sandals@crustytoothpaste.net>,
Hans Jerry Illikainen <hji@dyntopia.com>
Subject: Re: [PATCH] gpg-interface: fix for gpgsm v2.3
Date: Thu, 03 Feb 2022 10:55:01 -0800 [thread overview]
Message-ID: <xmqq7dabvkze.fsf@gitster.g> (raw)
In-Reply-To: <20220203123724.47529-1-fs@gigacodes.de> (Fabian Stelzer's message of "Thu, 3 Feb 2022 13:37:24 +0100")
Fabian Stelzer <fs@gigacodes.de> writes:
> gpgsm v2.3 changed some details about its output:
> - instead of displaying `fingerprint:` for keys it will print `sha1
> fpr:` and `sha2 fpr:`
> - some wording of errors has changed
> - signing will omit an extra debug output line before the [GNUPG]: tag
>
> This change adjusts the gpgsm test prerequisite to work with v2.3 as
> well by accepting `sha1 fpr:` as well as `fingerprint:` and allows both
> variants of errors for unknown certs.
OK, so the change is meant to add support for the new behaviour
without deprecating/removing the support for the older one. Good.
> Checking for successful signature creation will omit the leading NL in
> its search string.
I think this is to adjust for "will omit an extra debug output"; as
long as we still ensure that the "[GNUPG:] SIG_CREATED" comes at the
beginning of a line with some other means, I think that is a good
change.
> I am not a user of gpgsm but noticed that the GPGSM test prereq was disabled
> on my runs so i investigated. The `fix` seems rather trivial and I tried to
> test this as thorough as possible. I ran the test suite on machines
> available to me (fedora35, centos8) and did a full CI run on github without
> any issues.
> But if you actually use gpgsm with git please give this a go and let me know
> if I missed anything.
Yup, thanks for a call for help. I am not gpgsm user either and
testing by actual users is very much appreciated.
> @@ -939,7 +939,7 @@ static int sign_buffer_gpg(struct strbuf *buffer, struct strbuf *signature,
> signature, 1024, &gpg_status, 0);
> sigchain_pop(SIGPIPE);
>
> - ret |= !strstr(gpg_status.buf, "\n[GNUPG:] SIG_CREATED ");
> + ret |= !strstr(gpg_status.buf, "[GNUPG:] SIG_CREATED ");
This I am not sure about. I understand that the intention is to
allow this at the beginning of gpg_status.buf, but not to allow the
substring appear in the middle of an otherwise unrelated line. I am
afraid that the new check is a bit too lose for that.
Totally untested but just to illustrate the idea...
gpg-interface.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git c/gpg-interface.c w/gpg-interface.c
index b52eb0e2e0..4238e60dfa 100644
--- c/gpg-interface.c
+++ w/gpg-interface.c
@@ -920,6 +920,7 @@ static int sign_buffer_gpg(struct strbuf *buffer, struct strbuf *signature,
struct child_process gpg = CHILD_PROCESS_INIT;
int ret;
size_t bottom;
+ const char *cp;
struct strbuf gpg_status = STRBUF_INIT;
strvec_pushl(&gpg.args,
@@ -939,7 +940,13 @@ static int sign_buffer_gpg(struct strbuf *buffer, struct strbuf *signature,
signature, 1024, &gpg_status, 0);
sigchain_pop(SIGPIPE);
- ret |= !strstr(gpg_status.buf, "\n[GNUPG:] SIG_CREATED ");
+ for (cp = gpg_status.buf;
+ cp && (cp = strstr(cp, "[GNUPG:] SIG_CREATED "));
+ cp++) {
+ if (cp == gpg_status.buf || cp[-1] == '\n')
+ break; /* found */
+ }
+ ret |= !cp;
strbuf_release(&gpg_status);
if (ret)
return error(_("gpg failed to sign the data"));
next prev parent reply other threads:[~2022-02-03 18:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-03 12:37 [PATCH] gpg-interface: fix for gpgsm v2.3 Fabian Stelzer
2022-02-03 18:55 ` Junio C Hamano [this message]
2022-02-03 20:01 ` Todd Zullinger
2022-02-03 21:38 ` Junio C Hamano
2022-02-03 22:07 ` Todd Zullinger
2022-02-03 22:46 ` Junio C Hamano
2022-02-07 10:52 ` Fabian Stelzer
2022-02-07 16:38 ` Todd Zullinger
2022-02-09 8:33 ` Fabian Stelzer
2022-02-09 16:20 ` Todd Zullinger
2022-02-21 9:22 ` Fabian Stelzer
2022-02-23 4:38 ` Todd Zullinger
2022-02-24 10:06 ` [PATCH 1/3] gpg-interface/gpgsm: fix for v2.3 Fabian Stelzer
2022-02-28 17:57 ` Todd Zullinger
2022-03-02 9:02 ` [PATCH v3 " Fabian Stelzer
2022-03-02 19:18 ` Junio C Hamano
2022-03-03 11:51 ` Fabian Stelzer
2022-03-04 10:25 ` [PATCH v4 " Fabian Stelzer
2022-03-04 10:25 ` [PATCH v4 2/3] t/lib-gpg: reload gpg components after updating trustlist Fabian Stelzer
2022-03-04 10:25 ` [PATCH v4 3/3] t/lib-gpg: kill all gpg components, not just gpg-agent Fabian Stelzer
2022-03-02 9:02 ` [PATCH v3 2/3] t/lib-gpg: reload gpg components after updating trustlist Fabian Stelzer
2022-03-02 9:02 ` [PATCH v3 3/3] t/lib-gpg: kill all gpg components, not just gpg-agent Fabian Stelzer
2022-02-24 10:06 ` [PATCH 2/3] t/lib-gpg: reload gpg components after updating trustlist Fabian Stelzer
2022-02-24 10:06 ` [PATCH 3/3] t/lib-gpg: kill all gpg components, not just gpg-agent Fabian Stelzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7dabvkze.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=fs@gigacodes.de \
--cc=git@vger.kernel.org \
--cc=henning.schild@siemens.com \
--cc=hji@dyntopia.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.