works in Gpg4win-5.0.0-beta476

If no logging is running in the background (that's something that often trips me…) on consecutive runs:

Indeed. We would need to add different entries to the context menu for each installation. Given that GpgEX needs to be replaced anyway and we will drop the need for a UI server socket (which is anyway only a trigger and no full communication).

Fixed and backported for VSD 3.4.

Ranking as discussed with @ebo

The root cause is that opening the details reloads the certificate. This triggers a change of the key cache. And that triggers are reload of the group.

This also happens in vsd 3.3.2 and gpg4win-5.0.0-beta413 @ win11

Ok, then this is only an issue in the VSD versions. (I confirmed with a quick test with Gpg4win-5.0.0-beta413)

It would be possible as a workaround in Kleopatra to show any identical entries only once. Saving after that will not add any more entries.

Good catch. My guess is that get_uid_for_sender returns the last matching UID without checking for revocations. The matching was done on the mailbox part only. For reference:

This seems to apply only for non vsd compliant algos. Importing and certifying a

• rsa/brainpool cert results in security level 4
• cv25519 cert results in security level 2

I rechecked: the revoked userid has to match the email address of the sender. Still there's another non revoked userid with the same email address:

Do you mean one of the user-ids has been revoked or the one matching the mail sender?

Best test this with a newer installer than gpg4win-5.0.0-beta413 to avoid the regression with the raw HTML (see T7886#208675).

The error dialog now has a button to show the audit log (named Diagnostics).

@werner sees no reason to define a new status error for everything in gpg. So let's stick with this Kleopatra ticket and adding the "Audit Log"/"Diagnostics" button.

Conclusion: gpg needs to emit a more useful status error. -> subticket

gpgme logs:

2025-11-13 11:22:26 gpgme[28014.6de1]   _gpgme_io_read: check: [GNUPG:] KEY_NOT_CREATED <LF>
2025-11-13 11:22:26 gpgme[28014.6de1]   _gpgme_io_read: check: [GNUPG:] FAILURE gpg-exit 33554433<LF>

where 33554433 means (GPG_ERR_SOURCE_GPG, GPG_ERR_GENERAL) = (GnuPG, General error)

For Kleopatra we need to add an "Audit log" button to the error dialog. And we need to check if gpg is giving us a useful error that we (gpgme) are ignoring or if gpg doesn't throw a useful error. What do the gpgme logs say?

meanwhile it looks like this in Kleopatra, it has now the blue sign but the issue is still the same:

what do we want here? "No public key" would be better that "General error" but then we would still have the same issue as here: T7886: Kleopatra: Enhance error on missing subkey, if set by default-new-key-adsk.

This here is resolved, for timegrids findings see other ticket, the issue is not related to the one from this ticket and no regression, as it turned out. And difficult to trigger.

In T7911#207826, @timegrid wrote:

So, for the current vsd docs (3.3): https://gnupg.com/vsd/kleopatra-settings.html
This would be more correct, if i understood it right?

HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra
HKEY_CURRENT_USER\Software\Wow6432node\GNU\Kleopatra

Thanks for clarification. I added this to the doc enhancement ticket https://dev.gnupg.org/T7911 and set this ticket to invalid.

Test with beta32

I think this is a matter of imprecise documentation.

So, for the current vsd docs (3.3): https://gnupg.com/vsd/kleopatra-settings.html
This would be more correct, if i understood it right?

HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra
HKEY_CURRENT_USER\Software\Wow6432node\GNU\Kleopatra

My point about action restrictions was to add one sentence in the docs section to clarify, what exactly is restricted then.

I think there is a misconception about Action Restrictions. Yes, they exclusively disable the corresponding action, i.e. the action is hidden (from menus and toolbars) and the keyboard shortcuts won't do anything. Action restrictions are no means to disable certain functionality as a whole like "Add User ID". Just because somebody listed all available actions in the documentation (which is rather questionable in my opinion) doesn't mean that it makes sense to remove those actions. Maybe only relevant/important actions should be listed so that the readers are not drowned in a huge list of largely irrelevant settings.

For settings in VSD 3.x best look at https://dev.gnupg.org/source/kleo/browse/gpg4win%252F24.05/src/kcfg/settings.kcfg (gpg4win/24.05 branch).

This looks questionable:

HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra
HKEY_CURRENT_USER\Software\GNU\Kleopatra

Either both keys use the 32-bit compatibility path Wow6432node\ or both keys don't. 32-bit builds (like VSD 3.x) will use the compatibility path (without being aware of the redirection). 64-bit builds (like Gpg4win 5.x) don't use it. Since Windows mirrors some settings between both registry paths it may not matter.

Allright, then the dash notation for those two groups are intended and the documentation needs to be adjusted

I suspect that the author of the documentation confused the (internally used) "name" of the settings with the "key" that's used in the config files (and the registry). For reference: Many settings are defined in https://dev.gnupg.org/source/kleo/browse/master/src/kcfg/settings.kcfg .

Note: The tab name is displayed after restart, if

• The tab was renamed manually
• The filter was changed (leading to a rename)

And when I switch of read-as-plain, both testmails in the inbox are displayed as expected but one of the ones from the sent-folder has an empty body:

This is a gif to show the UX. It is to complicated for words…

with 3.3.90.29-Beta:

Then I don't see how we can avoid this. It should be easy to reproduce this with gpgconf alone if you know how to use --change-options manually. Simply set the LDAP server that's already configured in the global config file.

gpgconf does not know about the global config files. Nor does it known about things like gpg.conf-2 etc.

Looks good to me on gpg4win-5.0.0-beta395 @ win11

I guess this is easy to explain:

1. gpgconf/gpgme reads the LDAP server from the global config
2. You add a second LDAP server (I don't think it matters if it's the same as the one from the global config or different one)
3. When you save the LDAP server then gpgme/gpgconf writes both LDAP servers to the local config
4. When you now read the LDAP servers you get one from the global config and two from the local config