@werner I can confirm that we've tested the patch and it seems to fix the issue in our setup.

Applied to master to be release with 2.5.19.

Here is my attempt for fixing the de-vs compliance check when verifying a signature:

2.2.53 was released wit VSD 3.3.6

Can you please test the patch below in your environment. That would be helpful.

Note: The invalid revocation certificate: Bad signature - rejected line is also shown on vsd 3.3.4, gpg 2.2.53 @ win10 (but revocation works).

I applied the keyboxd part for SETEPHEMERAL command, as it doesn't break anything.

Here is an attempt to fix the client side:

To clarify, the state in Kleopatra Ingo described a year ago has changed, with T7579: Kleopatra: improve menu items the refresh option in the Tools menu was removed. Both actions to update certificates - in the context menu and in the details - are/work the same.

Removing kleopatra tag since Kleopatra already does what's requested.

But the original patch rG1b4ac98de7db: agent: Accept a trustlist with a missing LF at the end. was not working to allow missing newlines in gpg4win-5.0.0 @ win11?

Pushed the change of gpgme: rM8b89678aed6d: Fix passphrase cancel handling.

That change is too complex for just getting a proper error message. The original patch covers the most common case.

This should also be fixed in 2.2 and 2.4 (if neccessary)

It seems that pinentry-curses defaults to "OK".
(my branch for GTK-4, same.)

Cancel (in pinentry-qt) was made default with rP291089ed476d75c71ef1984a7c081d27e357437d. Marc's ChangeLog entry was

• qt4/main.cpp: (qt_cmd_handler) make Cancel the default button for CONFIRM

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.