Home → Stable →

scdaemon - Neither reader_x_.status is updated nor scd-event is called

• Edit

antispam007

01 Aug, 2019 08:27 PM

When I unplug the token, scdaemon recognised correct: NOCARD and echoed it into the reader.status file and also called scd-event script. When I then re-plugin the card, nothing happens. While MacOs recognized the card. It seems that scdaemon does not.
Only when I access the card ( which is possible with gpg --card-status ) , the status is updated and the scd-event is fired.
I am not sure if that is a MacGPG Problem or more a generic GnuPG trouble ? Is there any special I need to setup ?

(BTW: Im using ttl with 3456000 ( around a year) , but this should be cleared, when the token is pulled.)

1. Support Staff 1 Posted by Luke Le on 01 Aug, 2019 10:37 PM

   

   Hi,

   there's nothing special we do in MacGPG in regards to smart cards. Unfortunately scdaemon is known not to be too reliable. It's best to directly ask the people of gnupg.org on one of their mailing lists.

   • Edit

2. 2 Posted by antispam007 on 02 Aug, 2019 07:42 AM

   

   Ok, grummel
   Flame On While I understand your point, I need to say more and more Opensource Companies act : "oh, great, not our trouble - we know our users also have problems, but let them send to the source (we use) . Should they figure out how to solve it."

   I would love to see, that companies that sell their product (and use other opensource) take responsibility about their product. They should collect these issues and should take care in meetings ( or whatever) with the source code provider to fix or create workarounds for the troublemaker of their products ! A single user is not so empowered than a company with much more users !

   Do you think I complain about GnuPG ? No, I bought GPGTools that is now not working reliable !
   Flame Off And of course you could close this discussion if you fingerpoint to gnupg.org

   • Edit

3. Support Staff 3 Posted by Luke Le on 02 Aug, 2019 09:28 AM

   

   We do feel and understand your frustration.
   The answer I sent you was tailored specifically to your detailed question and to the level of expertise that I assumed due to the way the question was phrased.

   While we do have quite a few smart card bugs on record in our bug tracker this is not one of which we have heard of before, so there can be multiple reasons for it. It could either be the hardware itself, it could be the exclusive access to the smart card that GnuPG requires which is known to cause different kinds of troubles on macOS or it could be something else.

   In the case if this request were filed by a user not as familiar with the details of GnuPG (you mention reader.status file etc.) we would have asked for more debugging info in order to try to isolate where the problem comes from and in the end probably created a ticket in our bug tracker for it and then in GnuPG's bug tracker. In your case however, it seemed to be more helpful to redirect you to the source, since MacGPG only differs from vanilla GnuPG mainly in the support of macOS Keychain for storing key passphrases.

   Now to also address your critique in general.

   In the 10 years we have been providing GPG Suite (for over 8 them for free), our main focus always was to provide graphical user interfaces which make it easier to use PGP encryption. For additional comfortability for our users we also package GnuPG.
   In all these years we also tried to fix bugs or issues in GnuPG ourselves, and if we couldn't, created tickets for them. Unfortunately however, a lot of them were out of scope for this project. But as I already mentioned, if it weren't due to the expertise I (maybe wrongly) assumed, I wouldn't have redirected you directly to the provider of GnuPG but instead would have recorded all you could give us and created a ticket on their site.

   One last thing, we would be more than happy to refund your purchase of GPG Mail Support Plan should you want that.

   • Edit

4. Support Staff 4 Posted by Luke Le on 02 Aug, 2019 09:33 AM

   

   In regards to the exclusive access to the smart card I mentioned. One thing you could try is to add the following line to your ~/.gnupg/scdaemon.conf file:

    shared-access
   

   This feature is not available in GnuPG vanilla, since the creator the developers of GnuPG are not in favor of it and it has only seen very limited testing. But there have been a couple of macOS users who reported that it helped make smart cards more reliable.

   Kill scdaemon afterwards in order for the setting to be accepted.

   • Edit

5. 5 Posted by antispam007 on 02 Aug, 2019 10:12 AM

   

   Thanks for taking the time to provide such a comprehensive answer.
   And shame on me, that I am an expert and need to go direct to gnupg.org :D

   Let me add some stuff: a) I think you as a group have more power to call out a bug at gnupg.org than a single user. So IMHO you could better collect the information from multiple users and bring that up to gnupg.org as a weighted trouble maker.
   b) regarding your paragraph starting "In the 10 years ..." : yes, that is one challange I see for all OpenSource using companies: they build their product on a foreign base and bundle it. Wouldn't it be easier to say : Install first GnuPG and then our few graphical tools / or patches ?
   c) No, I don't want a refund - I want a working tool :D - not so easy to get rid of a nasty customer :D

   But back to the topic: I will try the 'shared-access' - it might be that the macOS 'securityd' is also grabbing the card through scdaemon. BUT it seems to be a bit of a different problem: when I plug out the token, it is immediately recognised. Just when you plug in the token, nothing happens. Even with a shared access I would imagine, that after a while the event is fired - it is not. Let's see if it will change something - I will provide feedback :)

   Oh, one addition:
   

   2019-08-02 12:07:29 scdaemon[4717] DBG: pcsc_get_status_change: 
   2019-08-02 12:07:29 scdaemon[4717] DBG: pcsc_get_status_change: 
   2019-08-02 12:07:30 scdaemon[4717] DBG: pcsc_get_status_change: 
   2019-08-02 12:07:30 scdaemon[4717] DBG: pcsc_get_status_change:  changed unknown
   2019-08-02 12:07:30 scdaemon[4717] DBG: Removal of a card: 0
   

   So when the card is plugged out it seems a routine ( that is normaly blowing up the log file ) has stopped. I already plugged in the card again ....
   • Edit

6. 6 Posted by antispam007 on 02 Aug, 2019 10:54 AM

   

   Update

   user@blackpearl:~% /usr/local/libexec/scdaemon --multi-server
   scdaemon[6733]: /Users/user/.gnupg/scdaemon.conf:1: invalid option
   user@blackpearl:~% cat .gnupg/scdaemon.conf
   shared-access
   debug-level expert
   log-file /Users/user/Library/Logs/scdaemon.log
   

   • Edit

7. Support Staff 7 Posted by Luke Le on 02 Aug, 2019 10:58 AM

   

   shared-access only exists for MacGPG not for gnupg vanilla.

   As I have mentioned, we have brought up smart card issues with the developers at gnupg.org before, but unfortunately they weren't really able to help.
   I have contacted the developer which has written most of the code of scdaemon and will update you once I hear back.

   Let me reiterate, the goal is not to get rid of you.

   • Edit

8. Support Staff 8 Posted by Luke Le on 02 Aug, 2019 11:06 AM

   

   What I have failed to ask in the beginning is what you are trying to do that doesn't work.
   I realize that you describe the symptoms what isn't working but not what you are trying to accomplish in the first place.

   As far as I remember gpg --card-status is called automatically if a gnupg operation is executed that interacts with a key on the smart card, for example if you try to sign a message. So in that case, the signing operation should recognize the card, but you would still not be seeing scdaemon recognizing the card before such an operation is executed.

   • Edit

9. 9 Posted by antispam007 on 02 Aug, 2019 11:17 AM

   

   Hmm, I am not using gnupg vanilla - I am using only MacGPG with the patch your team has provided to upgrade to the latest lib's. The former installed GnuPG was uninstalled.

   To your question: I am posting a code snippet from scd-event, which should be called in case of event recognized by scdaemon.

   ....
   if [ x$status = xUSABLE ]; then
   UPW=`security find-generic-password -a mefj-network -c GNPG -C UPIN -w`
   
   cat <<EOF >$TMPF
   OPTION pinentry-mode=loopback
   /subst
   /let ppp $UPW
   /definq PASSPHRASE ppp
   SCD CHECKPIN $CARDID
   /bye
   EOF
       /usr/local/bin/gpg-connect-agent updatestartuptty /bye 2>&1
       /usr/local/bin/gpg-connect-agent -r $TMPF 2>&1
       rm $TMPF
   fi
   

   ---

   which works fine until the card is pulled. It also works fine, when I plug in teh card and call gpg --card-status to trigger an access to the card ( and that seems to wakeup scdaemon)
   .. and I am using it to pre-load the cache for ssh to get rid of the boring pin question when you first time access the card. (This key is only used internal in my network )

   • Edit

10. Support Staff 10 Posted by Luke Le on 02 Aug, 2019 11:56 AM

    

    We don't symlink /usr/local/libexec/scdaemon, so if it exists it is most likely a leftover of a previous gnupg installation from either brew/macports or something similar.

    So the situation is quite dire and I now understand that this is related to your other question regarding pin entry. It seems that gpg-agent doesn't support caching the pin (from what I understand, this is something the card does directly) and thus gpg-preset-passphrase can't be used. Our pinentry-mac implementation unfortunately also doesn't support storing the pin in macOS Keychain and retrieving it from there. We will have to see if that would be something that could be added easily or if a change to the way gpg-agent interacts with pinentry-mac would be required.

    The quickest workaround, while admittedly ugly would be, to create another shell script which starts calling gpg --card-status every few seconds/minutes once your scd-event script detects that the card has been removed. If gpg --card-status returns successfully with information about the card, you could then re-run the script which pre-sets the PIN to use.

    Instead of polling for the device yourself you could try to leverage a macOS launch agent which uses iokit.matching

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd >
    <plist version="1.0">
    <dict>
        <key>Label</key>
        <string>org.gpgtools.smartcard-polling</string>
        <key>ProgramArguments</key>
        <array>
        <string>/usr/local/MacGPG2/bin/gpg</string>
            <string>--card-status</string>
        </array>
        <key>LaunchEvents</key>
        <dict>
                <key>com.apple.iokit.matching</key>
                <dict>
                        <key>com.apple.device-attach</key>
                        <dict>
                                <key>idProduct</key>
                                <integer>1031</integer>
                                <key>idVendor</key>
                                <integer>4176</integer>
                                <key>IOProviderClass</key>
                                <string>IOUSBDevice</string>
                                <key>IOMatchLaunchStream</key>
                                <true/>
                        </dict>
                </dict>
        </dict>
    </dict>
    </plist>
    

    You can find the productID and vendorID using system_profiler -detailLevel mini SPUSBDataType

    After saving the script in ~/Library/LaunchAgents/org.gpgtools.smartcard-polling.plist you can then load it using:

    launchctl load /Library/LaunchAgents/org.gpgtools.smartcard-polling.plist
    

    Now whenever you plugin the smart card gpg --card-status is called. Instead of calling gpg --card-status you could of course also call your script which presets the passphrase and call gpg --card-status in that script.

    WARNING: This script has not been tested at all. Make sure to backup any key data before trying it.

    Hope that helps.

    • Edit

11. 11 Posted by antispam007 on 02 Aug, 2019 12:08 PM

    

    Cool !!!
    Let me try out some things and I will come back

    • Edit

12. Support Staff 12 Posted by Luke Le on 02 Aug, 2019 12:57 PM

    

    One additional thing in regards to the launch agent. It seems to be calling the script every 10 seconds once the usb device is plugged in. This could be solved by having the called script run xpc_set_event_stream_handler (https://stackoverflow.com/questions/7240117/execute-an-application-...) which however is not possible from a shell script.

    While it is not possible to prevent the shell script from being launched without using a compiled program, you could use the information from reader.status to determine if the drive has been unplugged in the meantime and only in that case call gpg --card-status again

    • Edit

13. 13 Posted by antispam007 on 02 Aug, 2019 01:17 PM

    

    Ok some status updates:

    a) ok I have not recognised that there was a GnuPG still installed from last fall and so the wrong scdaemon was used. Also MacGPG has not over-written this former configuration ( but I don't complain)

    b) Now after cleaning, gpgconf was no longer found: it is only in /usr/local/MACGPG2/bin and no longer in /usr/local/bin (Hmm, while gpg is in /usr/local/bin -- strange ) Is your installer not coping all bin/* into local/bin/ ?

    c) As I cleand up some stuff , I also cleand up an assuanlib used by scd-pkcs11lib - inside ssh pkcs11 now complaints about the missing lib. Maybe th epkcs11 is another source that was accessing the scdaemon.

    d) it is my understanding reader.status is deprecated as it will be replaced by the scd-event file ( at least man scdaemon.1is telling that . So I don't want to setup something based on that file.

    e) Hmm, Also the man pages are no longer found for MacGPG stuff. The files are there, but the path is not set.

    ---

    ... to be continued

    • Edit

14. Support Staff 14 Posted by Luke Le on 03 Aug, 2019 09:18 PM

    

    a) that is by design. There are legitimate reasons to have a different GnuPG installation and since our tools prefer our own that doesn't have to be a problem. It is however, if the two installation are often to be used simultaneously. We did discuss to warn during installation.

    b) We only symlink the most important components into /usr/local/bin, currently only gpg or gpg2 in order not to dirty an existing /usr/local. MacPGP2 is self-contained in /usr/local/MacGPG2 so it can simply and cleanly be removed

    c) Unfortunately we have not dealt with pkcs11 and gnupg before, so can't say much about that.

    d) You are right.

    e) hmm... that is interesting. We install a /etc/manpaths.d/MacGPG2 file which is responsible for telling man where to find gnupg's man files: /usr/local/MacGPG2/share/man`. If that path still exists, it should work, unless the previous installation is still causing trouble as not everything was removed.

    • Edit

15. 15 Posted by antispam007 on 05 Aug, 2019 01:55 PM

    

    I am still testing some setups:
    a) your scdaemon is not better than the GnuPG one :-) - same source , ey
    b) manhas a strange setup since Xcode is installed. It looks like it is neither reading man.confnor /etc/manpaths nor /etc/manpaths.d/* nad I have no clue, how the Xcode pathes are fed in ( as they are visible) . So at teh moment a man gpgdoesn't work

    • Edit

16. Luke Le closed this discussion on 16 Sep, 2019 12:44 PM.