Thu, Oct 29
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.
Wed, Oct 28
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.
Tue, Oct 27
- returns app specific serialno
- returns canonical serialno
Mon, Oct 26
Pushed the change.
Fri, Oct 23
Wed, Oct 21
I created this patch D509: Yubikey supports two (or more) apps, serial number problem.
Mon, Oct 19
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.)
Tue, Oct 13
This doesn't help. I think that's because after
flush_cached_data (app, dobj->tag);
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
Mon, Oct 12
Fri, Oct 9
Thu, Oct 8
I have added a workaround to Kleopatra: rKLEOPATRA57cf71b043d198f85270eb3b8782de6277b8b889
Tue, Oct 6
Sep 30 2020
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.
Sep 29 2020
Sep 28 2020
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.
Sep 26 2020
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.
Sep 25 2020
Currently, yes. After some testing, I'll backport it to 2.2.
Sep 24 2020
Nice, thanks! If I want to try this fix, should I just compile the master tree?
Sep 17 2020
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!
Sep 16 2020
Thanks for sending.