We meanwhile released two versions to our clients and are looking on how we can make it available to the community.

We have everything ready for a GnuPG Desktop Appimage but we first need a business case to maintain it.

We have a workaround by using a recent version of gpgtar directly. Thus lowering priority.

Please disable all other Add-Ins as well as extra security tools running on that machine to see whether there is some interference with them.

But only with an option - in general showing expired keys is annoying. For revoked keys the situation is different in case of a compromise - but many users revoke old keys anyway and we don't make use of the revocation reason. If we would consider the latter the UI/Support would be more complicated than useful.

Thanks for opening a ticket.

Thanks. Should be applied.

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

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