I consider again about Ben's change. It could be simply support of the detection of the cancel situation where gpgme should return GPG_ERR_CANCELED (not related to single cancellation vs. whole cancellation).

I can't remember why Ben introduced the new status. OTOH, I wish that the Qt-Pinentry also emits a button_info line for closing the window. Normal users don't notice the difference but if you have a lot of private keys and you get a mail which has only hidden recipients the full_canceled is pretty useful. Also for other tasks like allow-mark-trusted: On Windows with the qt-pinentry I am always cursing about this but on my box I only need to close the pinentry window to get a fully_canceled

I investigated the introduction of STATUS_CANCELED_BY_USER and GPGME_STATUS_CANCELED_BY_USER:
rG31e47dfad0f4: gpg: Add canceled status message.
rM35ca460019ea: Parse STATUS_CANCELED_BY_USER.

I stand partially corrected. Apparently, pinentry-efl also sets close_button. For Gpg4win that's irrelevant because we ship pinentry-qt which doesn't have this IMHO contra-intuitive behavior (and pinentry-w32 where I don't know how it behaves).

pinentry-tty and pinentry-curses support GPG_ERR_FULLY_CANCELED by Ctrl-C. But other pinentry implementations have no support (only GPG_ERR_CANCELED).

I'd also like to point out that changing the error code from GPG_ERR_CANCELED to GPG_ERR_FULLY_CANCELED could cause regressions in applications.

How do you want to decide whether to show two "Cancel" buttons? How would you call those two "Cancel" buttons? For decryption I can imagine that for example "Try Next Key" and "Cancel Decryption" (or even just "Cancel") would make clear what happens.

If this definition is OK

@bernhard Thank you for the link.

In T8076#215372, @werner wrote:

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

What is an "incomplete team key" - a standard offline secret key (i.e. one with only secret subkeys)?

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

I guess the behavior changed with gpg 2.4, i.e. "With gpg 2.4 (or later), ..."

why gpg 2.4? Don't you mean 2.6? I'll add the proper 2.6 tag for avoiding confusion

Right, looks good to me now on gpg4win-5.0.2-beta2 @ win11:

Possibly, it was the same cause as T8052 (the bug in libgpg-error spawning a process).

I looked at sm/keydb.c:keydb_set_ephemeral function. It says:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

• first manual gpg -K and gpgsm -K displays the correct output now
• the loop ran without a hang for 50 times

In T8029#212310, @werner wrote:

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.

I found that it's not that simple to accept the case of no newline at the end.
Because we need to handle the edge case where no newline occurs at the maximum buffer length, too.
It's something like the following.

Also applied to 2.4 branch.

I haven't tested it, but it looks good

Fixed in libgpg-error 1.59.

Like this patch?

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 ignores about the npth_protect and npth_unprotect sequence when calling fork to spawn a process.
New code in libgpg-error cares about npth_protect and npth_unprotect sequence 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 in the description (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.

Option works in Gpg4win-5.0.1 with GnuPG 2.5.17