Has now been backported to be released with 2.2.53

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;

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

This is not 2.5-only.

Sorry for the ambiguity. The request was only about mentioning (bpX) for the first two choices, not to add more combinations.

Although it is technicall possible to use all combinations, we should limit in the menu them to those as listed above. Too many algorithms pose an interop problem. Thus we provide brainpool because it is required in Germany and the two IETF curves for the general internet (for those who are playing mitigation against against physical experiments).

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.

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!

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.

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.

This string comes from the Windows API and thus it is a Windows bug. It maye take some decades until this get fixed but at least they have meanwhile sfxed the "Westeuropäische Zeit" zu the correct "Mitteleuropäische Zeit" - Modulo Umlaut problems.

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

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?

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.