Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka <gni...@fsij.org> wrote: >> This works. Actually, this is not mandatory. It is OK to have pcscd >> package installed **if not used**. > > I take it you mean that the system-wide pcscd service itself needs to be > stopped.
In another message: > I take it you mean that the the system-wide pcscd service itself needs > to be disabled and prevented from being started again: > > systemctl disable --now pcscd.socket pcscd.service No. It is OK systemd watches the socket to invoke pcscd.service, as long as no client tries to connect the socket (by libpcsclite.so.1.0.0). >> The order of usage by scdaemon is: >> >> (1) First, try internal ccid-driver. >> (2) Then, try PC/SC service. >> >> I enbugged in 2.1.18 and the transition (1)->(2) doesen't work well now. > > Are you saying that 2.1.18-4 isn't a sufficient fix for this? Are there > other patches we should consider applying in debian to smooth this > (1)->(2) transition? No, 2.1.18-4 (or even master in upstream) is not a sufficient fix. I don't have an idea of any good solution at hand, yet. Thus, workaround of "disable-ccid". >>> or per-user: >>> >>> echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon >> >> ... this does not work. A user need to kill pcscd service. > > This is because the pcscd service itself will be locking the card in an > exclusive fashion, right? Let me clarify. It is not the problem of locking of the card, but problem of which process is using USB device. Only a single process can claim an interface of a USB device at given time. And pcscd serves all CCID devices to client(s). Upon initialization of pcscd, pcscd claims all CCID devices (= card readers). Then, it starts accepting request from clients. A client asks list of card readers, and then connects to a card reader. For PC/SC service, it is possible for client to access a card in shared fashon or exclusive fashion. Once pcscd is invoked, all CCID devices are under control of pcscd, even if there are no client. >> For GNU/Linux system, yes. However, there are users (especially in >> Eurpoe), who want to use other smcartcards like citizen ID card >> simultaneously/interchangeably on a system. scdaemon is not a system- >> wide service for all smartcards, but it's specific to OpenPGP card and >> it's per user service for gpg-agent. > > Would it work for the user to tell pcscd to explicitly ignore certain > devices that are expected to be handled only by scdaemon? that would > allow pcscd to run and serve the non-OpenPGP cards, while allowing > scdaemon to do its work with the OpenPGP cards. In some use cases, this would be possible; Say, Yubikey and Nitrokey are handled only by scdaemon through its CCID driver. The other use case is: some users want to use a single card reader for both of OpenPGP card and non-OpenPGP card, interchangeably. > I'm not suggesting that this would be particularly easy (or even > possible, in some cases) to configure, but i'm just trying to explore > the space of options for users. > > This should really all be much easier, sigh :( > >>> Would it make sense instead to just change the defaults for pcsc-driver >>> to be the empty string? >> >> The problem is pcscd holds the access to device, which prevents >> ccid-driver's access. >> >> Current order makes some sense. Specific one first, then catch-all one >> second. However, in future implementation of scdaemon, perhaps, >> changing the order of access (pcscd first, ccid-driver second) would >> also make sense for some use cases. > > so many options! and yet users generally just want things to Just Work™ > :/ > > Do you want to propose any documentation or notes about this situation? > README.Debian, or something else? I think that an explanation like following is good. If you want to use PC/SC service, please add disable-ccid in .gnupg/scdaemon.conf. Or do: echo disable-ccid:0:1 | gpgconf --change-options scdaemon --