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.

Pushed the change. Also, it's backported to 1.10 branch.

Thanks for creating this ticket. I'll reply.

Pushed the changes for http.c.

libgcrypt 1.10 is out with the API change for Windows, and we don't see any report (yet).

Applied to 2.2 branch, too.

Pushed the change to master.

Pushed the fix.

I examined all log files you gave us, and I think that scdaemon with PC/SC fails to detect the removal of the USB device.

You need to install a package like sqlite-devel or libsqlite3-dev, so that you can have development header files and library (sqlite3*.h and libsqite3.so) and pkgconfig file (pkgconfig/sqlite3.pc).

Yes, I saw that in the logs and installed those packages. Now I have sqlite and sqlite3 in /usr/bin, but that doesn't seem to have changed anything.

the link's target doesn't exist

Yes, of course I did that. The error output I included followed the sequence

Is there any progress on this issue? The code looks reasonable but does not apply on top of 2.2.35 (I didn't try master yet) and I didn't find a submission to the mailing list. I would really appreciate this patch, as it is a significant speedbump in my workflow.