MacGPG2: scdaemon PC/SC OPEN failed: sharing violation (0x8010000b)
My hardware token (YubiKey NEO) has several applets, including PIV and OpenPGP. Needless to say, I need and use both of them.
On Mac OS X, tokend connects to the token immediately upon its insertion, which is necessary to present the token as a (PIV) keychain in the Keychain Access, and make its keys/certificates otherwise available to the Mac OS X applications.
However, when I try to use gpg, or any component of GPGTools that needs access to this token (to its OpenPGP applet), this tool detects that the token is already being used - and refuses to connect to it, with the following messages in the /tmp/scdaemon.log:
2016-09-06 21:09:24 scdaemon PC/SC OPEN failed: sharing
2016-09-06 21:09:24 scdaemon PC/SC OPEN failed: sharing violation (0x8010000b)
2016-09-06 21:09:33 scdaemon PC/SC OPEN failed: sharing violation (0x8010000b)
I would expect and like sharing - especially since they share the “token” but not the “applet”: PIV applications cannot use OpenPGP interface, and vs. versa (I think).
I know about the design ideology (security concerns), but this kills usability, particularly with Apple Mail, where I need to process both PGP-protected and S/MIME-protected emails (obviously from different crowds, but that is not relevant).
Same applies to Thunderbird, except there is no tokend involved - just inability of GPG suite to share the token with PIV suite. I’d like it remedied.
There is a workaround - but it is ugly: insert the token, start Apple Mail, process all the S/MIME emails. Quit Mail, kill OpenSC.tokend. Run “gpg2 —card-status” (assuming it connects and provides expected result). Start Mail, process PGP/MIME emails. Quit Mail, remove the token, re-insert it - now PIV and S/MIME are functioning again.
Ugly as a mule. Can you please either remove this restriction, or better yet - add a configuration parameter that would allow token sharing?
Mac OS X 10.11.6 (15G1004) Libmacgpg 0.7 769 GPGMail 2.6.1 1151 GPG Keychain 1.3.1 1233 GPGServices 1.11 907 MacGPG2 2.0.30 875 GPGPreferences 2.0 887 Pinentry 0.9.7 2
- 2016-09-07_02-13_DebugInfo.gpg 64.5 KB
Showing page 2 out of 2. View the first page
Comments are currently closed for this discussion. You can start a new one.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 31 Posted by Steve on 18 Jul, 2017 09:31 PM
The relevant commit is here:
32 Posted by mouse008 on 26 Jul, 2017 03:47 AM
Continuation. MacOS 10.12.6. Yubikey 4, PIV and OpenPGP applets provisioned.
Start Apple Mail. Reply to an S/MIME email with a signed S/MIME email. Reply to an OpenPGP email with a signed OpenPGP email. In a Terminal run “yubico-piv-tool -a status” to select PIV applet on the token again. Send a signed S/MIME email. So far so good.
Now in a Terminal run “gpg —card-status” to get OpenPGP applet selected, and try to reply to an OpenPGP email with a signed OpenPGP. Fails with the error
gpg: signing failed: Card error gpg: signing failed: Card error
Screenshot of the error attached. After that error, neither GPG keys on the token, or "normal" GPG keys in the keyring work - same error. Re-inserting the token and restarting Apple Mail help, but the above scenario leads to this error.
33 Posted by mouse008 on 26 Jul, 2017 03:14 PM
P.S. Even with the current "physical/manual" workaround of having to re-insert the token, this situation is still far-far better than what we had with the scdaemon from upstream.
So please don't take this report as criticism or disparagement - in fact, the changes in the Nightlies made GPGTools actually usable on Sierra with multi-applet tokens (and probably enabled running one session of Apple Mail using multiple tokens - some PIV and some OpenPGP). Thank you!
P.P.S. I hope you guys are already looking at the High Sierra betas? ;-)
Support Staff 34 Posted by Steve on 02 Aug, 2017 11:32 AM
Thanks a lot for thoroughly testing this and providing feedback.
I am going to close this discussion for now. Sadly, at this moment, we do not have the capacity to invest more time to this area.
Steve closed this discussion on 02 Aug, 2017 11:32 AM.
Steve closed this discussion on 10 May, 2019 12:27 PM.