Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> To be concrete, i believe the two proposed solutions for users are:
[...]
> Do not use CCID
> ---------------
>
> echo disable-ccid:0:1 | gpgconf --change-options scdaemon
>
Correct.
The things for PCSC is a bit complicated. Let me describe.
> Do not use PCSC
> ---------------
>
> Either system-wide:
>
> apt purge pcscd
This works. Actually, this is not mandatory. It is OK to have pcscd
package installed **if not used**.
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.
When pcscd is not running, ccid-driver just works well even if pcscd
package is installed.
Internal ccid-driver fails when pcscd service is running and it tries to
open USB devices which are now under the control of pcscd.
And when pcscd is running on a system,
> 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.
>> However, the gnupg package maintainers might want to think about how
>> to best document this issue.
>
> aiui, CCID is the preferred method for scdaemon to access smartcards.
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 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.
--
