I forgot that we have LOCK and UNLOCK commands in scdaemon. This was implemented around 2005 but there are no more users in gpg meanwhile.

I have tested this with Kleopatra. The good news is that SCD GETATTR $DISPSERIALNO now works for the piv app even if the openpgp app is enabled.

SCD commands:

• SERIALNO
  • returns app specific serialno
• LEARN
  • returns canonical serialno

Pushed the change.

I created this patch D509: Yubikey supports two (or more) apps, serial number problem.

But changing just the displayed S/N should not disturb anything.

No, the above patch makes OpenPGP app stop working.

(I don't know well about Yubikey specific serial number.)

This doesn't help. I think that's because after

flush_cached_data (app, dobj->tag);

do_writecert does

do_readkey (...)

which fills the cache again.

Caching issue. do_writecert in app-piv flushes the cache but may be the wrong DO. Can you try to

I have added a workaround to Kleopatra: rKLEOPATRA57cf71b043d198f85270eb3b8782de6277b8b889

I observed that the card reader's going erroneous state when I removed a card during its communication.
In this state, it never reports the card removal by the interrupt transfer.
I applied rG920f258eb601: scd: Internal CCID driver: More fix for SPR532. for this problem.

The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.

This is also what I found out with my tests with the libvirt usb: removing and redirecting back the device got it working again.

Testing more, I managed to encounter failure with physical usb.
Once in this failure mode, I need to remove the card reader from USB and reinsert again.
I need to figure out a sequence to avoid this situation and to reset the card reader correctly.

I tested with physical usb, did multiple operations with external events (insert/remove/etc. for card). I haven't seen any problem (if so, I were doing more fixes), so far.

Ok. Tried to test this with master, but failed. I got it compiled and installed, and it actually detected the first removal after reboot/suspend/reader attach/whatever reason, but after that when I inserted the card back, it didn't function anymore. I suppose you also tried that? I mean that's the use case, I suppose: to be able to remove/insert the card reliably all day long.

Currently, yes. After some testing, I'll backport it to 2.2.

Nice, thanks! If I want to try this fix, should I just compile the master tree?

This is everything lsusb knows about the device:

And please report the output of lsusb -d 04e6:e003 for the information of the card reader.

@turkja Thanks for your information.
May I ask you one thing?
Please show me the usb VID:PID of your card reader.
Is it 04e6:e003?
You can examine a line of the output by lsusb.

Just wanted to add to my initial findings:

• I was not using proprietary drivers (libscmccid.so.5.0.35), because the installer script fails to install on default CentOS 8 pcsc-lite. So the distribution pcsc-lite also doesn't have this issue.
• Fastest way to test this condition is to just detach/attach the reader device.
• Proprietary drivers doesn't support secure pin entry!

Thanks for sending.

Here is the output for an SCM SPR532