According to the ML @gniibe tried to replicate the problem without success.

I guess the test fails because one cannot create a key with an expiration date before the current date. And the test tries to create a key which expires on 2038-01-01 which will fail if the test is run on 2038-01-01 or later. The easiest fix would be to disable the test cases if the current date is past 2038-01-01.

Okay, then I set the ticket to Testing.

Unfortunately, this was run on x86_64 and also other 64 bit archs.

Is that on a 32 bit machine or 64? The latter would be a problem for 32 bit with 32 bit time-t I'd say: we won't fix it.

At least for an expired data signature I would suggest to have an info button to further expliah this. Maybe to a FAQ or KB article. The case is too rare that we should not discuss endlessly the pros and cons of expiring signatures. I hope that Kleo does not provide an option to crerate such a signature.

Your fix is okay.

AFAICS all conditions are protected by isascii(3) which

After serveral clever attempt, I've settled to this simple workaround that seems working despite being quite inefficient: if you don't find any key with gpgme_op_keylist_next and gpgme_err_code(err) == GPG_ERR_EOF on a ctx with keylist mode set to GPGME_KEYLIST_MODE_LOCATE, try again (even on the same context), after

Looking to workaround this issue, I've noticed something that might be useful during debug.

@werner: Shall we backport the fix to the gpgme-1.24-branch or do we just add a patch to gpg4win's gpg4win-4-branch and/or vsd-3.3-branch?

I have verified (by locally applying the change to a Gpg4win 4 build) that ifdef'ing-out the above hack for Windows builds fixes the display issue.

The capping of the date seems to be caused by this workaround/hack in gpgme's _gpgme_parse_timestamp

/* Fixme: We would better use a configure test to see whether
   mktime can handle dates beyond 2038. */
if (sizeof (time_t) <= 4 && year >= 2038)
  return (time_t)2145914603; /* 2037-12-31 23:23:23 */

Now an expired signature with certified key is reported like this:

Backported for VSD 3.4

Fixed. Kleopatra now looks for programs given as plain name (i.e. without any path) first in the GnuPG installation path (as reported by gpgme) and then next to the kleopatra executable. If the program is found at neither location it is run as-is.

For "expired signature with certified key" I believe green with check mark is a too positive. Should be a warning, too.

I found two issues in libgpg-error for spawning functions.

POSIX documentation never says that PSHARED=0 prevents sharing among processes. In my opinion, it still conforms to POSIX even when a PSHARED=0 semaphore can be shared between parent and child processes.

Will go into 1.12.1

Additionally, the de-vs-compliance filters are no longer show in non-compliant installations like Gpg4win.

I've tried the new patch in my environment, and it fixes the gnupg HEAD self tests as well. Thank you!

In tests/migrations, (unlike tests/openpgp and tests/cms), the tests do not prepare gpg-agent, but it is gpg which invokes gpg-agent if needed.
Because of that, on NetBSD (where POSIX semaphore has a different semantics), it hangs with gpg --list-secret-key, when gpg tries to spawn the gpg-agent process.
In the old code of 2.4, it simply ignore the npth_protect and npth_unprotect when calling fork to spawn a process.
New code in libgpg-error cares about npth_protect and npth_unprotect but it was not sufficient; We need to care about NetBSD's semantics. Child process should not call npth_protect. With shared semantics, child process's calling npth_protect affects to cause parent process: it hangs.

@wiz Thank you for your quick feedback.

Thank you for the patch. I've tried it in my environment, and gnupg 987c6a398a9505399b2c25a775d4b625753bc962 passes all its self-tests for me now!

Thank you, that did indeed fix the problem!

Oh yeah, the mentioned patch is bogus because it assumes that fgets has already set the eof flag while reading the last line. This seems not to be the case.

This is actually a (known) bug in gpg, i.e. gpg --delete-secret-and-public-key PRIMARY_KEY_FPR only deletes the public key for keys without primary secret key.

Makes me wonder why they think they can use such a common word for a typedef without risking name clashes everywhere. Luckily, the helper function single is superfluous nowadays so that we can easily avoid the name clash.

Thank you for the log.

CVE-2026-24882 has been assigned to this issue.

I added the gpgsm log output (same error as in the gpg log)

Ah, thanks for the pointer, I did not expect gpgsm to behave differently here. Then it's probably intentional and I'll close this as invalid.

The gnupg manual (page 113) mentions:

Thank you for looking at this.
I'm testing with gnupg git head as of today, please let me know if you prefer 2.5.17 instead.

Thank you for your report.

works in vsd 3.3.5

I bisected it and found the commit that introduced this test failure:

@mmontkowski, use this as string:

In the same environment, 2.4.9 passes its self tests.
I've reverted the update in pkgsrc until this can be resolved.

The previous pkgsrc version was 2.4.9. However, I've just tested 2.5.14 and saw the same behaviour (so I guess there is no point in testing 2.5.16).

Do you remember wether you had the same problem also with 2.5.14 or 2.5.16? Or can you test with these versions? Which version of libgpg-error are you using?

When I kill the gpg process, I see:

("/tmp/security/gnupg2/work/gnupg-2.5.17/g10/gpg" --no-permission-warning --no-greeting --no-secmem-warning --batch "--agent-program=/tmp/security/gnupg2/work/gnupg-2.5.17/agent/gpg-agent|--debug-quick-random" --list-sec
ret-keys) failed: gpg: starting migration from earlier GnuPG versions

My actual plan is to rework the imp[ort/export of secret keys to gpg-agent. Right now gpg-agent has knowledge of OpenPGP for import/export. This is not good and the required conversion should be moved to a helper tools for easier testing and to have this out of the gpg-agent process. For Kyber we right now don't use any conversion mut store the secret keys in gpg-agent's native format. Thus the passphrase is not necessary. We need to figure out why we have this problem here.