It is selecting FD which is created by gnupg_create_pipe.

Version information, please.

I cannot replicate this on GNU/Linux with PC/SC (by disable-ccid).
Anyway, I am looking into this issue:

npth_pselect failed: Input/output error - waiting 1s

I doubt that this is Windows only. On Linux we use our own driver but on
Windows we have to resort to PC/SC. My educated guess is that we are in some
blocking system call which is not npth_unprotected.

From what I've seen there is no variation in getsockname, it just returns
whatever path is passed to bind. I don't understand the need for getsockname
tbh, because we are the ones that bind the socket in the first place.

(The only variation seems to be that the function is broken on Hurd...).

Justus, thanks for this work, it's great!. If we can solve the problem by doing
more clever socket(7) manipulation, that would be a big win.

How do you propose dealing with the getsockname() variations? or should we just
forbid the use of getsockname() entirely in the gnupg codebase?

dkg, I understand that GnuPG does not work with such a homedir, however, it is
not the act of creating the socket that is problematic. In fact, both
bind(2)ing and connect(2)ing is ok if one uses relative paths, as demonstrated
by the test program I have attached here.

Here is the program binding and connecting to a socket with an absolute path
length of ~10 * sizeof sockaddr_un.sun_path:

System: OpenBSD:6.0:GENERIC.MP#1992
sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'

getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106

Running test with strlen (cwd): 22, name: 'socket'

getsockname returned 'socket', addrlen: 106

Running test with strlen (cwd): 126, name: 'socket'

getsockname returned 'socket', addrlen: 106

Running test with strlen (cwd): 1062, name: 'socket'

  getsockname returned 'socket', addrlen: 106

This works on all Unices that I have access to. I've asked on gnupg-devel@ for
people to run it elsewhere.

I understand that '--create-socketdir' solves problems besides this one. But I
disagree with the statement that our handling of socket paths is unproblematic
because --create-socketdir solves this problem.

Can we test whether /run is mounted on a tmpfs ?
should we assume that /run is always on a tmpfs but /var/run is a classical Unix
w/o a tmpfs? Or is it better to have a configure option.

I can imagine to agree to auto-create the directory on a tmpfs.

Yes, notmuch decided that they needed to workaround the situation anyway,
because they're in an environment that doesn't create the standard per-user
rundir. That doesn't seem like a great argument that gpg should also fail in
environments where the standard per-user rundir is available. I can demonstrate
a number of environments where gpg or its daemons will fail, but i don't think
any of them justify forcing gpg or its daemons to *also* fail when those
environments aren't present.

In answer to your nitpick, here is evidence that gpg's daemons cannot create
their sockets when the GNUPGHOME is too long:

1 dkg@alice:~$ mkdir -m 0700
/home/dkg/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long
0 dkg@alice:~$
GNUPGHOME=/home/dkg/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long
gpgconf --launch dirmngr
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent --dirmngr NOP': General error
1 dkg@alice:~$

I'm having trouble decrypting some mails. I use an encryption sub-key with a
unusual length of 3104 bits. I described my problem in the gnupg-users mailing
list and there the following problem was identified:
<quote>
I think that it is deterministic; The cause is that the RSA keysize is
not the one in the set of: 1024, 1536, 2048, 3072, 4096. When data to
be decrypted is padded, scdaemon can't decrypt, I suppose.

I am not sure the exact reason why scdaemon only supports limited set of
keysize for encryption. But we have this handling of padding in the
current code:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=scd/app-openpgp.c;h=71c9e1b83003af07b0984688ba1ec5e9013b877c;hb=refs/heads/master#l4334

       /* We might encounter a couple of leading zeroes in the
          cryptogram.  Due to internal use of MPIs these leading zeroes
          are stripped.  However the OpenPGP card expects exactly 128
          bytes for the cryptogram (for a 1k key).  Thus we need to fix
          it up.  We do this for up to 16 leading zero bytes; a
          cryptogram with more than this is with a very high
          probability anyway broken.  If a signed conversion was used
          we may also encounter one leading zero followed by the correct
          length.  We fix that as well.  */
       if (indatalen >= (128-16) && indatalen < 128)      /* 1024 bit key.  */
         fixuplen = 128 - indatalen;
       else if (indatalen >= (192-16) && indatalen < 192) /* 1536 bit key.  */
         fixuplen = 192 - indatalen;
       else if (indatalen >= (256-16) && indatalen < 256) /* 2048 bit key.  */
         fixuplen = 256 - indatalen;
       else if (indatalen >= (384-16) && indatalen < 384) /* 3072 bit key.  */
         fixuplen = 384 - indatalen;
       else if (indatalen >= (512-16) && indatalen < 512) /* 4096 bit key.  */
         fixuplen = 512 - indatalen;
       else if (!*(const char *)indata && (indatalen == 129
                                           || indatalen == 193
                                           || indatalen == 257
                                           || indatalen == 385
                                           || indatalen == 513))
         fixuplen = -1;
       else
         fixuplen = 0;

Perhaps, it was due to support all existing OpenPGP card
implementations, I mean, somehow historical, and it was easier to list
up specific keysizes.

This should be fixed.
</quote>

I also attached to log-files of the scdaemon. One for a successful and one for a
failed decryption attempt.

Please let me know if you need any additional information.

I tested with the GnuPG version 2.0.30 (GPG4WIn) as well as the current 2.1.16
Windows binaries. SCdaemon was running but was unable to get exclusive card access.
Why?
The Cisco Network Manager as well as Cisco Anyconnect VPN did both gain shared
card access (they were not told to do so!). I needed both programs to get access
to the university network.

Uninstalling both Programs and restarting did resolve the issue. To find the
two offenders I used Process Explorer (Processes for all users) and used the
Find Handle or DLL functon with the search term "SCARD". All crosschecked all
Processes (except for scdaemon which sould access the card) and Services
(svchost) to be only scdaemon aswell as the services to be Windows internal.
To determine the inital issue I used
https://sourceforge.net/projects/pcsctracker/ which told me the status of my
Yubikey (as Present,InUse -> Shared Access).

As a suggestion I like to see the experimental option to change the accessmode
from exclusive to shared on the commandline (If for example the other
application cannot be uninstalled).

Which version of GnuPG are you using? Do you have scdaemon?

Fixed in 2.1.16. Will be in 2.0.31 as the fix is in the git repo already.

Yeah, lets do that. Commit 8489b12 to go into 2.1.17. Thanks.

What about putting in the suggested patch as an intermediate step towards a full
solution?

Anything I can do to help?

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

Updated by the fix:

f9e49c8 scd: Fix an action after card removal.

Fixed in master:

    8fe8105 scd: Release the card reader after card removal.

In my environment, it works both for PC/SC and in-stock CCID driver.

Not yet for 2.0 and 1.4.

Ok, I can record such files. Will there be any confidential information contained in
these logs?

You can have a configuration file like:

.gnupg/gpg-agent.conf

enable-ssh-support
debug-level guru
debug-all

log-file /run/user/1000/gpg-agent.log

and

.gnupg/scdaemon.conf

debug-level guru
debug-all
debug-ccid-driver

log-file /run/user/1000/scd.log

so that the interactions can be recorded with debug information.

My problems are resolved. I have not encountered a problem since your last
fixes. Although I sometimes have to reenter pin so I think the errors still
occur occassionally but gnupg recovers.

Thanks.

It is handled in scdaemon (not in g10/keyedit.c).

When the keysize is different, it changes key attribute automatically.
For 2.1, it was fixed by f10b427d0e2be333776fee2df8150145da36e587 on 2015-09-07
which is in 2.1.8.

is there any way to get better debug output so this can be tracked down?

Thank you for the version information which worked.

Speaking of the code of scdaemon, there is no difference for unblocking (by
resetcode and by admin) between 2.1.11/12 and 2.0.30.

Please note that there are two subcommands.

    admin -> passwd -> 2: unblocking by Admin
    unblock: unblocking by resetcode

Latter requires setting resetcode beforehand.

This was possible on my mac with:

gpg (GnuPG) 2.0.30
libgcrypt 1.7.0
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://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: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Here is another session after another three times failure.

This time, unblock by admin with Admin PIN.

$ gpg --card-edit

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> admin
Admin commands are allowed

gpg/card> passwd
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 2

[ Admin PIN ]
[ New PIN ]
[ Repeat New PIN ]

PIN unblocked and new PIN set.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? q

gpg/card>

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

$

My case with Gnuk Token.
First, I intentionally input wrong PIN for singing three times.
Then, I invoke gpg --card-edit (with 2.1.2 on Debian experimental) to unblock
the token by resetcode.

$ gpg --card-edit

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 2 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> unblock
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected

[ Resetcode ]
[ New PIN ]
[ Repeat New PIN ]

PIN changed.

gpg/card>

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> quit

Please note that 'unblock' subcommand is to unblock with resetcode.

For some reason, I can't reproduce your problem in 2.1.x. Isn't it a problem of
your smartcard implementation?
Please describe the specific version number of GnuPG which is possible to
unblock this particular implementation of smartcard.

Sorry for the delay. Here is the complete log:

• SNIP ---

languitar@bird ~> gpg --card-edit

Reader ...........: REINER SCT cyberJack RFID standard (XXXXX) 00 00
Application ID ...: XXXXXX
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: XXXXXX
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 3
Signature counter : 3
Signature key ....: Some Stuff

created ....: Some Stuff

Encryption key....: Some Stuff

created ....: Some Stuff

Authentication key: Some Stuff

created ....: Some Stuff

General key info..: pub rsa2048/0xXXXXXXXXXXXXX somedate somename
<somemail@example.org>
sec> rsa2048/0xXXXXXXXXXXXXXXXX created: somedate expires: never

card-no: 0006 XXXXXX

ssb> rsa2048/0xXXXXXXXXXXXXXXXX created: somedate expires: never

card-no: 0006 XXXXXX

ssb> rsa2048/0xXXXXXXXXXXXXXXXX created: somedate expires: never

                                  card-no: 0006 XXXXXX

gpg/card> admin
Admin commands are allowed

gpg/card> unblock

[GUI asks for admin PIN and new PIN, which I entered]

gpg: OpenPGP card no. XXXXXX detected
Error changing the PIN: Conditions of use not satisfied

gpg/card> passwd
gpg: OpenPGP card no. XXXXXX detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 2
Error unblocking the PIN: Conditions of use not satisfied

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? q

gpg/card> q
languitar@bird ~> gpg --version
gpg (GnuPG) 2.1.12
libgcrypt 1.7.0
Copyright (C) 2016 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: ~/.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
languitar@bird ~> uname -a
Linux bird 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux

• SNIP ---

Same thing works without problems using an older version of GPG on my mac.

Anything else I can do to help?

Another problem has been fixed in 6677d8b.
I intentionally set up more hubs from computer to the device to cause an error.
When an error occurred, scdaemon continued to report "Card error", even after I
inserted the device directly to the computer.
Now, it returns "No such device" for severe errors, and scdaemon can recover
from such errors.

The particular problem of T2306 (aheinecke on Apr 25 2016, 06:53 PM / Roundup) has been fixed in cb4fee8.

I think that it was not always reproducible because it depends on timing (only
when it detected an error at bulk_in, the problem happened). I'm not sure if
the difference of old/new libusb mattered for this problem.

I can make "a" problem (not sure if it is "the" problem) reproducible with the
following command (as root):

AUTHFILE="/sys/bus/usb/devices/4-1.2/authorized" ; echo 0 > "$AUTHFILE" ; sleep
1 ; echo 1 > "$AUTHFILE"

This was based on:
http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line/61165#61165

where 4-1.2 is the id of my reader. The error message in scdaemon log is
slightly different but the behavior is the same. It's in an error state until I
kill it.

I'm reading the implementation of new libusb.
If I guess correctly, the picture of the problem would be:

• New libusb somehow caches (or uses cache of kernel's) USB device list structures.
• When the device is plugged off/on (or hardware failures), the cache should be

updated.

• GnuPG's ccid-driver possibly keeps using staled data of USB device list.

I'll check the implementation detail, and try fixing this.
I think that current ccid-driver with new libusb has an issue for memory leaks
for device list, so, it should be reviewed and modified anyway.

It would be good if we could have a reproducible scenario.

Please describe the interaction. IIUC, isn't it pinentry problem?
Did you input your PIN? For "2 - unblock PIN" operation, you need to
authenticate as admin, did you input your PIN for admin? Wasn't it a failure of
PIN input for admin or user, whatever?

This is a fidesmo privacy card with the yubikey applet installed. Therefore the second reader.

Possible causes would be SUSPEND/RESUME of usb device.
Let me see about libusb implementation differences.

Probably a trigger for this, but if a hardware error is causing this it appears
to be recoverable by software otherwise why would restarting gpg-agent /
scdaemon help?

Before the changes to libusb from time to time i had to reenter my pin for
authentication although it should have been cached and in the syslog it showed
the usb disconnect / reconnect. But scdeamon recovered from that.

btw. I can't reproduce this problem if I just disconnect / reconnect the reader
that works as expected.

Hardware problem? The "usb_claim_interface failed" error seems to be ENXIO (No
such device or address).

Thank you for your report and the log, but it doesn't have useful information so
that I can debug.

The information of card reader is required, if the problem happens for specific
card reader only. Please include full log which includes card reader information.

There seems to be a problem with your reader. We would need to closer analyze
the log (which I copy below):

DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
DBG: ccid-driver: PC_to_RDR_IccPowerOn:
DBG: ccid-driver: dwLength ..........: 0
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bPowerSelect ......: 0x01 (5.0 V)
DBG: ccid-driver: [0008] 00 00
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 21
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 3B DA 18 FF 81 B1
DBG: ccid-driver: [0016] FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: PC_to_RDR_SetParameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bProtocolNum ......: 0x01
DBG: ccid-driver: [0008] 00 00 18 10 FF 75 00 FE
DBG: ccid-driver: [0016] 10
DBG: ccid-driver: RDR_to_PC_Parameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: protocol ..........: T=1
DBG: ccid-driver: bmFindexDindex ....: 18
DBG: ccid-driver: bmTCCKST1 .........: 10
DBG: ccid-driver: bGuardTimeT1 ......: FF
DBG: ccid-driver: bmWaitingIntegersT1: 75
DBG: ccid-driver: bClockStop ........: 00
DBG: ccid-driver: bIFSC .............: 254
DBG: ccid-driver: bNadValue .........: 16
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 5
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] 10 C1 01 FE 2E
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 00 82 00 82
DBG: ccid-driver: invalid response for S-block (Change-IFSD)
apdu_send_simple(0) failed: unknown host status error
DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0

Without pcscd running, I get a "Not supported" error. The scd.log is attached.
Using pcscd, it works, except for that special case.

debug 2048
debug 1024

is what I need.

Thanks. We need to know some more detailed information. Please
put

debug 2018
debug 1024
log-file /somewhere/scd.log

into scdaemon.conf, kill scdaemon and try again. It seems you have not yet been
asked for a PIN so the log won't reveal the PIN. Anyway, you may want to send
the log to me by PM (wk@gnupg.org - key 1e42b367).

Fails with 2.0.29 too, compiled from source. With enabled debug-all verbose in
scdaemon.conf, the log ends with:

2016-03-19 10:12:09 scdaemon[1988] DBG: response: sw=6A88 datalen=0
2016-03-19 10:12:09 scdaemon[1988] operation decipher result: Missing item in object
2016-03-19 10:12:09 scdaemon[1988] app_decipher failed: Missing item in object
scdaemon[1988]: chan_7 -> ERR 100663364 Missing item in object <SCD>
scdaemon[1988]: chan_7 <- RESTART
scdaemon[1988]: chan_7 -> OK

The current version is 2.0.29 - please try again using this version.

I believe I have also seen this issue (or something very similar) on my Windows
7 64bit machine. I am running gpg 2.1.11. I hope this isn't redundant, but it
seems that I need to restart scdaemon anytime I unplug/replug my yubikey or
suspend/resume my computer.

Sometimes it doesn't recover even after restarting scdaemon. In those cases, I
am able to fix it by stopping scdaemon, removing the yubikey, starting scdaemon,
and finally reinserting the yubikey.

For what it's worth, with the following trivial patch the decryption works:

diff --git a/sm/decrypt.c b/sm/decrypt.c
index a560272..aa6e874 100644

• a/sm/decrypt.c

+++ b/sm/decrypt.c
@@ -74,9 +74,9 @@ prepare_decryption (ctrl_t ctrl, const char *hexkeygrip, const
char *desc,

    log_printhex ("pkcs1 encoded session key:", seskey, seskeylen);

  n=0;

• if (seskeylen == 24)

+ if (seskeylen == 24 || seskeylen == 16)

{

• /* Smells like a 3-des key. This might happen because a SC has

+ /* Smells like a 3-des or AES key. This might happen because a SC has

          already done the unpacking. */
     }
   else

I am not sure this is a good solution, though, it is probably better to somehow
pass along the information whether the padding is already stripped or not.

Kind regards,

Lorenz

This is likey due to the card already decoding the pkcs#1 - we need to look
closer at this use case.

For reference, I have a OpenPGP v2.0 card from "ZeitControl".

I think the card will always remove the encoding internally and only return the
plaintext, as far as I can tell from
http://g10code.com/docs/openpgp-card-2.0.pdf, Section 7.2.9

Look here:

gpgsm: DBG: pkcs1 encoded session key: 11 E8 C4 40 93 A8 24 35 16 57 93 8D 03 00
63 5F
gpgsm: decrypting session key failed: Invalid session key

This is clearly not a PKCS#1 encoded session key but a plain session key. This
is likey due to the card already decoding the pkcs#1 - we need to look closer at
this use case.

Thanks for looking at this!

I am on openSUSE (Tumbleweed), my gnupg version is
lorenz@host:~/gpgsm_problem> gpgsm --version
gpgsm (GnuPG) 2.1.10
libgcrypt 1.6.4
libksba 1.3.3
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://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: ~/.gnupg
Supported algorithms:
Cipher: 3DES, AES128, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, SEED,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Pubkey: RSA, ECC
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL

If I run

  gpgsm --debug 4 -d gpgsm_encrypted

the same session key is printed that my script got

Here is a full transcript:

lorenz@host:~/gpgsm_problem> gpgsm --debug 4 -d gpgsm_encrypted
gpgsm: reading options from '/home/lorenz/.gnupg/gpgsm.conf'
gpgsm: enabled debug flags: crypto
gpgsm: failed to open '/home/lorenz/.gnupg/policies.txt': No such file or directory
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28
31 3A 73 32 35 36 3A 75 46 91 66 A9 B6 A0 46 03 85 68 F1 E8 A5 37 14 30 BA E5 B6
A2 D6 5C E8 26 31 C7 9A AF 27 96 54 CD 6D 73 8C 70 73 CA C9 E9 73 9C E2 B3 5E 50
9B 7D 6A 5E C7 9E C4 34 FE 1B E1 9C DC 14 56 3F F4 29 A2 07 47 9D A5 5D 0E BE C3
F3 6E E6 49 3C 96 BB 43 3A 5B 1C 56 10 E3 3B 0C 3F 67 2F 31 B9 BF B7 38 4F CA C7
55 20 AC 50 76 6A CB FC C9 15 29 D5 10 89 31 88 A9 87 ED DC 2B A3 7C 22 E5 04 4F
16 A8 32 DF 62 56 B1 88 C8 80 0B 4B 93 E7 8A D4 35 D3 14 62 40 FB 87 82 EF E3 4F
DE ED 27 BF 0B 01 B1 49 C5 20 03 1A 04 87 31 55 14 7F B3 91 31 8A A8 E5 0C CF CE
25 77 6C A1 5C 5D EB 74 D5 28 4D DB 90 6A 87 B3 91 48 A0 72 10 2C C7 DD DA 2F E0
2E AA D1 BD D0 16 50 DB 30 12 08 C4 3A 62 DB 4F 77 E1 5E 18 ED 22 C1 70 32 2F C3
6A DE 66 B2 47 52 48 B2 86 B1 32 6C 6E 27 04 12 A8 E1 48 8A 29 29 28 34 3A 68 61
73 68 36 3A 73 68 61 32 35 36 29 29
gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 31
30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 82 A4 B2 5B 4E 14 77 27 0B 73
12 97 8F 56 FC 61 42 7E 37 3F 8B 74 3F 4E 40 2D 38 C1 08 47 32 6C
DBG: rsa_verify
data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d06096086480165030402010500042082 \
DBG: a4b25b4e1477270b7312978f56fc61427e373f8b743f4e402d38c10847326c
DBG: rsa_verify
sig:+75469166a9b6a046038568f1e8a5371430bae5b6a2d65ce82631c79aaf279654 \
DBG:
cd6d738c7073cac9e9739ce2b35e509b7d6a5ec79ec434fe1be19cdc14563ff4 \
DBG:
29a207479da55d0ebec3f36ee6493c96bb433a5b1c5610e33b0c3f672f31b9bf \
DBG:
b7384fcac75520ac50766acbfcc91529d510893188a987eddc2ba37c22e5044f \
DBG:
16a832df6256b188c8800b4b93e78ad435d3146240fb8782efe34fdeed27bf0b \
DBG:
01b149c520031a04873155147fb391318aa8e50ccfce25776ca15c5deb74d528 \
DBG:
4ddb906a87b39148a072102cc7ddda2fe02eaad1bdd01650db301208c43a62db \
DBG:
4f77e15e18ed22c170322fc36ade66b2475248b286b1326c6e270412a8e1488a
DBG: rsa_verify
n:+d851729ea0d4cb8241b06da9e2e2b96e6b98f39732127c79da8ffe6a4be9a88d \
DBG:
0a80fde61ad1b1ae732955e61c90bb2273edde2045c91d84c0d5f03648c44454 \
DBG:
22c1655c58fa1c61e36998e58481dba384b5d868cb8531f9619dfb3bb307570d \
DBG:
0bfc9861cd423111233565f453ff12ea873da27496234fdf16f4e16fccf813d3 \
DBG:
2add89e33390b533e57fdfa58f0cbb26018319dd741251c3a66d9617429a5e05 \
DBG:
f10df9a526fc276a80362c2e255bb75824e02ffc9da37780f2f0e278c319ecef \
DBG:
8bd700270b305b1c08c9e47eb153507b9a5c26bbb577a53a0a3e07169a53b41d \
DBG:
c4e96baf0c70d4c61a263ca4ed3f467d5f5e4a8361ff33d253dd5945b16ccd51
DBG: rsa_verify e:+010001
DBG: rsa_verify
cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d06096086480165030402010500042082 \
DBG: a4b25b4e1477270b7312978f56fc61427e373f8b743f4e402d38c10847326c
DBG: rsa_verify => Good
gpgsm: certificate is good
gpgsm: failed to open '/home/lorenz/.gnupg/policies.txt': No such file or directory
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28
31 3A 73 32 35 36 3A 3F DC 77 C2 D3 F0 64 6C AE 20 91 39 59 AF F4 E8 EC B3 F2 B4
BA 19 9A 85 9D 7B 8D 07 59 B8 F8 38 FF 54 7D 5D 80 5D 5B 7C B2 9B 86 48 61 6B DB
ED 8B DD 8E 78 1B 5D 62 0F E6 CF CA AF 78 52 64 7E B7 74 5C F0 57 FF 15 EA 7E DE
E7 A5 CA 73 DE F6 F5 B4 1D B9 39 C0 B3 EF 98 4F 15 14 CB 4E 69 16 76 B8 EC DB FD
04 26 E2 4B 91 13 5D 42 99 3C C2 09 03 4D 57 C0 0E F2 5E 41 4F F9 B4 5D 98 94 6C
16 7F 30 78 A6 E3 9C E1 35 76 6E B8 B5 7E AE A5 F3 F5 37 C8 56 90 67 EC 23 0C 8E
D8 DE 3B 49 31 EB BF 4F D5 3E 51 E1 2B 16 1D 2D 64 34 EE A6 C4 D6 9F C8 BD 05 B2
98 84 90 7B 02 C1 8E 63 BB DA 05 81 E2 87 06 03 67 D3 AC 3E F7 C2 7D BD 5F 86 6C
47 51 E7 D3 9C 62 E8 F2 D0 D3 A1 D0 3B 11 91 AD 2F 5E 10 3D 14 42 81 D8 CD FD 45
D1 AD E8 FB 36 3A 3A 7C 8D 69 C0 A6 77 85 6B 60 67 52 B4 1C 29 29 28 34 3A 68 61
73 68 36 3A 73 68 61 32 35 36 29 29
gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 31
30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 AC 84 B9 EC BF F8 15 90 76 00
F8 4A 76 2E 6E 51 C9 40 2B 43 D9 FB 28 C4 C1 E1 94 EC D5 14 4B D0
DBG: rsa_verify
data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420ac \
DBG: 84b9ecbff815907600f84a762e6e51c9402b43d9fb28c4c1e194ecd5144bd0
DBG: rsa_verify
sig:+3fdc77c2d3f0646cae20913959aff4e8ecb3f2b4ba199a859d7b8d0759b8f838 \
DBG:
ff547d5d805d5b7cb29b8648616bdbed8bdd8e781b5d620fe6cfcaaf7852647e \
DBG:
b7745cf057ff15ea7edee7a5ca73def6f5b41db939c0b3ef984f1514cb4e6916 \
DBG:
76b8ecdbfd0426e24b91135d42993cc209034d57c00ef25e414ff9b45d98946c \
DBG:
167f3078a6e39ce135766eb8b57eaea5f3f537c8569067ec230c8ed8de3b4931 \
DBG:
ebbf4fd53e51e12b161d2d6434eea6c4d69fc8bd05b29884907b02c18e63bbda \
DBG:
0581e287060367d3ac3ef7c27dbd5f866c4751e7d39c62e8f2d0d3a1d03b1191 \
DBG:
ad2f5e103d144281d8cdfd45d1ade8fb363a3a7c8d69c0a677856b606752b41c
DBG: rsa_verify
n:+e99bc36785f90daef58d54c39650353d62e96e4ced94d7005b952274d420eb34 \
DBG:
8fd6ecc031040b9981e2a614d252a02823848b7489045e5be0e278c178cb16cb \
DBG:
2835397b2d9045d0eda0007a7cbf4a0e1b00c386e95c2b31117b0cf38224438c \
DBG:
1c388b6a68009aeedc4f78abd2c6139b76adeede26e8ef01af740fc109a2f66b \
DBG:
cebdd3cd14304ff5e5e3a4c8629b821a0327300d0265604dedd109232a963558 \
DBG:
27d376c671b6901dc4edff35867d6f33b3db0fc511c28a83a1945d416bd8d210 \
DBG:
f54cfdca51acd9bdef9283bbdaeb8b16565643cfe1d5133da61f2730cd4954db \
DBG:
c913349a7175c56ceaa70b98f9219d27af3ea33939486a8cadc999fbc312f2bd
DBG: rsa_verify e:+010001
DBG: rsa_verify
cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420ac \
DBG: 84b9ecbff815907600f84a762e6e51c9402b43d9fb28c4c1e194ecd5144bd0
DBG: rsa_verify => Good
gpgsm: intermediate certificate is good
gpgsm: failed to open '/home/lorenz/.gnupg/policies.txt': No such file or directory
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28
31 3A 73 32 35 36 3A 63 20 28 FD 9C 21 86 72 BE 39 46 59 39 32 25 BC A9 01 9B 0D
CC CA 7D 41 9C 86 6D 0A 6E 2C B3 13 59 75 B1 33 92 1B 61 27 16 FF C3 B2 D5 35 82
FB 84 2A 01 49 BD 66 BB 66 2F B2 C2 06 5D 6E 3F 6E E3 01 5A 5B CA 43 63 5C 95 B6
E1 31 A7 1F D5 07 5F 4D E6 65 82 4E 32 F9 C3 7C 7A 4B CD 4D 5C 74 EE 21 F2 75 02
EC 52 3E D2 C9 6A D3 90 23 6E 49 67 35 BE 7F 4D 56 A4 EC CC 2F CF B7 A1 97 A8 72
3E C9 BC 40 D6 5A A4 08 3D D6 BC 82 C3 B7 B7 32 8E B1 2C 8E 6A 6D B7 35 02 19 CF
F5 39 44 58 63 A7 24 00 10 B0 BB FC 4E AF 6E 2F 38 BB A5 57 49 3F D8 6E 50 6F 2C
97 96 DC 1D 46 9A 65 89 CF AE CC F2 E5 D9 9F 53 B3 3E A1 2F 92 A9 D8 0B C6 84 1F
04 C6 EB 1E E8 9F 7D B5 7B A5 02 F1 24 C5 24 63 11 34 CC 5A 93 20 2A 79 88 3A 25
42 90 A9 65 3B 7C 86 D3 12 15 23 29 FC 2C DA CC 39 5B 54 17 29 29 28 34 3A 68 61
73 68 36 3A 73 68 61 32 35 36 29 29
gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 31
30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 DF 7B C9 01 35 70 5A 34 2B 30
ED 96 C6 35 7F 80 51 5A 56 9C B6 89 F2 9D 69 DE E4 02 3F 5E 7C 9A
DBG: rsa_verify
data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420df \
DBG: 7bc90135705a342b30ed96c6357f80515a569cb689f29d69dee4023f5e7c9a
DBG: rsa_verify
sig:+632028fd9c218672be394659393225bca9019b0dccca7d419c866d0a6e2cb313 \
DBG:
5975b133921b612716ffc3b2d53582fb842a0149bd66bb662fb2c2065d6e3f6e \
DBG:
e3015a5bca43635c95b6e131a71fd5075f4de665824e32f9c37c7a4bcd4d5c74 \
DBG:
ee21f27502ec523ed2c96ad390236e496735be7f4d56a4eccc2fcfb7a197a872 \
DBG:
3ec9bc40d65aa4083dd6bc82c3b7b7328eb12c8e6a6db7350219cff539445863 \
DBG:
a7240010b0bbfc4eaf6e2f38bba557493fd86e506f2c9796dc1d469a6589cfae \
DBG:
ccf2e5d99f53b33ea12f92a9d80bc6841f04c6eb1ee89f7db57ba502f124c524 \
DBG:
631134cc5a93202a79883a254290a9653b7c86d312152329fc2cdacc395b5417
DBG: rsa_verify
n:+ab0ba335e08b2914b11485af3c10e4396f355d4aaeddea618d9549f46f64a31a \
DBG:
6066a4a9402284d9d4a5e578930e6801adb94d5c3aced3b8a84240dfcfa3ba82 \
DBG:
596a921bac1c9ada082b2527f9692347f1e0eb2c7a9bf51302d07e347cc29e3c \
DBG:
0059abf5da0cf5323c2bac50dad6c3de8394caa80c99320e0848565b6afbdae1 \
DBG:
585801495f72413c1506018e5dadaab893b4cd9eeba7e86a2d5234db3aef5c75 \
DBG:
51dadbf331f9ee719832c45415440cf99b55edaddf1808a0a3868a49ee53058f \
DBG:
194cd5de58799bd26a1c42abc5d5a7cf680f96e4e161987661c8917cd63e00e2 \
DBG:
915087e19d0ae6ad97d21dc63a7dcbbcda0334d58e5b01f56a07b716b66e4a7f
DBG: rsa_verify e:+010001
DBG: rsa_verify
cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420df \
DBG: 7bc90135705a342b30ed96c6357f80515a569cb689f29d69dee4023f5e7c9a
DBG: rsa_verify => Good
gpgsm: root certificate is good
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: validation model used: shell
gpgsm: DBG: recp 0 - issuer: 'CN=mail@example.com'
gpgsm: DBG: recp 0 - serial: 52DF665BB71FAF4F
gpgsm: DBG: pkcs1 encoded session key: 11 E8 C4 40 93 A8 24 35 16 57 93 8D 03 00
63 5F
gpgsm: decrypting session key failed: Invalid session key
gpgsm: message decryption failed: No secret key <GpgSM>
secmem usage: 0/16384 bytes in 0 blocks

Which OS and which gnupg version are you using?

Use

gpgsm --debug 4 -d gpgsm_encrypted

to see the session key before gpgsm detects thaty it is invalid.

Thank you again.

It is likely that the token itself doesn't work well after wakeup from sleep
mode. In this case, all that we can do is re-inserting the token manually.

I'm not sure how PC/SC service handles USB reset after wakeup.

Sorry to say, but mapping the error to "no reader" doesn't help. The first
reset event doesn't get handled. Later it trys to remove the reader but it's
not getting correctly resetted/reinserted again.

I've attached the debug log again

Thank you for further testing.
I think that current code doesn't handle the case when card goes inactive/reset
while reader keeps working. Current code only goes to the reset sequence for a
card again when it detects reader failure. So, although the concept is
different, I think mapping PSCS_W_CARD_RESET to SW_HOST_NO_READER (for now) will
work. Given the situation we don't yet support multiple cards, this workaround
would be OK for a while.

Nope. Neither mapping the "reset card" event to SW_HOST_CARD_INACTIVE or
SW_HOST_NO_CARD helps. It seems that somewhere in the code the return code
SW error codes are not being handled correctly and the card doesn't get
resetted.

I've attached a small log where you can see that pcsc returns the error
reason "reset card" which then gets remapped to "Card reset required" (was
general error before). I also can see that the error is getting mapped to
GPG_ERR_CARD_RESET (because of the error message "Card reset required")
leaving the daemon around with no working card and reporting general errors
again (0x100b).

Additional Info: This bug only happens when you put your computer/laptop
into sleep mode while the smartcard/reader (yubikey) is plugged in. If I
remove the reader before putting it to sleep and attaching it after getting
out of the sleep mode, the scdaemon works fine.

D338: 740_0002-scd-map-card-reset-event.patch