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

Fixed.

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

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.

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

@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;
             }

I could reproduce this with a ZeitControl OpenPGP v3.4 card, but (as Tobias) not with an (old) Yubikey. Looks like a bug in the card firmware.

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.

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

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

Correct, the fix is not included in beta395.

Notes to self:

• On Windows, libgpg-error's gettext replacement uses the value of LC_ALL, LC_MESSAGE, or LANG (in this order) if set. Otherwise, it uses Windows's GetThreadLocale. (gnupg should probably use the MUI API instead.)
• We should probably force Qt's/KDE's language on gnupg by setting LANG.

Please attach scdaemon logs (created with debug ipc,cardio)

I have no idea how Qt/KDE and how gettext (resp. gnupg's replacement of gettext for Windows) react to Windows's "regional format" setting. It seems that Qt/KDE correctly use English despite German regional format while gnupg uses German.

This can only be tested with the AppImage because on Windows we disable drag&drop of certificates.

Didn't happen on Linux (on my one and only attempt to reproduce). Will have to check on Windows.

Looks like we need a different implementation using Microsoft's groups-of-8 formatting. I'm not sure if for libkleo we should add a format enum to the existing prettyId() function so that we don't have to come up with multiple function names.

That's not surprising. The fix was made after GpgOL 2.6.7. And gpg4win-5.0.0-beta395 still seems to include GpgOL 2.6.6 only.

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.

This was a regression introduced by my fix to make F5 work again and to ensure that it's displayed in the View menu (which itself was a regression of the menu changes made with T7579: Kleopatra: improve menu items).

The changes in libkleo and kleopatra are not included in gpg4win-5.0.0-beta395. Maybe the changes in gpg make the issue less likely. This should still be tested with the complete fix.

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

Backported for VSD 3.4 since this is clearly a regression introduced with T7350 and the fix is zero risk.

Fixed. The check box has been removed from the "S/MIME Validation" tab.

Fixed and backported for VSD 3.4

I merged Tobias's MR

Fixed and backported for VSD 3.4

Fixed for VSD 3.4

Fixed and backported for VSD 3.4