hi gniibe-- thanks for the thoughtful followup!
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.
> 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?
> 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.
This is because the pcscd service itself will be locking the card in an
exclusive fashion, right?
> 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.
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?
Thanks for your work on this,
--dkg
signature.asc
Description: PGP signature
