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.

I've applied the linked patch, but still experience the error. Most of the times, I cannot access my yubikey at all and I am not sure what is blocking it.
I've tried to include as much debugging output as I could below. Please let me know if there is anything else I can do to debug this.

Sorry, yes I meant the Certificate Dump not the Details.

I would love to defer those encoding problems to gpgme. The output of gpgme should always be UTF-8 encoded, so that higher API doesn't need to bother about encoding. Obviously, this would mean that we shouldn't bypass gpgme by running gpg commands with QProcess.