Multiple readers with scdaemon
uri at mit.edu
Thu Sep 19 02:13:00 CEST 2019
Another problem is that GnuPG insists on opening the card in an exclusive mode - which is unacceptable for cards/tokens with multiple applets (OpenPGP and PIV is what I've got), as different apps require use of both applets, sometimes running in parallel - like a browser session that uses PIV to authenticate to the server, an email session that may use both PIV and OpenPGP applets to deal with S/MIME and PGP/MIME emails, and occasional SSH operations during that time.
Sent from my test iPhone
> On Sep 18, 2019, at 19:51, NIIBE Yutaka <gniibe at fsij.org> wrote:
> Laurent Bigonville <bigon at bigon.be> wrote:
>> I'm coming back to this question after almost a year, but this is still
>> an issue for me as without pcscd support, I cannot use other smartcard
>> if scdaemon is running.
> It is not ignored. Sorry, it has been in low priority state.
> Well, the multiple readers support with PC/SC is tracked here:
> The feature is now in the master branch (this week). I tested the
> feature in my environment of Windows under qemu VM, too. It works for
> this environment of mine.
> So far, it is only lightly tested. I think that there are some
> complicated use cases like: using two readers for OpenPGP cards, and
> another for different card for different application. Those cases are
> not tested at all. Your testing will be appreciated.
> Still, in my opinion, I prefer access to USB device directly by libusb
> (not through PC/SC service), when it is possible.
> In the development of the support of multiple readers with PC/SC, I
> tried to use the API of SCardGetStatusChange and SCardCancel within a
> single context, so that scdaemon don't need to poll periodically. I
> realized that the API is not good enough (there are fundamental race
> conditions). So, for this time, I don't pursue to remove scdaemon's
> periodical check with SCardGetStatus. I know that this is not a perfect
> situation and some users of laptop complain about possible more use of
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2894 bytes
Desc: not available
More information about the Gnupg-devel