Mailing List Archive

Multiple readers with scdaemon
Hello,

I recently bought a yubikey. When connecting it to my laptop that
already has a smartcard reader, gnupg is not detecting it when using pcscd.

I discovered that the readers detected by scdeamon is linked to the
order the reader has been initialized by pcscd and only the first reader
is used (as written in the manpage).

To make my yubikey work I had to add a "reader-port" option with (a
substring of) the yubikey name, but surprisingly if the yubikey is not
present it fails back to the other reader.

The situation is a bit weird, at the same time scdaemon is only using
the first reader by default, adding "reader-port" make scdaemon uses
that reader except if not present. Don't get me wrong the fact that
fails back to the 1st reader is "good" in the sense that in the end it
allows the use of 2 readers, but it's just weird IMHO.

Are there any plans to support multiples readers? Shouldn't
"reader-port" makes scdeamon really stick to that reader and not
fallback if not present (hasn't that security implications?) Shouldn't
"reader-port" matches the full name of the reader instead of a substring
of it?

Kind regards,

Laurent Bigonville

PS: I lost access to the email address of the account on the BTS, is
there a way to reset the password of it without?



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Multiple readers with scdaemon [ In reply to ]
Laurent Bigonville <bigon@bigon.be> wrote:
> Are there any plans to support multiples readers?

When you can disable PC/SC, multiple readers are supported by the
internal CCID driver of scdaemon (through libusb, directly).

Currently, I don't have a specific plan to support multiple readers with
PC/SC. There are different PC/SC implementations, I mean, the one of
Windows, the one of macOS, and pcsc-lite+libccid. In this situation, it
is a bit harder for me to introduce new feature to scdaemon with PC/SC.
I could test with pcsc-lite, but major users of scdaemon with PC/SC are
on Windows or macOS.

And it seems for me that PC/SC is not actively developed on Windows and
macOS. If it is the case, I'd like to put my energy to the internal
CCID driver.

BTW, I'm curious if the internal CCID driver can be used on Windows and
macOS.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Multiple readers with scdaemon [ In reply to ]
Le 09/05/18 à 02:11, NIIBE Yutaka a écrit :
> Laurent Bigonville <bigon@bigon.be> wrote:
>> Are there any plans to support multiples readers?
> When you can disable PC/SC, multiple readers are supported by the
> internal CCID driver of scdaemon (through libusb, directly).

In that case I cannot use other smartcards if scdaemon is still running,
this is quite annoying.

> Currently, I don't have a specific plan to support multiple readers with
> PC/SC. There are different PC/SC implementations, I mean, the one of
> Windows, the one of macOS, and pcsc-lite+libccid. In this situation, it
> is a bit harder for me to introduce new feature to scdaemon with PC/SC.
> I could test with pcsc-lite, but major users of scdaemon with PC/SC are
> on Windows or macOS.
>
> And it seems for me that PC/SC is not actively developed on Windows and
> macOS. If it is the case, I'd like to put my energy to the internal
> CCID driver.
>
> BTW, I'm curious if the internal CCID driver can be used on Windows and
> macOS.
Isn't pcsc-lite used on MacOSX the same as the one on GNU/Linux?

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Multiple readers with scdaemon [ In reply to ]
Hello,

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.

On 9/05/18 13:49, Laurent Bigonville wrote:
> Le 09/05/18 à 02:11, NIIBE Yutaka a écrit :
>> Laurent Bigonville <bigon@bigon.be> wrote:
>>> Are there any plans to support multiples readers?
>> When you can disable PC/SC, multiple readers are supported by the
>> internal CCID driver of scdaemon (through libusb, directly).
>
> In that case I cannot use other smartcards if scdaemon is still
> running, this is quite annoying.
>
>> Currently, I don't have a specific plan to support multiple readers with
>> PC/SC.  There are different PC/SC implementations, I mean, the one of
>> Windows, the one of macOS, and pcsc-lite+libccid.  In this situation, it
>> is a bit harder for me to introduce new feature to scdaemon with PC/SC.
>> I could test with pcsc-lite, but major users of scdaemon with PC/SC are
>> on Windows or macOS.
>>
>> And it seems for me that PC/SC is not actively developed on Windows and
>> macOS.  If it is the case, I'd like to put my energy to the internal
>> CCID driver.
>>
>> BTW, I'm curious if the internal CCID driver can be used on Windows and
>> macOS.
> Isn't pcsc-lite used on MacOSX the same as the one on GNU/Linux?
>
If I can trust this
page(https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite), it says
that:

"PC/SC is the de facto cross-platform API for accessing smart card
readers. It is published by PC/SC Workgroup but the “reference
implementation” is Windows. Linux and Mac OS X use the open source
pcsc-lite package."

So this is far from being dead, and the API itself (not the pcsc-lite
implementation) is working on all platforms including MS/Windows



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Multiple readers with scdaemon [ In reply to ]
On 18/09/2019 17:28, Laurent Bigonville via Gnupg-devel wrote:
> If I can trust this
> page(https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite), it says
> that:
>
> [...snip...]

> So this is far from being dead

Erm, that page hasn't been edited since 2012 and the link to pcsc-lite
is dead... just saying. The Alioth server has been taken down over a
year ago, if I'm not mistaken, so it's not a recently dead link. I don't
see why you say it indicates aliveness.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
Re: Multiple readers with scdaemon [ In reply to ]
Hello,

Laurent Bigonville <bigon@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:

https://dev.gnupg.org/T4620

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
energy.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Multiple readers with scdaemon [ In reply to ]
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@fsij.org> wrote:
>
> Hello,
>
> Laurent Bigonville <bigon@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:
>
> https://dev.gnupg.org/T4620
>
> 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
> energy.
> --
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel