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

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)

The language settings of Windows have strange influence on Kleopatra and GnuPG.

Werner said we leave it as is for vsd3.3.3 and only change reading order of the configs for the change to the next mayor release.
So I retag this ticket for gpd5x. timegrid has made a separate ticket for updating the documentation.

Fixed.

I'm fixing this in Kleopatra similarly to gpg-card.

VS-Desktop-3.3.90.31-Beta shows no warning any more for the export of a newly generated key.

So this means, the order in the description should be implemented, right?

That's what gpg-card url --clear does

if (!strcmp (argstr, "--clear"))
  url = xstrdup (" "); /* No real way to clear; set to space instead. */

Yes, by definition an immutable group doesn't allow any changes for that group. Don't mark a group as immutable if you want to allow changes.

The [KDE Action Restrictions][$i] in XDG_SYSTEM_DIRS/kleopatrarc prevents any changes within the whole group afterwards.
I guess, this is intended by defining an "immutable group", but i doubt that we want to prevent admins to change those settings?

So, regarding the minor version change: the change of order seems not critical (as there was no settings file before), but the introduction of the settings file might be.

I verified, that both in vsd 3.3.2 and vsd 3.3.3 beta90.29 the current implementation is

And we shouldn't change the precedence in a minor release, I believe.

The configuration readout order still needs to be specified/fixed.

Looks good to me on vsd-3.3.3-beta90.29 @ win11

So we need to find out what gpg-card url --clear does to avoid the card error for the ZeitControl cards.

An new suggestion for the wording without prior reading of the above texts to get a fresh view.
But in German ...

@werner Proposed patch for gpg:

diff --git a/g10/export.c b/g10/export.c
index 5dcb9c665..908a6b6a0 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -1961,7 +1961,9 @@ do_export_one_keyblock (ctrl_t ctrl, kbnode_t keyblock, u32 *keyid,
           if (strchr (hexgrip, ','))
             {
               log_error ("exporting a secret dual key is not yet supported\n");
-              return gpg_error (GPG_ERR_NOT_IMPLEMENTED);
+              err = gpg_error (GPG_ERR_NOT_IMPLEMENTED);
+              write_status_error ("export_keys.secret", err);
+              return err;
             }

Move Notepad and Smartcards from View to Tools (entries are additionally still in view)

Backported for VSD 3.4 and VSD 3.3.

I couldn't reproduce the problem because I had apparently told Kleopatra in the past "Do not ask again". :/

I think this problem just occurs because the secret key of the ADSK is available. Otherwise, Kleopatra wouldn't know whether the ADSK is stored on a smart card and therefore wouldn't erroneously take a non-card key for a card key.

Well, in the audit log the output of gpg is shown, nothing Kleo can do there, I believe.
But we need to talk about what still needs to be / can be implemented on the Kleo side.

The API documentation of gpgme has been improved. And Kleopatra no longer tries to read the private key files of subkeys using combined algorithms (like Kyber+some curve) because (as of now) such keys are not stored on any smart cards (that are supported by GnuPG).

New ticket for the remaining issue.

gpgme log for key creation and export with warning for VSD-Beta29

This is also the case in the latest VSD-Beta29

I could reproduce it with the same version (on WIN10).

Right, gpg CLI output depends on it, too.

Does that mean that it is not possible to close the message automatically if changes are made in a) the text field or b) the encryption settings in the right pane?

Please attach the output of gpg -K --with-colons

For the open issue I have created T7890: Kleopatra: Icon sidebar in configuration dialog is missing an accessible name because it needs to be fixed upstream (in KDE Frameworks).