app-crypt/gnupg-2.0.28, using USB use flag, still trys to launch scdaemon from /usr/libexec/scdaemon - USB use flag states: (Restricted to >=app-crypt/gnupg-2.0.17-r1) Build direct CCID access for scdaemon; requires dev-libs/libusb. - SMARTCARD use flag states: (Restricted to <app-crypt/gnupg-2.0.17-r1) Bring in dev-libs/libusb as a dependency; enable scdaemon. So it /seems to me/ that the new USB use flag is failing to enable scdaemon. $ gpg --card-status gpg: can't connect to the agent - trying fall back gpg-agent[13338]: can't connect to the SCdaemon: IPC connect call failed gpg: OpenPGP card not available: No SmartCard daemon $ gpg-agent --server --debug-level=guru gpg-agent[13375]: enabled debug flags: command mpi crypto memory cache memstat hashing assuan gpg-agent[13375]: chan_5 -> OK Pleased to meet you OK Pleased to meet you SCD HELP gpg-agent[13375]: chan_5 <- SCD HELP gpg-agent[13375]: no running SCdaemon - starting it gpg-agent[13375]: chan_7 <- ERR 67109133 can't exec `/usr/libexec/scdaemon': No such file or directory gpg-agent[13375]: chan_7 -> BYE gpg-agent[13375]: can't connect to the SCdaemon: IPC connect call failed gpg-agent[13375]: chan_5 -> ERR 67108983 No SmartCard daemon <GPG Agent> ERR 67108983 No SmartCard daemon <GPG Agent> Reproducible: Always Steps to Reproduce: (Clear out your gnupg installed programs) (Install latest unmasked app-crypt/gnupg) 1. Plug in smart card 2. execute 'gpg --card-status' Actual Results: gpg: can't connect to the agent - trying fall back gpg-agent[13338]: can't connect to the SCdaemon: IPC connect call failed gpg: OpenPGP card not available: No SmartCard daemon Expected Results: GPG find and report on the smart card (yubikey in this instance) SUDO SUCCESS! Portage 2.2.24 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop/kde, gcc-4.8.4, glibc-2.21-r1, 4.0.5-gentoo x86_64) ================================================================= System uname: Linux-4.0.5-gentoo-x86_64-AMD_FX-tm-8350_Eight-Core_Processor-with-gentoo-2.2 KiB Mem: 16319076 total, 4247612 free KiB Swap: 8388604 total, 8388604 free Timestamp of repository gentoo: Thu, 07 Jan 2016 12:15:01 +0000 sh bash 4.3_p39 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p39::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.10-r1::gentoo, 3.2.5-r6::gentoo, 3.4.3::gentoo dev-util/cmake: 3.3.1-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.18.4::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.8.4::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r1::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.us.gentoo.org/gentoo-portage/ priority: -1000 arduino location: /usr/local/portage masters: gentoo priority: 0 sublime-text location: /var/lib/layman/sublime-text masters: gentoo priority: 1 abadonna-overlay location: /var/lib/layman/abadonna-overlay masters: gentoo priority: 2 jkolo location: /var/lib/layman/jkolo masters: gentoo priority: 3 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://lug.mtu.edu/gentoo/ ftp://lug.mtu.edu/gentoo/" INSTALL_MASK="/lib32/systemd /lib64/systemd /usr/lib/systemd /usr/lib32/systemd /usr/lib64/systemd /etc/systemd" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa amd64 berkdb bindist bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdbm gif git glamor gpm iconv ipv6 jpeg kde kipi lcms ldap libnotify mad mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pcsc-lite pdf phonon plasma png policykit ppds qt3support qt4 readline sdl seccomp semantic-desktop session spell sse sse2 ssl startup-notification subversion svg tcpd tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xattr xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="amdgpu radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
I should go ahead and state, running the gpg and gpg-agent commands as root, with and w/out pcscd running, make no difference in the already provided output. Also, thank you!
Gave this a shot on the latest Gentoo LiveDVD image running in a VM. I wasn't able to gain access to the yubikey with pcsc_tools, but I don't believe that is relevant to gnupg continuing to provide the same output. The scdaemon would access it (and fail), but gnupg can't access the scdaemon. https://bpaste.net/show/1709d6c87ff0
2.0.28 ebuild does seem to contain instructions to enable scdaemon. However, the 2.0.28 ebuild does not declare the libexec dir as done in the 1.4.19 ebuild. The 2.0.28 ebuild does seem to create a few symlinks in the /usr/libexec dir, but not for scdaemon. However, I believe I searched the machine for any file name containing scdaemon and found none; I need to confirm that statement. From gnupg-2.0.28.ebuild: ( https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/gnupg/gnupg-2.0.28.ebuild?id=914100df67e290823ce724d8c8092fe0c587b6fe ) src_configure() { ... if use smartcard; then myconf+=( --enable-scdaemon $(use_enable usb ccid-driver) ) else myconf+=( --disable-scdaemon ) fi ... } src_install() { ... dosym gpg2keys_hkp /usr/libexec/gpgkeys_hkp dosym gpg2keys_finger /usr/libexec/gpgkeys_finger dosym gpg2keys_curl /usr/libexec/gpgkeys_curl if use ldap; then dosym gpg2keys_ldap /usr/libexec/gpgkeys_ldap fi ... } From gnupg-1.4.19.ebuild: ( https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/gnupg/gnupg-1.4.19.ebuild?id=58fd093c9f7947b53321a0b5f705b28657980a1e ) src_configure() { ... econf \ ... --libexecdir="${EPREFIX}/usr/libexec" \ --enable-noexecstack \ CC_FOR_BUILD=$(tc-getBUILD_CC) \ ${myconf} }
Confirmed, no scdaemon on this system: $ sudo find / -xdev -iname '*scdae*' /usr/share/man/man1/scdaemon.1.bz2 $ Enabled build logging and grepped it. Turns out the ebuild is, for some reason, declaring --disable-scdaemon: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --docdir=/usr/share/doc/gnupg-2.0.28 --enable-gpg --enable-gpgsm --enable-agent --enable-large-secmem --without-adns --disable-scdaemon --enable-symcryptrun --enable-bzip2 --enable-nls --disable-mailto --enable-ldap --with-readline CC_FOR_BUILD=x86_64-pc-linux-gnu-gcc config.status: creating scd/Makefile Evaluating the ebuild logic...
Seems there is a logic error in the ebuild. Looking at equery u app-crypt/gnupg we see: - - smartcard : (Restricted to <app-crypt/gnupg-2.0.17-r1) Bring in dev-libs/libusb as a dependency; enable scdaemon. + + usb : (Restricted to >=app-crypt/gnupg-2.0.17-r1) Build direct CCID access for scdaemon; requires dev-libs/libusb. So for all systems running versions >=2.0.17-r1, the use flag will always be USB. Looking at the gnupg-2.0.28.ebuild we see: if use smartcard; then myconf+=( --enable-scdaemon $(use_enable usb ccid-driver) ) else myconf+=( --disable-scdaemon ) fi So for all systems running versions >=2.0.17-r1, the use flag will NOT be smartcard, and there for scdaemon will be disabled during build.
Corrected USB use flag ebuild logic error. Will attach patch momentarily. $ gpg --card-status gpg: can't connect to the agent - trying fall back scdaemon[23121]: reading public key failed: Card error scdaemon[23121]: reading public key failed: Card error scdaemon[23121]: reading public key failed: Card error Application ID ...: D2760001240102000006038245780000 Version ..........: 2.0 Manufacturer .....: Yubico Serial number ....: 03824578 Name of cardholder: [not set] Language prefs ...: [not set] Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 127 127 127 PIN retry counter : 3 3 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] scdaemon[23121]: updating slot 0 status: 0x0000->0x0007 (0->1)
Created attachment 422346 [details, diff] Patch for bug 571250
Not sure I understand. smartcard instructs to enable smartcard support - may be multiple interfaces. usb instructs to enables the ccid drive within smartcard. So if smartcard is disabled then usb has no effect, as far as I see this is what you experience which is what the ebuild is doing.
Current use flag restrictions prevent smartcard use flag from being used, forcing USB to be used on >=app-crypt/gnupg-2.0.17-r1. USB use flag does not cause gnupg to compile w/ smartcard support, due to logic in ebuild it actually forces smartcard support to be disabled. Comment #5 identifies the root cause of this.
(In reply to John Harlan from comment #9) > Current use flag restrictions prevent smartcard use flag from being used, > forcing USB to be used on >=app-crypt/gnupg-2.0.17-r1. USB use flag does not > cause gnupg to compile w/ smartcard support, due to logic in ebuild it > actually forces smartcard support to be disabled. > > Comment #5 identifies the root cause of this. I have no idea why equery would show the use flag as "restricted", but have you tried enabling "smartcard" use flag anyhow?
(In reply to Kristian Fiskerstrand from comment #10) ... > I have no idea why equery would show the use flag as "restricted", but have > you tried enabling "smartcard" use flag anyhow? No, I assumed the provided tools provided correct information. It looks like that will work however.: $ cat /etc/portage/make.conf | grep smart $ sudo nano /etc/portage/make.conf Password: $ cat /etc/portage/make.conf | grep smart USE="-gtk -gnome qt4 qt3support kde X cups consolekit acl pam policykit udev udisks crypt opengl amd64 dvd alsa cdr bindist mmx sse sse2 git subversion svg bluetooth pcsc-lite smartcard" $ emerge -av --changed-use app-crypt/gnupg ... Calculating dependencies... done! [ebuild R ] app-crypt/gnupg-2.0.28::gentoo USE="bzip2 ldap nls readline smartcard* usb -doc -mta (-selinux) -static -tools" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] n Quitting.
Summary: - 'equery u' outputs misleading information (root cause of this ticket) - USB use flag's function is dependent on smartcard use flag being enabled, but: - - There is no warn/error message if USB is enabled, and smartcard is not. - - Enabling USB does not force enable smartcard I recommend closing this ticket as invalid, and opening a new ticket for the equery issue. I would also open a new ticket for the use flag issue, but they may be working as intended. Let me know what you think, thanks.
I do not think there is an issue in package nor an issue with equery, in time you get use to the output of the tools, the customization in gentoo is powerful.
actual issue fixed in https://bugs.gentoo.org/show_bug.cgi?id=572574
