No way to fix, itself. Better warning/error message can be done.

we are now at 2.1.20 - time to mark this one as resolved.

We also have a discussion of the mailing list. It does currently not make sense
to continue here.

The problem of NFS mounted home directories is _real_ and we have a solution for
this which is better than the old redirection hack.

The problem with too long socket names is not severe and has been around for
decades (for other software and 14 years for GnuPG). There are workaround and
/run/user also solves this.

I proposed a change which does not even require --create-socketdir. There was
no comment on this and thus I will push that now so that we can do a real life test.

Justus: I told you several times that we are not going to change working code
for no good reason.

Except that it is not working. If it was working, then
06f1f163e96f1039304fd3cf565cf9de1ca45849
would not be necessary.

Even if your hack (I call it a hack because it does not
work with getsockname)

1/ Yes it does. It returns precisely the path that was used in bind.

2/ We only use getsockname on sockets that were given us by a service manager
like systemd, and thus those sockets would be unaffected by "the hack".

would make it, it does not solve the major problem: The
inability of creating sockets on certain file systems. THAT is the major reason
why we moved to /var/run.

Please stop conflating these things. This bug is about "dirmngr and gpg-agent
should work automatically even when GNUPGHOME is larger than sun_path". It is
not about NFS or FAT or something.

Implemented in 2.1.19

Hello Werner,

The problem is, that some projects liek gpgtools for MacOS are reluctantly sticking to
gnupg-2.0 :-/

So, I'd love to have this patch committed in order to ease the transition phase from

2.0 to 2.1 for them.

Regards, Wolfgang

Justus: I told you several times that we are not going to change working code
for no good reason. Even if your hack (I call it a hack because it does not
work with getsockname) would make it, it does not solve the major problem: The
inability of creating sockets on certain file systems. THAT is the major reason
why we moved to /var/run.

The whole IPC thing is pretty complex and adding a non-standard hack as proposed
by Justus will for sure cause breakage on some platforms.

I'm not sure why you call it a hack. I've been looking at POSIX, [0] introduces
pathname resolution, and the terms 'relative path' and 'absolute path'.

0: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13

Neither the page for connect [1], nor the one for bind [2] state that the path
used to connect/bind unix sockets must be an absolute path.

1: http: / / pubs.opengroup.org/onlinepubs/9699919799/functions/connect.html#
2: http: / / pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html#

Furthermore, my test across a wide range of UNIX implementations did not show
any issues with using relative paths.

I agreed in T2964 (wk on Mar 01 2017, 07:31 AM / Roundup) to auto create socket directories. I would like to do that
only for a tmpfs but we can also try to do this always. Adding a inotify watch
to remove the directory is more complex and I am not sure whether this is really
needed. The other thing is simple and we could do that for 2.1.20.

The whole IPC thing is pretty complex and adding a non-standard hack as proposed
by Justus will for sure cause breakage on some platforms.

Yes, we should document /var/run recommendations in the README. I will do that
for the next release.

This bug report simply asks to solve the generic problem of GNUPGHOME being
larger than sun_path. Justus's proposed mechanism is only one way of solving
that problem.

Another proposed mechanism is what i originally proposed in T2964 (dkg on Feb 17 2017, 01:52 AM / Roundup), which
*does* address remote filesystems and re-mounted filesystems.

I don't undertstand the critique about the code not yet being mature. Code
doesn't become mature by not being written, it needs to be written first and
then tested in order to become mature.

Lastly, i think if we expect that /run/user/$(id -u)/ is a "simple dependency"
for building other software, we need to make that expectation explicit someplace
reasonable (e.g. doc/HACKING or something similar)

I've tried latest master and it no longer hangs for me.

Thanks. Changing the status to not-released as this is fixed.

My main reasons why I don't want to consider this now are:

• That code is not written and thus will not be matured.
• It does not solve the major problem why we moved to /var/run, namely remote file systems and avoidance of possible re-mounted file systems
• The claim that /var/run/user does not exists is not valid, because that is a simple dependency for building the software or using it with non-common setups (remot, long $HOME). Thus an admin will anyway be on duty and adding a few lines to /etc/rc.local is not a bug deal.

FWIW, we may try this in 2.3 see T2987.

Werner does not think that this is a problem and does not want me to spend time
on this.

getsockname is only used to recover the paths of sockets bound by a supervisor
like systemd. So unless systemd starts doing the same trick that I propose,
there is no problem.

This patch tried to fix the issue:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=f9acc7d18bb90f47dafe7e32ae92f567756d6b12

I was wrong that PIPE can be select(2)-ed on Windows. This patch changes the
code so that it uses kill(2) on UNIX and SetEvent on Windows
to break the loop.

With this patch the log message is different (No such file or directory). Hang
still happens.

2017-03-03 10:21:06 scdaemon[8604] DBG: enter: apdu_get_status: slot=0 hang=0
2017-03-03 10:21:06 scdaemon[8604] DBG: leave: apdu_get_status => sw=0x0 status=7
2017-03-03 10:21:06 scdaemon[8604] npth_pselect failed: No such file or
directory - waiting 1s

Version was 2.1.19 from the installer built by werner / the speedo system.

I'll try out the patch

It seems npth_eselect is for network FDs.

How about this change?

diff --git a/scd/scdaemon.c b/scd/scdaemon.c
index f7e9f83b5..462ff1b3e 100644

• a/scd/scdaemon.c

+++ b/scd/scdaemon.c
@@ -1291,7 +1291,7 @@ handle_connections (int listen_fd)

while (npth_sigev_get_pending(&signo))
  handle_signal (signo);

#else

• ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, t, NULL, NULL);

+ ret = npth_select (nfd+1, &read_fdset, NULL, NULL, t);

saved_errno = errno;

#endif

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