Hello, Thank you very much for the discussion. I appreciate the viewpoints from users. No, it's not frustrating at all.
Daniel Kahn Gillmor <d...@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. --