Yeah. It's a gpgmepp bug.

FWIW: Okay, gmime is still a wrapper around gpgme. After decryption it has the ability to get the used session key from the gpgme result structure. Thus, I have been on the wrong trail. The actual problem is not gpgme but more GnuPG's use of Libgcrypt or an actual regression in Libgcrypt. Well, Friday 13th.

I can't speak for gpgmpp but for gpgme. And the gpgme manual says:

Any hints where to find the actual crypto code which uses libgcrypt?

Maintainer of the FreeBSD notmuch port/package here. The steps below consistently trigger the problem on FreeBSD 16.0 (unreleased main branch), but there are no problems on FreeBSD 15.0. All my testing was on amd64.

Yeah sure.

In T8101#213455, @werner wrote:

You need to use a current Windows version (and not Windows Server 2016)

Any hints where to find the actual crypto code which uses libgcrypt?

I'm surprised that nobody did detect these problems during the long beta phase...

@thesamesam Thanks a lot.
I managed to replicate the failure somehow (for me, it fails at the importing the key).

I've attached notmuch-bug.log with debug-level guru commented out for gpg-agent:

I can reproduce it using Stuart's script from https://lists.gnupg.org/pipermail/gcrypt-devel/2026-February/006031.html.

Please tell us the information of your environment.
What the versions of gpg and gpg-agent?

Here is an attempt of mine this week:

diff --git a/g10/call-agent.c b/g10/call-agent.c
index 5e13a3e52..8949fad17 100644
--- a/g10/call-agent.c
+++ b/g10/call-agent.c
@@ -3290,13 +3290,14 @@ confirm_status_cb (void *opaque, const char *line)
    message.  If FORCE is true the agent is advised not to ask for
    confirmation. */
 gpg_error_t
-agent_delete_key (ctrl_t ctrl, const char *hexkeygrip, const char *desc,
+agent_delete_key (ctrl_t ctrl, const char *keygrip, const char *desc,
                   int force)
 {
   gpg_error_t err;
   char line[ASSUAN_LINELENGTH];
   struct default_inq_parm_s dfltparm;
   struct confirm_parm_s confirm_parm;
+  const char *keygrip2 = NULL;

We have seen the same thing on amd64 (x86_64) linux: https://bugs.gentoo.org/969501

Please do not use the portable installation - it is dangerous to use it. We will eventually remove this option.

The fix causes a regression. Reported: https://lists.gnupg.org/pipermail/gnupg-devel/2026-February/036218.html

This is not 2.5-only.

Hi, the test is green with rG86baca6e62b3 for both 2038-01-01 and 2105-01-01. Thanks!

For the time being I "upgraded 5.0.1 to 4.4.1 (in the new directory), and then Kleopatra started again.
When upgrading that installation again to 5.0.1, Kleopatra does not start (same error message as before).

Also: When I click "Abort" ("Abbrechen"), the dialog disappeared, but the main windows does not show any progress: Specifically it does not abort.
I had to press "Abort" ("Abbrechen") in the main window; then the upgrade aborted.
When retrying (and confirming that I don't want to install as Administrator (actually I cannot), the proposed target directory still is "C:\Program Files\Gpg4win".
When locating the previous installation directory (it seems it was a subdirectory of %USERPROFIL%\Downloads) the upgrade succeeded, but Kleopatra fails to start.
It want a bin\Qt6Core.dll, bit in the bin directory there is only a Qt5Corew.dll dated " 14. ‎Juli ‎2023, ‏‎13:23:40".
When retrying the installation/upgrade it announced to upgrade 5.0.1, but then did seemingly nothing (I guess as the version was estimated to "be current").
It seems some "reinstall/repair" option is missing.

No, OpenBSD's implementation of POSIX semaphore is different to NetBSD.
(It doesn't support PSHARED=1.)

Possibly, it is related to the NetBSD failure of T8065.
If importing the secret key fails (which invokes gpg-agent), decryption cannot be succeeded.
I will check OpenBSD implementation of POSIX semaphore, if it's similar to NetBSD one.

We forgot to update the tooltip when the default keyserver was removed in gpg 2.5.3. This has already been fixed in the meantime. Sorry for the inconvenience!

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.