Add option for scdaemon to open smart card in non-exclusive mode
uri at mit.edu
Mon Sep 12 03:18:24 CEST 2016
I use a token that has both PIV and OpenPGP applets provisioned. Some of my emails are secured by PGP/MIME, and others by S/MIME (depending on the crowd I’m communicating with, not surprisingly).
The problem is that scdaemon insists on grabbing the token, so first - it refuses to access it when another daemon (tokend in this case) is connected to it (tokend on Mac OS X is the daemon that makes the token available to all the native OS X applications, such as Safari, Google Chrome, Apple Mail, MS Outlook, Adobe Acrobat, Keychain Access, etc. etc.). Tokend is talking to PIV applet.
So the way it is now, I have to kill tokend in order for scdaemon to access the card. And then there’s no way for tokend to get back to it until the card is re-inserted.
Here’ where it is really inconvenient. My ideal workflow in processing emails would be - use whatever standard the given email came in under and respond in kind. Just like with soft certificates and keys. The way it is with scdaemon now, however, I have to process all the S/MIME emails first, then kill tokend, exit Apple Mail, make sure gpg2 can access the card, start Apple Mail, process PGP/MIME emails, quit Apple Mail, remove the card. Since the token is used for things other than email, it is really inconvenient, and for no real security benefit.
What I am asking for: add a configuration option that would tell scdaemon to open the token in non-exclusive (shared) mode. Keep it off by default. But those who (like me) have need to use multi-applet tokens, would be able to have a smooth workflow.
This has already been brought up by Martin Paljak in 2011: https://lists.gnupg.org/pipermail/gnupg-devel/2011-August/026210.html . I think it’s time we do that now.
P.S. Proposed timeout setting does not solve the problem, because timeout appears to be for powering the card down. This does not help - the card should stay powered up.
uri at mit.edu<mailto:uri at mit.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnupg-devel