Thanks for taking this up.

Thanks for your confirmation.

Thanks again for your update.

I just wrote a blog article about this problem
https://ludovicrousseau.blogspot.com/2022/05/scardlistreaders-and-non-initialized.html

Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.

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 a lot for your cooperation.

TL;DR: can reproduce, needs fixing

https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/140

On second thought: Let me open the MR.

@aheinecke I suggest to open an MR for this at https://invent.kde.org/frameworks/kconfigwidgets and see how the discussion goes. Either the change is accepted or other proposals are made to fix the crash in Kleopatra.

No. And this is out of scope for Kleopatra. You can use existing file sync tools to sync the files in ~/.gnupg. Which files to sync depends on what you want to sync. For details, I suggest to ask on the gnupg-users mailing list.

Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.

Maybe we shouldn't exclude expired or revoked keys from the list so that people can still choose them. Of course, those keys wouldn't be accepted to be used for encryption, but it would help people to find out why the keys are not acceptable.

My email to gnupg-devel@gnupg.org was accepted and is visible in the archives https://lists.gnupg.org/pipermail/gnupg-devel/2022-May/035063.html
Cool

Thanks. Should be applied.

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

In T5950#158024, @werner wrote:

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

Thank you for your fast reply. My apologies - I should have thought to do that (share log with asm enabled)! But now I'm confused. I think the failure was only ever with asm disabled. I will check with somebody else tomorrow just to make sure though.

Could you please give us the build log with no --disable-asm?

I put more fix for error handling of key algorithm attribute.
The change: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thanks a lot for your cooperation.

Full build.log: