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.

Has now been backported to be released with 2.2.53

Yeah sure.

In T8101#213455, @werner wrote:

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

keys.openpgp.org has two problems: a) it is a centralized service due to the requirement to confirm mail addresses. b) For non-confirmed keys it returns broken OpenPGP keys (ie. without a user id and thus without important information). For these reasons and the general problems with the keyserver-(networks) there is no more default.

Shall we change log_* functions also emit message to console, when file/socket is specified?

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.

I also updated the software page. Thanks for the hint.

That was fast, thank you.
Can you please update https://www.gnupg.org/related_software/gpa/ as well, or is there a better page to use as a homepage link for gpa?

Done. See T7449

Noteworthy changes in version 0.11.1 (2026-02-12)

This ticket is now obsolete, as we will force the setting of autoencryptUntrusted=0 via the registry in Ticket T8090

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

This is not 2.5-only.

Maybe we could show instead the text "No keyserver is configured."? Need not be in the same place. This would also be helpful in the other case, where you go to the search via "Lookup on Server".

Make all table column headings accessible (see Update 2025-10-27).

Forget my comment above. Or consider it as the "before" part of the task description…

Fixed and backported for VSD 3.4.

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

The settings should work again. They are described at https://docs.kde.org/trunk_kf6/en/kleopatra/kleopatra/admin.html#admin-certificate-request-wizard-keys , but note that the documentation is severely outdated. Note that those settings are not officially supported by GnuPG (VS-)Desktop (see https://gnupg.com/vsd/kleopatra-settings.html).

Should work now.

This was fixed in Qt 6.10.0 by adding compatibility code that's "hidden" behind a compiler flag, i.e. we just need to enable this compiler flag. See https://codereview.qt-project.org/c/qt/qtbase/+/629255 for details.

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).