tag:gpgtools.tenderapp.com,2011-11-04:/discussions/problems/101253-scdaemon-neither-reader_x_status-is-updated-nor-scd-event-is-calledGPGTools: Discussion 2019-09-16T12:44:46Ztag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-01T22:37:53Z2019-08-01T22:37:53Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>Hi,</p>
<p>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.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T07:42:25Z2019-08-02T07:44:26Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>Ok, <em>grummel</em><br>
<em>Flame On</em> 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."</p>
<p>I would love to see, that companies that <strong>sell</strong> their product (and use other opensource) take responsibility about <strong>their</strong> product. They should collect these issues and should take care in meetings ( or whatever) with the source code provider to <strong>fix</strong> or create workarounds for the troublemaker of their products ! A single user is not so empowered than a company with much more users !</p>
<p>Do you think I complain about GnuPG ? No, I bought GPGTools that is now not working reliable !<br>
<em>Flame Off</em> And of course you could close this discussion if you fingerpoint to gnupg.org</p></div>antispam007tag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T09:28:52Z2019-08-02T09:34:19Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>We do feel and understand your frustration.<br>
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.</p>
<p>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 <strong>exclusive access</strong> to the smart card that GnuPG requires which is known to cause different kinds of troubles on macOS or it could be something else.</p>
<p>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.</p>
<p>Now to also address your critique in general.</p>
<p>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.<br>
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.</p>
<p>One last thing, we would be more than happy to refund your purchase of GPG Mail Support Plan should you want that.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T09:33:40Z2019-08-02T09:34:06Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>In regards to the <strong>exclusive access</strong> to the smart card I mentioned. One thing you could try is to add the following line to your <code>~/.gnupg/scdaemon.conf</code> file:</p>
<pre>
<code> shared-access</code>
</pre>
<p>This <em>feature</em> 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.</p>
<p>Kill scdaemon afterwards in order for the setting to be accepted.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T10:12:04Z2019-08-02T10:19:18Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>Thanks for taking the time to provide such a comprehensive answer.<br>
And shame on me, that I am an expert and need to go direct to gnupg.org :D</p>
<p>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.<br>
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 ?<br>
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</p>
<p>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 :)</p>
<p>Oh, one addition:<br></p>
<pre>
<code>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</code>
</pre>
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 ....</div>antispam007tag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T10:54:22Z2019-08-02T10:54:22Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p><strong>Update</strong></p>
<pre>
<code>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</code>
</pre></div>antispam007tag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T10:58:05Z2019-08-02T10:58:05Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>shared-access only exists for MacGPG not for <strong>gnupg vanilla</strong>.</p>
<p>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.<br>
I have contacted the developer which has written most of the code of scdaemon and will update you once I hear back.</p>
<p>Let me reiterate, the goal is not to get rid of you.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T11:06:00Z2019-08-02T11:06:00Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>What I have failed to ask in the beginning is what you are trying to do that doesn't work.<br>
I realize that you describe the symptoms what isn't working but not what you are trying to accomplish in the first place.</p>
<p>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 <strong>before</strong> such an operation is executed.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T11:17:47Z2019-08-02T11:17:47Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>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.</p>
<p>To your question: I am posting a code snippet from scd-event, which should be called in case of event recognized by scdaemon.</p>
<pre>
<code>....
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</code>
</pre>
<hr>
<p>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)<br>
.. 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 )</p></div>antispam007tag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T11:56:17Z2019-08-02T11:58:40Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>We don't symlink <code>/usr/local/libexec/scdaemon</code>, so if it exists it is most likely a leftover of a previous gnupg installation from either brew/macports or something similar.</p>
<p>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 <code>gpg-preset-passphrase</code> 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.</p>
<p>The quickest workaround, while admittedly ugly would be, to create another shell script which starts calling <code>gpg --card-status</code> every few seconds/minutes once your scd-event script detects that the card has been removed. If <code>gpg --card-status</code> returns successfully with information about the card, you could then re-run the script which pre-sets the PIN to use.</p>
<p>Instead of polling for the device yourself you could try to leverage a macOS launch agent which uses iokit.matching</p>
<pre>
<code><?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></code>
</pre>
<p>You can find the <strong>productID</strong> and <strong>vendorID</strong> using <code>system_profiler -detailLevel mini SPUSBDataType</code></p>
<p>After saving the script in <code>~/Library/LaunchAgents/org.gpgtools.smartcard-polling.plist</code> you can then load it using:</p>
<pre>
<code>launchctl load /Library/LaunchAgents/org.gpgtools.smartcard-polling.plist</code>
</pre>
<p>Now whenever you plugin the smart card <code>gpg --card-status</code> is called. Instead of calling <code>gpg --card-status</code> you could of course also call your script which presets the passphrase and call <code>gpg --card-status</code> in that script.</p>
<p>WARNING: This script has not been tested at all. Make sure to backup any key data before trying it.</p>
<p>Hope that helps.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T12:08:33Z2019-08-02T12:08:33Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>Cool !!!<br>
Let me try out some things and I will come back</p></div>antispam007tag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T12:57:22Z2019-08-02T12:58:07Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>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 <code>xpc_set_event_stream_handler</code> (<a href="https://stackoverflow.com/questions/7240117/execute-an-application-on-mac-os-x-when-a-particular-type-of-usb-device-is-conne">https://stackoverflow.com/questions/7240117/execute-an-application-...</a>) which however is not possible from a shell script.</p>
<p>While it is not possible to prevent the shell script from being launched without using a compiled program, you could use the information from <code>reader.status</code> to determine if the drive has been unplugged in the meantime and only in that case call <code>gpg --card-status</code> again</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-02T13:17:18Z2019-08-02T13:17:18Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>Ok some status updates:</p>
<p>a) ok I have not recognised that there was a GnuPG still installed from last fall and so the wrong <code>scdaemon</code> was used. Also MacGPG has not over-written this former configuration ( but I don't complain)</p>
<p>b) Now after cleaning, <code>gpgconf</code> was no longer found: it is only in <code>/usr/local/MACGPG2/bin</code> and no longer in <code>/usr/local/bin</code> (Hmm, while <code>gpg</code> is in <code>/usr/local/bin</code> -- strange ) Is your installer not coping all <code>bin/*</code> into <code>local/bin/</code> ?</p>
<p>c) As I cleand up some stuff , I also cleand up an <em>assuanlib</em> used by <code>scd-pkcs11lib</code> - inside ssh pkcs11 now complaints about the missing lib. Maybe th epkcs11 is another source that was accessing the scdaemon.</p>
<p>d) it is my understanding <code>reader.status</code> is deprecated as it will be replaced by the scd-event file ( at least <code>man scdaemon.1</code>is telling that . So I don't want to setup something based on that file.</p>
<p>e) Hmm, Also the man pages are no longer found for MacGPG stuff. The files are there, but the path is not set.</p>
<hr>
<p>... to be continued</p></div>antispam007tag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-03T21:18:35Z2019-08-03T21:19:04Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>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.</p>
<p>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</p>
<p>c) Unfortunately we have not dealt with pkcs11 and gnupg before, so can't say much about that.</p>
<p>d) You are right.</p>
<p>e) hmm... that is interesting. We install a <code>/etc/manpaths.d/MacGPG2</code> 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.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/474927822019-08-05T13:55:31Z2019-08-05T13:55:31Zscdaemon - Neither reader_x_.status is updated nor scd-event is called<div><p>I am still testing some setups:<br>
a) your scdaemon is not better than the GnuPG one :-) - same source , ey<br>
b) <code>man</code>has a strange setup since Xcode is installed. It looks like it is neither reading <code>man.conf</code>nor <code>/etc/manpaths</code> nor <code>/etc/manpaths.d/*</code> nad I have no clue, how the Xcode pathes are fed in ( as they are visible) . So at teh moment a <code>man gpg</code>doesn't work</p></div>antispam007