That is actually more complicated than I initially though. The reason is that expired is used like a trust level:

Applied to master.

I created a branch https://dev.gnupg.org/source/gnupg/history/gniibe%252Ft8048 and pushed all changes (including keyboxd-patch-2026-04-23).

Enhance keyboxd to have new command for what keybox_set_flags does.

with VS-Desktop-3.3.97.11-Beta (GnuPG 2.2.54-beta9)

Still does not work on vsd-3.3.7-beta90.9 @ win10. Essentially the same behavior as before:

Reporter has tested 2.5 - the code in 2.2 is identical; no need for separate testing

I reworked the reading using our dedicated line reading functions which is used at other places. Extra benefit is that the code now also prints a status line ERROR which gives information on the first faulty line. Thus gpg-connect-agent listtrusted /bye can be sued to quickly check for errors without configuring a log file.

Without GpgsmCompatibility set and with the trust in the Root-CA established in the global trustlist file (the local one does not work for vs-complicane without GpgsmCompatibility=de-vs-trustlist , as expected), the compliance of a signature or decryption is now shown correctly and in accordance with the certificate status shown in Kleopatra. If the Root-CA is only trusted locally, the certificate and the signature are shown as "certified" resp. "not-compliant".
In short: everything works as expected if GpgsmCompatibility is not set.

auto-key-upload should not be triggered on revocation cert import, so everything seems fine.

Looks good to me on vsd-3.3.7-beta90.9 @ win10.

Note: Keyserver has to start with ldap: for this to work, otherwise it is silently ignored.

In general looks good to me on vsd-3.3.90.9 / gpg 2.2.54-beta4.

with GnuPG-VS-Desktop-3.3.90.9-Beta-Standard gpgsm now never shows the line [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23. Therefore Kleopatra always shows "not VS compliant" now on verification and decryption. Even though the certificate is shown a VS-compliant in the list an when encryping:

gnupg22 received this patch meanwhile: rG7bc969d388086b4f3aeee3c5389b7baf055689d7

@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