In T7886#208534, @werner wrote:

FWIW, GnuPG uses this Windows API

[...]

but can be overridden with the LC_ALL, LC_MESSAGES, or LANG envvars by setting them to the usual xx_XX value.

GPG output seems to depend on Regional Format.

This is fixed.

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

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

works with Gpg4win-5.0.0-beta395, too

as far as i can tell (and remember), I haven't implemented Ingo's suggestions. I'm putting the ticket back in the backlog and on my TODO list

@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.

Yes, we now plan to add an "Show Audit Log" Button (or is it "Diagnostics" in this case?). But we are not sure if this is enough.

it is probably not worth the effort to backport this

Note: We would need to handle possibly diverse error cases. A network share could be configured e.g. to not allow deletion for the user so that the temporary file can not be deleted.

What about adding a "show gnupg log" button as we have in other dialogs?

I am currently working on backup/restore of Kyber keys. The error message will go away.

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?

Backported for VSD 3.4.

Fixed (as far as possible).

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 needs to be fixed in Kleopatra because we create our own config dialog using a generic page dialog.

The second problem with the wrong tab order is also fixed.

Removing VSD 3.4 tag. I don't intend to backport the changes in Qt 6 to Qt 5.

In T7588#207022, @timegrid wrote:

• unselected radio/checkboxes are a bit hard to see and worse to distinguish

In T7588#207022, @timegrid wrote:

• calendar (weekend days: general/selected/hover on dark background)

The problem with Enter has been fixed upstream. I have added a patch with this fix.

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.

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 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 .

Fixed. Kleopatra and the GnuPG System configuration and error messages coming from GnuPG should now always use the configured Windows display language regardless of the Preferred languages or the Regional format. (GnuPG on the command line will still use the Regional format.)

Note: The tab name is displayed after restart, if

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