Please check the 2020 certificate by using the details dialog. Has it a valid encryption subkey?

it was noted that this also affects other ML hosted there like those of freie-software.org

No sure, you could also consider the is_cardkey flag to mean that a secret key might be available. FWIW, GPA sets it internal secret key flag based on the type of listing done; thus I see no problem if you want to change the behaviour.

Ours are even newer (5.4.3). Did you the Yubico tools to switch to curve443?
In any case, is it possible that you apply my fix and test again?

Your Yubikey's firmware version is 5.2.7 - let me see what versions we have in stock to test my fix.

When we implemented this first, Libgcrypt had no appropriate KDF support. I recall that I considered to change this but it turned out the for 2.2 the changes are too large. For 2.3 we will consider such a change.

I am not sure about the crash but the unknown curve is
1.3.6.1.4.1.11591.15.1.2 which seems to be a GNU OID for curve448

What I would do in this case is to stop the gnupg daemon amd anything whiuch might start them and run scdaemon under valgrind.

FWIW, the original idea with gpgscm was to provide code which does no rely on any gpg stuff so it can be merged back into upstream. I am not sure whether this still makes sense.

Please try a decent version of Gpg4win - we have fixed dozens of bugs in the mean time If the problems persists, please re-open this bug.

Conflicts between Add-Ins are often unavoidable. We have a list of known issues at:
https://wiki.gnupg.org/GpgOL/IncompatibleAddons
If you have more information on that ESET thingy please enter it into the above wiki or leave some description here.

Use our build system and things work. In particular you need to use the software versions as listed at versions.gnupg.org and available via the build-auch/getswdb.sh. Even better use the speedo build system for Windows. Everything else is not a supported build configuration.

Was fixed in 2.3.5

Thanks. Will go into 2.3.6

Please contact the Debian developers for any systemd/gnupg issues. We don't suggest the use of the --supervised option because it causes more problems than it claims to solve.

In this case it works, because the error messages are not translatable.

We are using rsa-4096 on smartcard for quite some time; so I wonder what's the problem here. Is that that we don't use our Assuan hack for large key material with OpenPGP.3?

You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.

Should also go into 2.2

The rest of the code looks fine.

I tend to avoid such changes to keep the translations valid. But for master this is okay.

The links for the Windows installer as given in the mail was wrong. The corrected links are