Created attachment 478264 [details] gpg 2.1.20-r1 output Hi, I've been trying this version as well as 2.1.15 with different outputs. On latest version I get that gnupg list key not usable on a key that is available. On 2.1.15 pekkari user shows similar output of the card than root user see in any version. This seems to be similar to the following bug: https://dev.gnupg.org/T2933 Though it's supposed 2.1.19 fixes it already. Any thoughts? Thanks! José.
unmasking the latest version still produces the same situation. gpg --version gpg (GnuPG) 2.1.21 libgcrypt 1.7.7 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/pekkari/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 gpg --card-status gpg: selecting openpgp failed: No such device gpg: OpenPGP card not available: No such device emerge -s gnupg [ Results for search key : gnupg ] Searching... * app-crypt/gnupg Latest version available: 2.1.21-r1 Latest version installed: 2.1.21-r1 Size of files: 6,322 KiB Homepage: http://www.gnupg.org/ Description: The GNU Privacy Guard, a GPL OpenPGP implementation License: GPL-3 .... Thanks! José
Oh, and just for completeness: # lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 033: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID # grep 0407 -R /lib/udev/rules.d/ /lib/udev/rules.d/70-u2f.rules:KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0113|0114|0115|0116|0120|0402|0403|0406|0407|0410", MODE="0664", GROUP="plugdev" $ groups wheel audio video qemu kvm usb users plugdev portage jenkins libvirt lxd pekkari lxc prey weston-launch So, in theory, user might not find issues to reach the device.
are you using the internal ccid driver or pcsd? The key that is located on the card seems to be a different one from the one you show in --edit-key, mainly the primary for pub rsa4096/26BB4BBD24D586EF created: 2016-06-14 expires: 2018-06-14 usage: SC trust: unknown validity: unknown sub rsa4096/6BAC6E89BBBA8DFA created: 2016-06-14 expires: 2018-06-14 usage: E You can increase the scdaemon verbosity using log-file and debug-level in scdaemon.conf, you can see a bit more about what happens for debugging then (don't post a non-redacted file if using guru level or similar as it can contain PIN information etc)
Hi, True, I confused the keys as I though there was one key per slot, but the real key is here: pub rsa4096/24D586EF 2016-06-14 [SC] [expires: 2018-06-14] C5468CDE4DC3CEBC334286BA26BB4BBD24D586EF uid [ultimate] José Pekkarinen <jose.pekkarinen@canonical.com> sub rsa4096/BBBA8DFA 2016-06-14 [E] [expires: 2018-06-14] I'm avoiding to use any ccid driver for this card, nor pcsd, as it used to work without any, and I don't own any other card supported by gnupg. I've been trying for a while to get output out of scdaemon, and this is what I got: 2017-06-30 09:51:53 scdaemon[13068] listening on socket '/run/user/1000/gnupg/S.scdaemon' 2017-06-30 09:51:53 scdaemon[13068] handler for fd -1 started 2017-06-30 09:51:53 scdaemon[13068] DBG: chan_5 -> OK GNU Privacy Guard's Smartcard server ready 2017-06-30 09:52:39 scdaemon[13068] SIGINT received - immediate shutdown 2017-06-30 09:52:39 scdaemon[13068] scdaemon (GnuPG) 2.1.21 stopped 2017-06-30 09:52:50 scdaemon[14435] listening on socket '/run/user/1000/gnupg/S.scdaemon' 2017-06-30 09:52:50 scdaemon[14435] handler for fd -1 started 2017-06-30 09:52:50 scdaemon[14435] DBG: chan_5 -> OK GNU Privacy Guard's Smartcard server ready 2017-06-30 09:55:30 scdaemon[14435] SIGINT received - immediate shutdown 2017-06-30 09:55:30 scdaemon[14435] scdaemon (GnuPG) 2.1.21 stopped 2017-06-30 09:55:33 scdaemon[14806] listening on socket '/run/user/1000/gnupg/S.scdaemon' 2017-06-30 09:55:33 scdaemon[14806] handler for fd -1 started 2017-06-30 09:55:33 scdaemon[14806] DBG: chan_5 -> OK GNU Privacy Guard's Smartcard server ready This is how I execute the scdaemon: /usr/libexec/scdaemon --multi-server --log-file ~/.gnupg/scd.log --no-detach --debug-level guru scdaemon[14806]: enabled debug flags: mpi crypto memory cache memstat hashing ipc cardio reader OK GNU Privacy Guard's Smartcard server ready In case it helps, the useflags used: # emerge -pv gnupg These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] app-crypt/gnupg-2.1.21-r1::gentoo USE="bzip2 gnutls ldap nls readline smartcard usb -doc (-selinux) -tofu -tools -wks-server" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Thanks! José
(In reply to José Pekkarinen from comment #4) > Hi, > > I'm avoiding to use any ccid driver for this card, nor pcsd, as it used to > work without any, and I don't own any other card supported by gnupg. For clarity, what you're saying here is not adding any _external_ ccid driver, meaning it will use gnupg internal ones (which is whats I recommend anyways), unless specifying e.g disable-ccid in scdaemon.conf that forces the use of external drivers. > > I've been trying for a while to get output out of scdaemon, and this is what hmm, I don't see anything truly useful here > > This is how I execute the scdaemon: Scdaemon should auto-launch, you don't need to start it externally (and likely shouldn't as it can confuse blocking on devices etc with multiple ones running) > In case it helps, the useflags used: > Thanks, this looks OK. What is the permission for ls -l /dev/bus/usb/002/001 (or if different port, whatever you connect the youbikey to)
Also, anything different if you add udev rule earlier in chain compared to u2f one with ATTR{idVendor}=="1050", ATTR{idProduct}=="0407", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg" ?
> For clarity, what you're saying here is not adding any _external_ ccid > driver, meaning it will use gnupg internal ones (which is whats I recommend > anyways), unless specifying e.g disable-ccid in scdaemon.conf that forces > the use of external drivers. Yes, I know gnupg provides ccid, I don't use any external, just the local one. > > Scdaemon should auto-launch, you don't need to start it externally (and > likely shouldn't as it can confuse blocking on devices etc with multiple > ones running) Yes, but for any reason it ignores scdaemon.conf on my end, and I used this as a workaround for testing. > > What is the permission for ls -l /dev/bus/usb/002/001 (or if different > port, whatever you connect the youbikey to) Whaaaaaaaaat?? $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID $ ls -l /dev/bus/usb/001/004 crw-rw-r-- 1 root pcscd 189, 3 Jun 30 18:03 /dev/bus/usb/001/004 I think you got the issue here... $ groups wheel audio video qemu kvm usb users plugdev portage jenkins libvirt lxd pekkari lxc prey weston-launch Where the heck is that group coming from? Thanks!
(In reply to José Pekkarinen from comment #7) > $ ls -l /dev/bus/usb/001/004 > crw-rw-r-- 1 root pcscd 189, 3 Jun 30 18:03 /dev/bus/usb/001/004 > > I think you got the issue here... > > $ groups > wheel audio video qemu kvm usb users plugdev portage jenkins libvirt lxd > pekkari lxc prey weston-launch > > Where the heck is that group coming from? > Can likely try grep pcscd /lib/udev/rules.d/* , I'd expect sys-apps/pcsc-lite or similar given the group
> Can likely try grep pcscd /lib/udev/rules.d/* , I'd expect > sys-apps/pcsc-lite or similar given the group Yes, guilty ones are: # grep pcscd -R . ./92-pcsc-ccid.rules:# so they can be used by pcscd ./92-pcsc-ccid.rules:# $Id: 92_pcscd_ccid.rules 6587 2013-04-05 16:31:55Z rousseau $ ./92-pcsc-ccid.rules:#SUBSYSTEMS=="pcmcia", DRIVERS=="serial_cs", ACTION=="add", ATTRS{prod_id1}=="Gemplus", ATTRS{prod_id2}=="SerialPort", ATTRS{prod_id3}=="GemPC Card", RUN+="/usr/sbin/pcscd --hotplug" ./92-pcsc-ccid.rules:ACTION!="add", GOTO="pcscd_ccid_rules_end" ./92-pcsc-ccid.rules:SUBSYSTEM!="usb", GOTO="pcscd_ccid_rules_end" ./92-pcsc-ccid.rules:ENV{DEVTYPE}!="usb_device", GOTO="pcscd_ccid_rules_end" ./92-pcsc-ccid.rules:# change group from default "root" to "pcscd" ./92-pcsc-ccid.rules:LABEL="pcscd_ccid_rules_end" ./99-pcscd-hotplug.rules:# if we just added a pcscd-owned device, we hotplug the pcscd service. ./99-pcscd-hotplug.rules:ACTION=="add", ENV{PCSCD}=="1", GROUP="pcscd", RUN+="/bin/env IN_HOTPLUG=1 /etc/init.d/pcscd --quiet start" It might be pcsc-lite as you said. It's installed though not in world. I can confirm that adding my user to pcscd allows me to read the yubikey again: $ gpg --card-status Reader ...........: 1050:0407:X:0 Application ID ...: D2760001240102010006042581400000 Version ..........: 2.1 Manufacturer .....: Yubico Serial number ....: 04258140 Name of cardholder: [not set] Language prefs ...: [not set] Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: not forced Key attributes ...: rsa4096 rsa2048 rsa2048 Max. PIN lengths .: 127 127 127 PIN retry counter : 2 0 3 Signature counter : 5 Signature key ....: C546 8CDE 4DC3 CEBC 3342 86BA 26BB 4BBD 24D5 86EF created ....: 2016-06-14 18:13:53 Encryption key....: [none] Authentication key: [none] General key info..: pub rsa4096/26BB4BBD24D586EF 2016-06-14 José Pekkarinen <jose.pekkarinen@canonical.com> sec> rsa4096/26BB4BBD24D586EF created: 2016-06-14 expires: 2018-06-14 card-no: 0006 04258140 ssb rsa4096/6BAC6E89BBBA8DFA created: 2016-06-14 expires: 2018-06-14 Thanks! José
Closing as fixed then, nothing to do for gnupg
I guess this should be WORKSFORME/INVALID as nothing was fixed... :)
Should this be reported to pcsc-lite or udev to revise the rules? In some way pcsc is hijacking u2f rules.
