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:

Contrary to your expectations, all gpg --card-status fail after yubikey insertion:

Please do experiment again and give us the whole log of scdaemon.log for:

• insert Yubikey initially
• run gpg --card-status (success is expected)
• remove Yubikey
• insert Yubikey second time
• run gpg --card-status (failure is expected)

Hmm, according to lxr.kde.org this is the only usage of a static thread_local KSharedConfigPtr variable in all of (indexed) KDE. OTOH, there's also exactly one usage of a static KSharedConfigPtr variable in all of KDE (in plasma/plasma-nm/libs/editor/configuration.cpp).

Editing a formatted password should work now as expected.

Ingo: I have now assigned this to you. If you can explain why my fix is required in a way that upstream would accept the change we should try to get this into KConfigWidgets proper. But I do not think that I can convincingly explain why it is required or what happens here.

In case you need any information, be sure to let me know. Maybe we can add some manual loggers to the patches, to confirm that everything is working as you imagine it to?

After some debugging and reading the code I did not find any way that the KSharedConfigPtr could be accessed when it was NULL. It is never saved in a member variable. The only place it was saved was in the static thread_local variable of defaultConfig in kcolorschemehelpers_p.h. Since this was irritating because I understood QExplicitlySharedDataPointer to already handle thread_local ness

Its an issue of cursor position. If one either deletes or inputs a a character anywhere in the password string, the cursor always jumps to the end of the string.

So after updating to latest kf5 this still happens. The windows event log tells me that the crash occurs from libkf5configwidgets.dll
Does not seem to happen on Linux, i have run it with valgrind to and only found other crashes on linux shutdown when closing the window.

Umm... The problem is the last bogus octet from Yubikey. In the log, we see:

I'm certain I've applied the patches correctly. This is my current patchset:

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

The change improve error handling for possible other errors by device: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thank you for the logs. It seems that scdaemon didn't detect the removal correctly.

I've uploaded the requested information with triple verbose and debug-all setting in the scdaemon.conf as scdaemon.log:

Thank you, @gniibe. That's what I was missing: installing libsqlite3-dev made the difference.