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

[Sahoo, Pritam Srichandan]

Hi NIIBE Yutaka,

Thank you - your command-line test led me straight to the cause.

1) ANSWERING YOUR REQUEST (plain --verify, as you asked)
--------------------------------------------------------
Running exactly what you suggested:

    cd ostree/tests/gpg-verify-data
    gpg-2.4.9  --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2
    gpg-2.5.21 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2

the two versions are IDENTICAL: both emit all five signatures, including
the final EXPSIG (expired-signature) line. So on a plain --verify there
is no difference - exactly as you'd expect. That is why this was so hard
to see at first.

2) WHERE THE DIFFERENCE ACTUALLY IS: the --batch flag
-----------------------------------------------------
GPGME (and therefore ostree) does not call a plain --verify; it invokes
gpg with, among others, --batch. The difference appears only when --batch
is added:

    gpg --batch --status-fd 1 --homedir . --verify lgpl2.sig lgpl2

With --batch, gpg 2.4.9 still emits the EXPSIG line, but gpg 2.5.x does
NOT. That single missing status line is why GPGME builds one fewer
gpgme_signature_t, so ostree's test-gpg-verify-result counts 4 instead of
5 and the assertion (count_all == 5) fails.

--enable-progress-filter and --enable-special-filenames make no
difference; adding only --batch is enough to trigger it.

PROOF (status-fd lines, same test data, only the gpg version differs)
---------------------------------------------------------------------
gpg 2.4.9, with --batch:

  [GNUPG:] NEWSIG
  [GNUPG:] GOODSIG   E8B35B6C9A51B00B J. Random User (valid signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] EXPKEYSIG 29C2433005B3B666 J. Random User (expired signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] REVKEYSIG BD9D2A44B7F541A6 J. Random User (revoked signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] ERRSIG    E769699B8E7E729C 1 2 00 1426782907 9 -
  [GNUPG:] NO_PUBKEY E769699B8E7E729C
  [GNUPG:] NEWSIG
  [GNUPG:] EXPSIG    E8B35B6C9A51B00B J. Random User (valid signing key) ...   <-- present

gpg 2.5.0 (and 2.5.21), with --batch:

  [GNUPG:] NEWSIG
  [GNUPG:] GOODSIG   E8B35B6C9A51B00B J. Random User (valid signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] EXPKEYSIG 29C2433005B3B666 J. Random User (expired signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] REVKEYSIG BD9D2A44B7F541A6 J. Random User (revoked signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] ERRSIG    E769699B8E7E729C 1 2 00 1426782907 9 -
  [GNUPG:] NO_PUBKEY E769699B8E7E729C
  (no fifth NEWSIG / EXPSIG)                                                    <-- missing

3) VERSION BOUNDARY (each gpg built from source, same
   libgcrypt 1.11.0 / libassuan 3.0.2 / libgpg-error 1.56 / npth 1.8)
--------------------------------------------------------------------
  gpg 2.4.9  (last 2.4.x)   --batch -> EXPSIG present  (5 signatures)
  gpg 2.5.0  (first 2.5.x)  --batch -> EXPSIG absent    (4 signatures)
  gpg 2.5.21                --batch -> EXPSIG absent    (4 signatures)

So the change appeared with the very first 2.5 release (2.5.0), i.e. at
the 2.4 -> 2.5 branch point, and persists through 2.5.21.

I also confirmed this is independent of GPGME: GPGME 1.24.3 and GPGME
2.1.2 both count 5 with gpg 2.4.9 and 4 with gpg 2.5.21 - the count tracks
only the gpg version, not GPGME.

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; if not, it looks like a 2.5-branch change in
status-line output under --batch.

I can send the complete --status-fd logs from both versions if helpful.

Best regards,
Pritam Srichandan Sahoo

________________________________________
From: NIIBE Yutaka <gniibe at fsij.org>
Sent: Tuesday, September 15, 2026 12:03
To: Sahoo, Pritam Srichandan; 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,

Pritam Srichandan Sahoo wrote:
> Reproduction
> ------------
> - Build ostree (v2026.3) and run tests/test-gpg-verify-result.
> - Note: GPGME resolves which gpg to use via gpgconf, not $PATH.  I made
>   sure "gpgconf --list-components | grep '^gpg:'" pointed at the gpg under
>   test before each run (otherwise the system gpg is silently used and the
>   test falsely passes).

Please run gpg by command line.

    $ cd ostree/tests/gpg-verify-data
    $ YOUR-GPG-1 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2
    $ YOUR-GPG-2 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2

And show us the differences.
--