MacGPG2: scdaemon PC/SC OPEN failed: sharing violation (0x8010000b)

mouse008's Avatar

mouse008

Sep 07, 2016 @ 02:13 AM

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[67807] PC/SC OPEN failed: sharing violation (0x8010000b)
2016-09-06 21:09:24 scdaemon[67807] PC/SC OPEN failed: sharing violation (0x8010000b)
2016-09-06 21:09:33 scdaemon[67807] PC/SC OPEN failed: sharing violation (0x8010000b)

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

Additional info
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
  1. Support Staff 1 Posted by Luke Le on Sep 07, 2016 @ 11:32 AM

    Luke Le's Avatar

    Hi,

    we absolutely understand your troubles and don't like this limitation either.
    It's best to bring this issue up with the gnupg developers at the developer mailinglist https://lists.gnupg.org/mailman/listinfo/gnupg-devel. We've brought this issue up in the past, but if I remember correctly there was no answer, and we didn't want to change this without their go ahead.

  2. 2 Posted by mouse008 on Sep 08, 2016 @ 09:03 PM

    mouse008's Avatar

    We've brought this issue up in the past, but if I remember correctly there was no answer, and we didn't want to change this without their go ahead.

    I am not sure this is the right way forward, because in the past GnuPG developers showed what I'd call a "religious attitude" towards this and some other issues.

    The choice is between greater security and better usability. They opted to sacrifice usability for security. I think that the security loss here would be minimal, while usability gains would be significant. Neither side has performed a comprehensive security and risk analysis, but the common sense seems to bear with my assertions.

    I again urge the GPGTools developers to add the ability to turn the "non-sharing" off via config option or parameter.

    P.S. I will bring this up with the GnuPG people, but despite the fact that I've been on the original PGP Evaluation Team back in the 90-ties I expect no progress from that end.

  3. 3 Posted by mouse008 on Sep 13, 2016 @ 12:42 AM

    mouse008's Avatar

    I've submitted a request to gnupg-devel at gnupg.org. If there is a response - I'll post here. In the meanwhile - could you please add a config option for scdaemon to not connect to the token in the exclusive mode?

    P.S. See Martin Paljak's good explanation why it makes sense.

  4. Support Staff 4 Posted by Steve on Nov 14, 2016 @ 04:43 PM

    Steve's Avatar

    any response? can you add a link to the web-version of your mailinst list post?

  5. 5 Posted by mouse008 on Nov 15, 2016 @ 04:53 AM

    mouse008's Avatar

    See this thread on the Gnupg-devel mailing list.

    I think we all might be better off doing it here.

    P.S. As I'm on Sierra now, I probably won't benefit from any development until the Mail plugin works with the new Apple Mail again.

  6. Support Staff 6 Posted by Luke Le on Nov 18, 2016 @ 07:41 PM

    Luke Le's Avatar

    Hi mouse008,

    we're making good progress on Sierra and hope to have a first beta in the next few weeks, so that's something :)

    There's been a branch on github which implemented very experimental support for this shared access feature. I've tried it once and it basically worked, so this could be taken as starting point. We also do believe that this feature is crucial for properly using a token with PGP on macOS. The workaround killing tokend and others are simply painful.

    Unfortunately I could only find this commit on github: https://github.com/lbschenkel/gnupg/commit/6d1728b9a0554edc948764dc...
    Hardly doubt that this is all that's necessary.

  7. 7 Posted by mouse008 on Nov 23, 2016 @ 11:54 PM

    mouse008's Avatar

    First - it's great to know that Sierra version is coming.

    Second - I'm very glad that the team agrees with me that this issue has to be resolved, and by means nicer than killing tokend. ;-)

    The referred commit makes sense. As for whether it is sufficient - it depends on whether the scdaemon (or gpg-agent - I keep mixing the two, there are so many demons around :) code can check the token status and adjust if necessary (e.g., re-login if the token's security status was reset or another applet was selected).

    I'd be happy to collaborate with the developers who work on this issue.

  8. Support Staff 8 Posted by Steve on Dec 01, 2016 @ 04:19 PM

    Steve's Avatar

    Unfortunately we currently don't have the resources to work on this issue. Once GPGMail for Sierra is ready we might be able to revisit it.

    We have a ticket for this problem. I connected this discussion with the existing ticket. That means, should this discussion get closed, it will be re-opened as soon as the ticket is closed. That way you'll stay in the loop and get notified as soon as we have news. Feel free to open a new discussions should you run into further problems or need assistance.

    All the best,
    steve

  9. 9 Posted by mouse008 on Dec 14, 2016 @ 04:58 PM

    mouse008's Avatar

    Unfortunately we currently don't have the resources to work on this issue. Once GPGMail for Sierra is ready we might be able to revisit it.

    Understand perfectly. I want GPGMail to run on Sierra as much! ;-)

    Are there specific problems? If you could share them (here, or privately) I might be able to do something about them.

    We have a ticket for this problem. I connected this discussion with the existing ticket.

    Thank you!

  10. Support Staff 10 Posted by Steve on Dec 30, 2016 @ 09:08 PM

    Steve's Avatar

    GPGMail beta 1 for 10.12 Sierra is out:

    https://gpgtools.tenderapp.com/discussions/problems/49449

  11. Steve closed this discussion on Dec 30, 2016 @ 09:08 PM.

  12. Steve re-opened this discussion on Jun 21, 2017 @ 12:13 PM

  13. Support Staff 11 Posted by Steve on Jun 21, 2017 @ 12:13 PM

    Steve's Avatar

    Hey mouse008,

    could you test the latest nightly from here: https://releases.gpgtools.org/nightlies/ and let me know if that changes anything regarding the usage of S/MIME and OpenPGP with your smartcard?

    The nightly now comes with gpg 2.1 so we'd be curious to learn if that has changed anything for the better or worse.

    Kind regards,
    steve

  14. 12 Posted by mouse008 on Jun 21, 2017 @ 06:34 PM

    mouse008's Avatar

    First, I'm happy with the move to GPG-2.1. Having said that - everything else is worse now. I'm on MacOS Sierra 10.12.5. When I start Apple Mail and do S/MIME stuff with the nightly, there's no way to proceed to OpenPGP even by killing the tokend:

    $ gpg2 --version
    gpg: keyserver option 'include-disabled' is unknown
    gpg: keyserver option 'honor-http-proxy' is unknown
    gpg (GnuPG/MacGPG2) 2.1.21
    libgcrypt 1.7.6
    Copyright (C) 2017 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.


    Home: /Users/ur20980/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ gpg2 --card-status gpg: keyserver option 'include-disabled' is unknown gpg: keyserver option 'honor-http-proxy' is unknown gpg: selecting openpgp failed: Operation not supported by device gpg: OpenPGP card not available: Operation not supported by device $

    When I switch to OpenPGP mode, even the checkboxes for encrypting and signing outgoing email disappear (see the attached screenshots).

  15. Support Staff 13 Posted by Luke Le on Jun 21, 2017 @ 06:41 PM

    Luke Le's Avatar

    Hi,

    for some (not necessarily obvious) reason, gpg refuses to work if unknown options are found.
    So you'll have to remove the following options:
    include-disabled
    honor-http-proxy

    Once we completely switch to gnupg2.1 we'll hopefully be abe to provide a smoother migration.

  16. 14 Posted by mouse008 on Jun 21, 2017 @ 06:56 PM

    mouse008's Avatar
    $ gpg2 --card-status
    gpg: selecting openpgp failed: Operation not supported by device
    gpg: OpenPGP card not available: Operation not supported by device
    $
    

    The above is symptomatic of trying to fail on "exclusive open".

  17. 15 Posted by mouse008 on Jun 21, 2017 @ 07:04 PM

    mouse008's Avatar

    Also, with GPGTools (persistent and old bug) signed and encrypted messages (S/MIME) are showed only as Signed. When I uninstall GPGTools, Apple Mail depicts them correctly (as Signed, Encrypted, or Signed and Encrypted as appropriate). See the attached screenshots:

  18. 16 Posted by mouse008 on Jun 21, 2017 @ 09:51 PM

    mouse008's Avatar

    Screenshots are attached here.

  19. 17 Posted by mouse008 on Jun 21, 2017 @ 10:19 PM

    mouse008's Avatar

    I re-installed 2017-b3-v2, but still unable to even access the card via GPG, let alone do OpenPGP email. It may be a Sierra thing. I'm running 10.12.5.

    $ cat ~/.gpg-agent-info 
    GPG_AGENT_INFO=/Users/ur20980/.gnupg/S.gpg-agent:4331:1
    SSH_AUTH_SOCK=/Users/ur20980/.gnupg/S.gpg-agent.ssh
    SSH_AGENT_PID=4331
    $ . ~/.gpg-agent-info 
    $ gpg2 --card-status
    gpg: selecting openpgp failed: Card not present
    gpg: OpenPGP card not available: Card not present
    $
    

    Update I was too hasty. Getting home (another MacOS Sierra 10.12.5 machine), uninstalling GPGTools and installing plain gnupg-2.0 from Macports (port install gnupg2 gpg-agent pinentry-mac) I was able to work with the card using gpg2 - after killing the tokend of course.

    Problem: scademon still fails to work, as indicated by the screen output and the log messages. Screen output (look at the first line!):

    $ gpg2 --card-status
    gpg: can't connect to the agent - trying fall back
    Application ID ...: D2760001240102000006038241700000
    Version ..........: 2.0
    Manufacturer .....: Yubico
    . . . . .
    ssb>  2048R/0x43EEB185FD3F6BEE  created: 2016-01-12  expires: 2019-06-11
                          card-no: 0006 03824170
    $
    

    The log:

    . . . . .
    2017-06-21 21:42:53 scdaemon[60520] pcsc_control failed: invalid parameter (0x80100004)
    2017-06-21 21:42:53 scdaemon[60520] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65538
    2017-06-21 21:42:54 scdaemon[60520] updating slot 0 status: 0x0000->0x0007 (0->1)
    2017-06-21 21:42:54 scdaemon[60520] sending signal 31 to client 60516
    2017-06-21 21:43:11 scdaemon[60520] DBG: asking for PIN '||Please enter the PIN'
    2017-06-21 21:43:16 scdaemon[60520] DBG: asking for PIN '|N|New PIN'
    2017-06-21 21:44:35 scdaemon[60520] signatures created so far: 57
    2017-06-21 21:44:35 scdaemon[60520] DBG: asking for PIN '||Please enter the PIN%0A[sigs done: 57]'
    2017-06-21 21:46:56 scdaemon[60520] updating slot 0 status: 0x0007->0x0000 (1->2)
    2017-06-21 21:46:56 scdaemon[60520] sending signal 31 to client 60516
    2017-06-21 21:47:10 scdaemon[60592] PC/SC OPEN failed: sharing violation (0x8010000b)
    2017-06-21 21:47:10 scdaemon[60592] PC/SC OPEN failed: sharing violation (0x8010000b)
    2017-06-21 21:47:38 scdaemon[60592] PC/SC OPEN failed: sharing violation (0x8010000b)
    2017-06-21 21:47:41 scdaemon[60592] PC/SC OPEN failed: sharing violation (0x8010000b)
    2017-06-21 21:53:54 scdaemon[60592] pcsc_control failed: invalid parameter (0x80100004)
    2017-06-21 21:53:54 scdaemon[60592] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65538
    2017-06-21 21:53:55 scdaemon[60592] updating slot 0 status: 0x0000->0x0007 (0->1)
    2017-06-21 21:53:55 scdaemon[60592] sending signal 31 to client 60516
    
    Process 60516 is gpg-agent:
    $ ifrun 60516
    mouse              60516   0.0  0.0  2463360   1040   ??  Ss    9:42PM   0:00.09 gpg-agent --homedir /Users/uri/.gnupg --use-standard-socket --daemon
    $
    
  20. Support Staff 18 Posted by Steve on Jul 10, 2017 @ 01:23 PM

    Steve's Avatar

    Hi mouse008,

    unfortunately unless gnupg enables SHARED mode, you'll be continuing to run into issues.
    Following are some workarounds proposed by usb key vendor nitrokey:
    https://www.nitrokey.com/documentation/frequently-asked-questions#o...

    Unless tokend is moved, macOS will try to restart it, which probably causes the latest issue you're seeing.

    Apparently they were quite successful patching gnupg itself, and according to them the single line change we've seen in one of my previous posts (git commit link) suffices.
    https://www.nitrokey.com/documentation/frequently-asked-questions#h...

    We've filed a ticket with gnupg and hope this will be adressed and this now lives in the GnuPG bug tracker as #3267 Should you consider patching gnupg itself, it would be interesting if you could report back your experience with using gnupg in PCSC_SHARED mode

    All the best,
    steve

  21. Support Staff 19 Posted by Steve on Jul 11, 2017 @ 02:11 PM

    Steve's Avatar

    Hi mouse008,

    this issue has been fixed. It would be helpful if you could test the fix. Please download our latest nightly GPG Suite. That page also has sig and SHA1 to verify the download. Build 1932n and later have the fix.

    Then add the line "shared-access" to ~/.gnupg/scdaemon.conf

    Looking forward to your feedback.

    Best, steve

    Disclaimer: This is a development version which has not been thoroughly tested yet, so bugs or crashes are to be expected. Thanks for helping us test this fix.

  22. 20 Posted by mouse008 on Jul 11, 2017 @ 07:27 PM

    mouse008's Avatar

    I've installed the 1932n. Inconclusive yet - but very promising.

    I will do more tests when I'm back - and report. Again, so far it
    looks far-far better than before.

  23. Support Staff 21 Posted by Steve on Jul 12, 2017 @ 09:31 AM

    Steve's Avatar

    Great, just let us know when you get around to testing this a bit more.

  24. 22 Posted by mouse008 on Jul 13, 2017 @ 02:38 AM

    mouse008's Avatar

    Hmm... I've just installed the current (1934n) suite on my "main" Sierra 10.12.5 machine. And observe with surprise that it fails to work, in a weird way:

    $ gpg --version
    gpg (GnuPG/MacGPG2) 2.1.21
    libgcrypt 1.7.8
    Copyright (C) 2017 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.


    Home: /Users/uri/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ gpg --card-status gpg: error getting version from 'scdaemon': No SmartCard daemon gpg: OpenPGP card not available: No SmartCard daemon $

    Here's gpg-agent.conf:

    pinentry-program /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac
    #pinentry-program /opt/local/bin/pinentry-mac.app/Contents/MacOS/pinentry-mac
    #pinentry-program /Applications/MacPorts/pinentry-mac.app/Contents/MacOS/pinentry-mac
    scdaemon-program /usr/local/MacGPG2/libexec/scdaemon
    #scdaemon-program /opt/local/libexec/scdaemon
    default-cache-ttl 600
    max-cache-ttl 7200
    #use-standard-socket
    enable-ssh-support
    write-env-file
    

    Attaching gpg-home-fixer.log.

  25. 23 Posted by mouse008 on Jul 13, 2017 @ 02:41 AM

    mouse008's Avatar

    More in the same key:

    $ /usr/local/MacGPG2/libexec/scdaemon --daemon
    SCDAEMON_INFO=/Users/uri/.gnupg/S.scdaemon:20560:1; export SCDAEMON_INFO;
    $ ifrun scdaemon
    uri             20560   0.0  0.0  2443612    460   ??  Ss   10:39PM   0:00.00 /usr/local/MacGPG2/libexec/scdaemon --daemon
    $ gpg --card-status
    gpg: error getting version from 'scdaemon': No SmartCard daemon
    gpg: OpenPGP card not available: No SmartCard daemon
    $ ifrun gpg-agent
    uri             19543   0.0  0.0  2443632   1084   ??  S    10:24PM   0:00.01 /bin/bash /usr/local/MacGPG2/libexec/shutdown-gpg-agent
    uri             19537   0.0  0.0  2471616    976   ??  Ss   10:24PM   0:00.11 /usr/local/MacGPG2/bin/gpg-agent --daemon
    $
    

    Then I killed everything gpg-related, and tried again. Surprisingly, seemed to get success. The following is very encouraging:

    $ gpg --card-status


    Reader ...........: Yubico Yubikey NEO OTP U2F CCID Application ID ...: D2760001240102000006038241700000 Version ..........: 2.0 Manufacturer .....: Yubico . . . . . Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 0 0 0 PIN retry counter : 0 0 0 Signature counter : 0 Signature key ....: 7ACC 2166 010F CD10 AAB7 5465 6C34 A497 41E9 0902 created ....: 2016-01-04 00:58:53 Encryption key....: 2080 5D50 EC69 217C 2E7A B789 D3C7 9381 E5A4 FF45 created ....: 2010-07-29 23:37:37 Authentication key: FE2A C36E CFF7 4903 48DD 6F4E 43EE B185 FD3F 6BEE created ....: 2016-01-12 00:23:14 General key info..: sub rsa2048/0x6C34A49741E90902 2016-01-04 Uri Blumenthal (MIT) <[email blocked]> sec rsa2048/0x9BAD9629C89BF6E5 created: 2010-07-29 expires: 2019-06-10 ssb> rsa2048/0xD3C79381E5A4FF45 created: 2010-07-29 expires: 2019-06-11 card-no: 0006 03824170 ssb> rsa2048/0x6C34A49741E90902 created: 2016-01-04 expires: 2019-06-11 card-no: 0006 03824170 ssb> rsa2048/0x43EEB185FD3F6BEE created: 2016-01-12 expires: 2019-06-11 card-no: 0006 03824170 $ pkcs15-tool -r 01 Using reader with a card: Yubico Yubikey NEO OTP+U2F+CCID -----BEGIN CERTIFICATE----- MIIDoDCCAgigAwIBAgIEV6nftjANBgkqhkiG9w0BAQsFADAaMRgwFgYDVQQDDA9G b3Jlc3QgQ0EgUlNBIDQwHhcNMTYwODA5MTM1MjA5WhcNMTkwODA5MTM1MjA5WjAY MRYwFAYDVQQDDA1VcmkgdGhlIEdyZWF0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAnXiivwb9IBkbFPH2er4bAbGf5++CZNbhPX2U6YZXgvfcJNap40xR . . . . . FdIJBNU3dH0aC0TLoNi2JbQCICUFDUHTMDAsfbz9m+irN83YjxJar+qHelgNWT2S 9Y28jZ75DybSf4H2Og4iwAaj37I= -----END CERTIFICATE-----

    Retry and Signature counters are displayed as zero - this looks rather bad. I suspect it has something to do with the GPG-2.0 vs GPG-2.1 incompatibility - but what can I do with keys on a hardware token? Help is welcome! ;-)

    This is my ~/.gnupg/scd-event file:

    #!/bin/sh
    state=$8
    if [ "$state" = "NOCARD" ]; then
      pkill -9 scdaemon
    fi
    

    Update Trying to OpenPGP-sign outgoing email showed that this GPG cannot work with the keys currently on my token - see the attached screenshot in the next comment. Help...?

  26. 24 Posted by mouse008 on Jul 13, 2017 @ 03:50 AM

    mouse008's Avatar

    After more experiments, the card now reacts differently to gpg --card-status:

    . . . . .
    Key attributes ...: rsa2048 rsa2048 rsa2048
    Max. PIN lengths .: 127 127 127
    PIN retry counter : 5 5 5
    Signature counter : 58
    . . . . .
    

    It seems to switch fairly smoothly from S/MIME to OpenPGP. I tested only signing outgoing email.

    It does not switch smoothly from OpenPGP to S/MIME: you have to re-insert the token, often repeating this process two or more times.

    It is still better than having to not only re-insert the token, but kill some running software.

    The likely cause of this lack of smooth switch back to S/MIME is that (as Doug Engert thinks) the PIV applet on the token is not selected again. So when the time comes for a PIV operation - the token still has OpenPGP applet selected from the previous run...

  27. 25 Posted by mouse008 on Jul 14, 2017 @ 06:09 AM

    mouse008's Avatar

    Update 2

    With Yubikey tokens I found a workaround for the appropriate applet selection:

    • Switching from S/MIME emails to OpenPGP emails - usually one needs to do nothing, just use OpenPGP mode. But if automatic switch hasn't happened - typing in a Terminal window gpg --card-status should do the job.
    • Switching from OpenPGP back to S/MIME often (always so far?) does not happen automatically. To manually switch the Yubikey token from OpenPGP applet to PIV applet, just type in the terminal window yubico-piv-tool -a status. That's enough to bring the token back to PIV mode.

    I've tested the above with Yubikey NEO and Apple Mail. It allowed me to send an OpenPGP-signed email, then send an S/MIME-signed email. Without killing or restarting anything, without having to remove and re-insert the token. Very smooth.

    Two problems with this workaround:
    1. It works only for Yubikey tokens - I don't know how (or using what tool) to force a multi-applet token to select its PIV applet. On the other hand, I don't know of any multi-applet token other than Yubikey.
    2. It's much-much better than whatever I had to use before - but it still requires "manual" intervention. Ideally, it all should happen transparently, so the user isn't even aware of the active applet selection on the token.

    Still, what we have now is a very significant progress, and a reasonably good solution. Having to type a CLI command (aka manually selecting active applet on a multi-applet token) isn't too bad. As I said, it's incomparably better than what we had before - searching through the running processes, killing some of them, re-inserting the token, and doing it all in certain sequence (because doing these right steps in a wrong order won't work)...

    Update 3 To make sure it's clear: we're talking about 1934n build. Hopefully the following builds would be even better! ;-)

  28. Support Staff 26 Posted by Steve on Jul 17, 2017 @ 10:12 AM

    Steve's Avatar

    Hi mouse008,

    thanks for taking the time to thoroughly test this. Good to hear that this is now somewhat usable. While this is not ideal, it probably is good enough for now. So you may probably not see further patches in this area for a while.

    All the best,
    steve

  29. 27 Posted by mouse008 on Jul 17, 2017 @ 08:06 PM

    mouse008's Avatar

    Thank you! Yes, it's certainly good enough for now - though I'd love to encourage you to keep improving it! ;-)

    I'm using it now.

    P.S. I'm not holding my breath - but might it be possible to convince the upstream folks to incorporate your patch?

  30. Support Staff 28 Posted by Steve on Jul 17, 2017 @ 08:29 PM

    Steve's Avatar

    No, we filed a ticket, which was closed as wontfix: https://dev.gnupg.org/T3267

  31. 29 Posted by mouse008 on Jul 17, 2017 @ 08:48 PM

    mouse008's Avatar

    :-)

    I requested them to re-consider. Let's see. But as long as GPGTools can do the right thing, I guess it's not too big a deal. ;-)

  32. Steve closed this discussion on Jul 18, 2017 @ 11:11 AM.

  33. mouse008 re-opened this discussion on Jul 18, 2017 @ 09:30 PM

  34. 30 Posted by mouse008 on Jul 18, 2017 @ 09:30 PM

    mouse008's Avatar

    @steve, would you be able to provide the patch for scdaemon (I assume that's the only component that had to be changed)? One of my colleagues may want to use it with the gpg setup on Linux (they use Yubikeys for PIV-based SSH and VPN, but sign email using OpenPGP).

    Thanks!

    P.S> And of course, please feel free to close this discussion again, as your solution works.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac