Fixed in 1.12.1.

Fixed in 1.12.0.

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.

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.

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

@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?

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

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.

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

Will go into 1.12.1

Thanks. Will go int the next version.

Thank you, that did indeed fix the problem!

Does following patch help?

Fixed in: rC2c1d41b5f86f: fips,cipher: Fix the regression with disabled public-key algo.

Re-opened because a regression is reported.

Backports have been done in both (1.10/1.11) branches.

Okay, let's backport this.

gpgrt 1.57 will come with gpgrt_fconcat. This can be used to get the sysconfig in a portable way:

@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.

Scute fixed in rSc3dc9c581631: w32: Use CSIDL_COMMON_APPDATA if available.

Okay, forward porting that patch is the easiest solution. Actually this is not enough: Users of Libgcrypt also need to make sure that the new sysconfig dir has the right permissions. That's a part for the installer and concrete ACLs may differ.