Mailing List Archive

Felix E. Klee <felix.klee@inka.de> wrote:
> system (running in VMware under Windows), it sometimes takes minutes to

> [felix@felix-arch ~]$ ls /dev/bus/usb/002/011 /dev/bus/usb/002/011

I think you need to make sure that it's not VMware that's failing to plug the
device through in a timely manner.

dmesg -w

Would confirm that it's getting there. You say that you can get it working
as root. How does --card-status know which USB device to use? Does it
perhaps scan through all devices? I wonder if it is getting stuck on some
other device that it hasn't got permission?

> How do I fix that?

> I am happy to substitute the udev rules with a timer, or to call some
> command to give permissions every time I want to use the YubiKey or the
> OpenPGP card. I just would like the whole process to be more reliable.
> Currently, it’s extremely frustrating.

!-indeed.



--
Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide

On Thu, Aug 3, 2023 at 9:28?PM Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
> I think you need to make sure that it's not VMware that's failing to
> plug the device through in a timely manner.

I have configured the VMware guest to automatically take over these
devices from the Windows 10 host:

usb.autoConnect.device0 = "0x04e6:0xe003"
[…]
usb.autoConnect.device7 = "0x1050:0x0404"

> dmesg -w

I just played around. After unplugging the YubiKey, I connected the
SPR332:

[felix@felix-arch ~]$ sudo dmesg -w
[…]
[ 5135.728320] usb 2-1: new full-speed USB device number 6 using
uhci_hcd
[ 5136.137546] usb 2-1: New USB device found, idVendor=04e6,
idProduct=e003, bcdDevice= 7.01
[ 5136.137551] usb 2-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=5
[ 5136.137553] usb 2-1: Product: SPRx32 USB Smart Card Reader
[ 5136.137554] usb 2-1: Manufacturer: SCM Microsystems Inc.
[ 5136.137555] usb 2-1: SerialNumber: 51271741200012
^C
[felix@felix-arch ~]$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
[felix@felix-arch ~]$ sudo gpg --card-status
Reader ...........: SCM Microsystems Inc. SPR 532 [CCID Interface]
(51271741200012) 00 00
Application ID ...: D2760001240103030005000064D50000
Application type .: OpenPGP
Version ..........: 3.3
Manufacturer .....: ZeitControl
Serial number ....: 000064D5
Name of cardholder: Felix Klee
Language prefs ...: en
Salutation .......: Mr.
URL of public key :
https://sks-keyservers.net/pks/lookup?op=get&search=0x5EF8B6017F668171259945D6BEF6EFD38FE8DCA0
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa4096 rsa4096 rsa2048
Max. PIN lengths .: 64 64 64
PIN retry counter : 3 3 3
Signature counter : 10
KDF setting ......: off
Signature key ....: 5EF8 B601 7F66 8171 2599 45D6 BEF6 EFD3 8FE8
DCA0
created ....: 2016-12-17 10:49:18
Encryption key....: 27BF BB40 70FC 6351 189E 79FE 04FD F78D 1679
DD94
created ....: 2016-12-17 10:49:18
Authentication key: [none]
General key info..: pub rsa4096/BEF6EFD38FE8DCA0 2016-12-17 Felix E.
Klee <felix.klee@inka.de>
sec> rsa4096/BEF6EFD38FE8DCA0 created: 2016-12-17 expires:
2020-11-10 card-no: 0005 000064D5
ssb> rsa4096/04FDF78D1679DD94 created: 2016-12-17 expires:
2020-11-10 card-no: 0005 000064D5
[felix@felix-arch ~]$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

As you can see, I can connect to it as root but not as regular user.
Sometimes connection as regular user works, sometimes not. Sometimes I
just have to wait for a while, can be minutes, and then it works.

I also tried killing root’s gpg-agent, to avoid conflicts with that of
the user, but that didn’t help either.

Furthermore, even if udev doesn’t trigger, I should have rw access to
the device file (it’s an SPR332, not sure why it says SPR532):

[felix@felix-arch ~]$ lsusb | grep SPR532
Bus 002 Device 006: ID 04e6:e003 SCM Microsystems, Inc. SPR532
PinPad SmartCard Reader
[felix@felix-arch ~]$ ls -l /dev/bus/usb/002/006
crw-rw---- 1 root scard 189, 133 Aug 5 12:02 /dev/bus/usb/002/006
[felix@felix-arch ~]$ groups
scanner saned uucp optical lp audio wheel felix scard plugdev
[felix@felix-arch ~]$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

Why does it work as root but not as regular user?

Any suggestion for a fix, even if crude, is welcome!

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Hello,

Please note that I don't have any experience using scdaemon in a guest
OS of GNU/Linux. So, my answer may be wrong/irrelevant.

"Felix E. Klee" <felix.klee@inka.de> wrote:
> [felix@felix-arch ~]$ sudo gpg --card-status
> Reader ...........: SCM Microsystems Inc. SPR 532 [CCID Interface]
> (51271741200012) 00 00

Please note that there may be two methods to access the device in
scdaemon:

* in-stock CCID driver of scdaemon
* the PC/SC service

Your output shows that you are connecting the smartcard reader through
the PC/SC service.

If it's not your intention and your scdaemon has support of in-stock
CCID driver, I'd recommend not to use the PC/SC service. Perhaps,
simply uninstall pcscd.

That's because it's simpler for scdaemon. It's easier to configure and
debug, if your purpose is only for use of OpenPGP smartcard.

If you have a reason using PC/SC service (say, for example, you need the
service for other applications and other cards, as well as your use of
OpenPGP smartcard for GnuPG), please make sure that you configure the
PC/SC service correctly. You should test and make sure, by a normal
user, if you can access your cards by the PC/SC service correctly.

* * *

Also, I'm afraid that you are using older GnuPG. In GnuPG 2.2, scdaemon
had a feature to fallback to the PC/SC service, when access to in-stock
CCID driver doesn't go well. The feature is disabled in 2.4. In GnuPG
2.4, when scdaemon has support of in-stock CCID driver, to use the PC/SC
service, you need manually configure scdaemon with "disable-ccid" (no
use of in-stock CCID driver).
--

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sat, 5 Aug 2023 12:10, Felix E. Klee said:
> I also tried killing root’s gpg-agent, to avoid conflicts with that of
> the user, but that didn’t help either.

Right a second scdaemon might have grabbed the device. If you don't
need it as root put into root's gpg-agent.conf "disable-scdaemon".

Another option is to put

pcsc-shared

into /etc/gnupg/scdaemon.conf and to install pcscd. The drawback is
that there might be some hiccup with OpenPGP cards and PIN requests
(because we cache the verification status in scdaemon for the sake of
older OpenPGP cards) and if you change the data on a card the other
scdaemon's won't see the change.

We are currently considering whether to chnage scdameon to a system
service or implement some kind of syncing.

> Why does it work as root but not as regular user?

The root's scdaemon has access to the device.


Shalom-Salam,

Werner



--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On Mon, Aug 7, 2023 at 9:00?AM NIIBE Yutaka <gniibe@fsij.org> wrote:
> Please note that there may be two methods to access the device in
> scdaemon:
>
> * in-stock CCID driver of scdaemon
> * the PC/SC service
>
> Your output shows that you are connecting the smartcard reader through
> the PC/SC service.

Interesting. I assume the problem is down to a race-condition with the
two competing for access. That would explain its apparent randomness.

> If it's not your intention and your scdaemon has support of in-stock
> CCID driver, I'd recommend not to use the PC/SC service. Perhaps,
> simply uninstall pcscd.

I prefer not to, because: I may install the PC/SC service again in the
future and then I likely will have forgotten about our conversation
here.

> If you have a reason using PC/SC service (say, for example, you need
> the service for other applications and other cards, as well as your
> use of OpenPGP smartcard for GnuPG), please make sure that you
> configure the PC/SC service correctly.

Indeed it was not properly set up:

[felix@felix-arch ~]$ opensc-tool -l
No smart card readers found.

I added a Polkit rule following the [instructions][1] for PC/SC:

[root@felix-arch ~]# cat /etc/polkit-1/rules.d/01-pcscd.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
subject.user == "felix") {
return polkit.Result.YES;
}
});

Now it works:

[felix@felix-arch ~]$ opensc-tool -l
# Detected readers (pcsc)
Nr. Card Features Name
0 Yes Yubico YubiKey CCID 00 00

I should see in the upcoming days whether that solves the issue.

Thank you!

[1]: https://github.com/LudovicRousseau/PCSC/blob/master/doc/README.polkit

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, Aug 7, 2023 at 3:30?PM Werner Koch <wk@gnupg.org> wrote:
> > I also tried killing root’s gpg-agent, to avoid conflicts with that
> > of the user, but that didn’t help either.
>
> Right a second scdaemon might have grabbed the device. If you don't
> need it as root put into root's gpg-agent.conf "disable-scdaemon".
>
> Another option is to put
>
> pcsc-shared

Thanks, good to know about this option. However, I hope that fixing
PC/SC access has solved the issue. See my other message.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

The issue persists. Sometimes the readers (just now the YubiKey) are not
visible to the user. But they are always to root k. I then disabled the
PC/SC daemon:

[felix@felix-arch ~]$ sudo systemctl disable pcscd
Removed "/etc/systemd/system/sockets.target.wants/pcscd.socket".
[felix@felix-arch ~]$ sudo systemctl stop pcscd
Warning: Stopping pcscd.service, but it can still be activated by:
pcscd.socket

Afterwards, `gpg --card-status` immediately showed the card status to
the ordinary user.

However, this solution is not good. As I mentioned before, I may want to
use PC/SC in the future, and I may also just accidentally re-enable it.
So it would be better to have a solution where the PC/SC daemon does not
cause some race condition.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users