gpg 2.5.x returns one fewer signature result than 2.4.x for expired/revoked keys (ostree test regression)

Sahoo, Pritam Srichandan PritamSrichandan.Sahoo at windriver.com
Wed Sep 16 09:26:11 CEST 2026


Hi NIIBE Yutaka,

Thank you very much - this is exactly what I needed, and it matches what I found (the change being intentional on the gpg/GPGME side).

I will apply the proc-all-sigs flag to ostree (both the verifier and the test as you showed), rebuild, and test it - first standalone, then in our full build on QEMU and on real hardware. I'll report back once I've confirmed it works, and then raise it with the ostree project.

One small thing: I could not open https://dev.gnupg.org/ (including the T7261 ticket you mentioned) - the site did not load for me. Is it possibly down at the moment, or does it require something specific to access? I'd like to read T7261 for the background if I can.

Really appreciate your guidance pointing me to the direct gpg test and to proc-all-sigs.

Best regards,
Pritam Srichandan Sahoo

________________________________________
From: NIIBE Yutaka <gniibe at fsij.org>
Sent: Wednesday, September 16, 2026 12:22
To: Sahoo, Pritam Srichandan
Cc: gnupg-devel at gnupg.org
Subject: Re: gpg 2.5.x returns one fewer signature result than 2.4.x for expired/revoked keys (ostree test regression)

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello,

Thank you very much for your cooperation.

Sahoo, Pritam Srichandan wrote:
> QUESTION
> --------
> Is it intended that, under --batch, gpg 2.5.x no longer emits the EXPSIG
> status line for a good signature whose signature validity has expired?
> gpg 2.4.x still emits it under --batch. If this is intentional we will
> adjust ostree's expectation;

I looked at https://dev.gnupg.org/T7261 and related tickets.  And I also
examined the history of the changes of GnuPG and GPGME.

IIUC, it is intended changes of GnuPG and GPGME.  Other developer(s)
would reply for further information (if it is not intended changes).

For ostree, something like following is needed.

diff --git a/src/libostree/ostree-gpg-verifier.c b/src/libostree/ostree-gpg-verifier.c
index 90aa4815..1dc7674c 100644
--- a/src/libostree/ostree-gpg-verifier.c
+++ b/src/libostree/ostree-gpg-verifier.c
@@ -312,6 +312,8 @@ _ostree_gpg_verifier_check_signature (OstreeGpgVerifier *self, GBytes *signed_da
       goto out;
     }

+  gpgme_set_ctx_flag (result->context, "proc-all-sigs", "1");
+
   gpg_error = gpgme_op_verify (result->context, signature_buffer, data_buffer, NULL);
   if (gpg_error != GPG_ERR_NO_ERROR)
     {
diff --git a/tests/test-gpg-verify-result.c b/tests/test-gpg-verify-result.c
index bfa37596..ea8998f3 100644
--- a/tests/test-gpg-verify-result.c
+++ b/tests/test-gpg-verify-result.c
@@ -130,6 +130,8 @@ test_fixture_setup (TestFixture *fixture, gconstpointer user_data)
       gpgme_data_seek (signature_buffer, 0, SEEK_SET);
     }

+  gpgme_set_ctx_flag (result->context, "proc-all-sigs", "1");
+
   gpg_error = gpgme_op_verify (result->context, signature_buffer, data_buffer, NULL);
   assert_no_gpg_error (gpg_error, NULL);

--


More information about the Gnupg-devel mailing list