[pkg-gnupg-maint] Bug#854005: Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Hello,

Thank you very much for the discussion.  I appreciate the viewpoints
from users.  No, it's not frustrating at all.

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> Can we offer a user experience that doesn't involve them making a choice
> between two indistinguishable options?
>
> A few ideas (no idea how plausible they are to implement, or even
> whether they'd solve the problems people are having):
>
>  0) if pcscd is running and has claimed the smartcard, then by default
>     disable ccid?
>
>  1) for each device that is detected by ccid, try to access it.  If it
>     is not accessible because someone else has it locked, and pcscd
>     appears to be running, and a similar-looking device is accessible
>     through pcsc, then skip the device entirely without complaint.
>
>  2) revert whatever the change was in 2.1.18 (handling multiple cards?)
>     that made things worse for people who had things working in 2.1.17
>
> Any other suggestions?

2) would be easy choice if any breaking is considered bad and that's the
highest priority.  I am sorry that I break this use case on GNU/Linux.
I thought I tested carefully, but my test coverage is apparently not
that large, I learned.

On GNU/Linux, use of PC/SC service is not recommended for OpenPGP card
(installing PC/SC is OK) and the use of different smartcards with PC/SC
(OpenPGP card together with other cards) requires struggle anyway, so, I
think that asking such users would be an option.

No, I don't say I won't fix this issue.  Surely, I will.

Currently, I am considering something like 1).



Some more information, from here.  Please skip.

> My only concern with this explanation is that most people (even those
> with smartcards!) have *no*idea* whether they "want to use PC/SC
> service."  They just bought a smartcard (or were given one by their
> employer or their government or their friend or whatever) and they know
> they're supposed to use it.

Yes.  This is an important point.

Unfortunately, I think that current situation of use of OpenPGP card is
somehow far from this.  Let me explain.

The situation is complicated becase only some limited card readers works
for OpenPGP card.  Since most users prefer longer key size of RSA these
days, the use of OpenPGP card requires tough condition to card reader.
Some workaround in the lower level of USB communcation for specific card
readers are implemented in the internal CCID driver, so, if the use if
for OpenPGP card, internal CCID driver is better option.

Please note that this is common:

    A card reader itself works well on the machine, but OpenPGP card
    with (common configuration of) RSA-4096 doesn't work with a reader.
    While --card-status works, decryption fails.

I think that something like this is common problem in smartcard
industry.  Current industrial practice seems to be a smartcard requires
specific card reader and vendor's offering application specific driver
which doesn't use general purpose PC/SC service.  Ideally, such
fragmentation should be avoided and it would be better to put all
lower-level knowledge/workaround to PC/SC service, so that all
application can be share common ground.  But it seems going
another direction.

Perhaps, card + reader can not be abstracted well.


And I think that there are two distinct use cases.

(1) Smartcard is given by external entity to user.  He has a little
    interest in detail.  The purpose is "just use it".

(2) User cares a lot on her privacy, and that is the reason why she
    starts to use smartcard.

It would make sense to put priority to the use case of (1), because
there are more users in this situation.  And since PC/SC serivice tries
to support more card readers, which are listed in
/etc/libccid_Info.plist, it might be a natural choice for a user in this
situation to prefer PC/SC even if he only uses OpenPGP card.

I agree that it is best if we don't need to ask users of (1) to put
"disable-ccid" in his configuration file.  So, I will try, but I don't
have a good solution at hand, right now.

Please note that current default of scdaemon is for the use case of (2).
And I recommend use of the internal CCID driver, a dedicated card reader
access implementation specific to OpenPGP card.  For the readers which
are listed in /lib/udev/rules.d/60-scdaemon.rules, it is easy to use (I
mean, no other configuration needed).  But user needs her own udev rules
if her reader is not listed there.
--