We already did this for Libgcrypt 1.8 but take care that an installer includig Libgcrypt should run something like

The question is who shall correct the wrong encoding of notation data (assuming it is flagged as human readable). Escaping is a solution but needs a lot of extra bytes.

It is not an ADSK issue. The problem is that the new subkey has not been entered into the fingerprint table and can thus not be found.

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

I think at line 82 we should use xtrymalloc as always in gpg-agent. xtrymalloc expands to gcry_malloc.

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.

Fixed in 2.5.13.

@onickolay The change was originally introduced for PQC stuff. And then, we applied use of KEM API (of libgcrypt) also for ordinary ECDH, so, it affected ordinary ECDH encryption (between 2.5.9 and 2.5.12).
The intention is follow the recommendation of use of KEM. IIUC, next FIPS certification will require use of KEM, possibly.

@gniibe @werner Is this change is supposed to work only for PQC stuff, or non-PQC as well, and where it is defined? As it breaks RNP tests for ordinary ECDH encryption (as it looks up for 0x40 prefix). It's not a problematic to update our code, but just want to know the reason for that.

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

In gpg4win-4.4.1 it works too.

Note: In the current vsd beta (29) it works (pinentry for the next key is opened):

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

Note: It works with gpg-card url --clear.

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

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.

Thanks for the quick response. I can confirm the patch works in my setup.

Thank you for your report.

Note that:
If we consider backporting this to 1.10/1.11 branch, we also need to apply: rCdef1d4ea8f66: random:jent: Fix build with address sanitizer.

@jukivili
Thanks for your feedback.

There's GCRYPT_IN_ASAN_TEST environment variable check in tests/t-secmen.c and tests/t-sexp.c. Are those check needed after this change? Could they be removed?

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