MS Surface Go Sim Card appears to cause scdaemon crash

[Derek C Hoffmann]

Thanks, good to know that it's a known issue and being worked on, looking
forward to the next update!

Just FYI though, the indicated workaround doesn't seem to work unless the
intended card reader for gpg is listed first:

I have another system I just started working on which needs two different
smart cards (Gemalto eToken Pro for work, and yubikey for personal use,
which is what I use with gpg).  The gemalto card readers are listed first,
and even putting various versions of 'reader-port Yubico YubiKey
OTP+FIDO+CCID 0', 'reader-port Yubico YubiKey', 'reader-port Yubico Yubi'
in scdaemon.conf result in the same behaviour.

2021-08-21 09:53:11 scdaemon[16820.1] DBG: chdir to '/tmp' failed: No such
file or directory
2021-08-21 09:53:11 scdaemon[16820.1] listening on socket
'C:\\Users\\derek\\AppData\\Roaming\\gnupg\\S.scdaemon'
2021-08-21 09:53:11 scdaemon[16820.2] handler for fd -1 started
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK GNU
Privacy Guard's Smartcard server ready
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- GETINFO
socket_name
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> D
C:\Users\derek\AppData\Roaming\gnupg\S.scdaemon
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- OPTION
event-signal=2bc
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- GETINFO
version
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> D 2.3.1
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> OK
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 <- SERIALNO
2021-08-21 09:53:11 scdaemon[16820.2] detected reader 'AKS ifdh 0'
2021-08-21 09:53:11 scdaemon[16820.2] detected reader 'AKS ifdh 1'
2021-08-21 09:53:11 scdaemon[16820.2] detected reader 'Yubico YubiKey
OTP+FIDO+CCID 0'
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: AKS ifdh 0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: new device=AKS
ifdh 0
2021-08-21 09:53:11 scdaemon[16820.2] reader slot 0: not connected
2021-08-21 09:53:11 scdaemon[16820.2] DBG: enter: apdu_connect: slot=0
2021-08-21 09:53:11 scdaemon[16820.2] pcsc_connect failed: removed card
(0x80100069)
2021-08-21 09:53:11 scdaemon[16820.2] reader slot 0: not connected
2021-08-21 09:53:11 scdaemon[16820.2] DBG: leave: apdu_connect => sw=0x10008
2021-08-21 09:53:11 scdaemon[16820.2] DBG: chan_0x000002e0 -> S
PINCACHE_PUT 0//
2021-08-21 09:53:11 scdaemon[16820.2] DBG: enter: apdu_close_reader: slot=0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: enter: apdu_disconnect: slot=0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: leave: apdu_disconnect => sw=0x0
2021-08-21 09:53:11 scdaemon[16820.2] DBG: leave: apdu_close_reader => 0x0
(close_reader)
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: (null)
2021-08-21 09:53:11 scdaemon[16820.2] DBG: apdu_open_reader: new
device=(null)


For now I've fallen back to 2.2

--
Derek C Hoffmann


On Fri, Aug 20, 2021 at 2:48 AM NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> Derek C Hoffmann via Gnupg-users <gnupg-users at gnupg.org> wrote:
> > It looks like scdaemon is crashing when attempting to access a sim card
> > slot/sim card itself on my Surface Go.
>
> It is my fault.  I added multiple card readers support (for PC/SC) to
> GnuPG 2.3, and it causes an issue in your use case.  By default,
> scdaemon tries to access all available card readers.  It has a bug
> accessing the second reader when the first reader doesn't have a card.
>
> Related bug is tracked at:
>
>         https://dev.gnupg.org/T5416
>
> And it will be fixed in GnuPG 2.3.2.
>
> > Any other suggestions as to prevent this crash without disabling the
> > Mobile Broadband card?
>
> If you have a line in scdaemon.conf, like:
>
>         reader-port Microsoft IFD 0
>
> scdaemon will only access to the card reader.  Please try this, until
> fixed version will be released.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210823/89a6574e/attachment-0001.html>