For some reason, scdaemon.log is not yet available here. Please put it again.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 20 2017
Nov 18 2017
Ok, edited ~/.gnupg/scdaemon.conf to contain
Nov 17 2017
You may have other changes on your system as well.
Nov 16 2017
But this does not explain why it works on the same system with GPG 2.1.11 instead of 2.2.2.
Here is what happens after applying the suggested quick fixes:
--- ~ » sudo pcscd --- ~ » sudo chown enno /dev/bus/usb/002/005 1 ↵ --- ~ » sudo chgrp users /dev/bus/usb/002/005 2 ↵ --- ~ » ls -l /dev/bus/usb/002/005 crw-rw-r-- 1 enno users 189, 132 16 nov. 15:17 /dev/bus/usb/002/005 --- ~ » gpg --card-status gpg: selecting openpgp failed: Aucun périphérique de ce type gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type
So you either need to start pcscd or you fix the permission of the device so that GnuPG's scdaemon can access the card reader using its internal access method. There are probably some udev rules which need to be adjusted. For a quick check you can manually change the owner or group to your own user or one of your groups. Then it should work again.
Dear Werner,
Entering on the shell
lsusb | grep USB
Nov 7 2017
Implemented in a branch: gniibe/scd-kdf-support
Nov 2 2017
Changes for Gnuk is done. It's now testing. It will be in Gnuk 1.2.7.
Oct 30 2017
D441 applied. Closed.
Oct 26 2017
I am pretty sure that older cards required this behaviour. It might have been a workaround for a bug in scdaemon, though - I am not sure. So we should test this with all available card versions.
Oct 24 2017
I am closing this bug report, as I can't get feedback to fix something.
Oct 20 2017
gniibe: Can you check the status?
Oct 17 2017
Hello.
I am having the same problem with my Yubikey v4.
Sep 21 2017
Sep 7 2017
Aug 1 2017
D441: card: Yubikey factory-reset failure is the patch.
This may fix the problem for new version 4.2.7:
Jul 27 2017
Jul 25 2017
That is the way I get my certificate signed, there is nothing I can do about it ;-)
It's not really a good idea to use the same RSA key for encryption and signing. (Although when I wrote scute, I couldn't generate a CSR for the encryption key, because the CSR had to be self-signed, meh).
Jul 24 2017
Jul 20 2017
Given that 2.0 only gets important updates, and for 2.1 it is fixed, we can close it.
Jul 19 2017
Jul 17 2017
@werner I request re-consideration. I *have* read the discussion, and remain convinced that a parameter that allows shared access is necessary.
gpgtools will have to update.
Jul 13 2017
Jul 10 2017
This is on purpose. Please read the discussions. Use card-timeout in scdaemon.conf or "gpgconf --kill scdaemon"
Jul 7 2017
Jun 26 2017
If this is gone in master, please close this bug. Thanks :).
Jun 23 2017
Issue seems to be gone in gpg (GnuPG) 2.1.22-beta75
Jun 9 2017
Specification is finished.
bit 0 (in smartcard context, we say b1 as it starts from 1) of Extended Capabilities specifies if KDF-DO is supported.
Tag for KDF-DO is assigned as:
Jun 6 2017
May 29 2017
May 24 2017
May 22 2017
May 15 2017
Automatic creation of socket directories creates cleanup trouble for projects previously relying on the agent-shutdown if $GNUPGHOME is removed: https://notmuchmail.org/pipermail/notmuch/2017/024550.html
May 11 2017
Here is the spec.
May 9 2017
May 1 2017
The debug log includes communication between host PC and the reader, thus, it may include your input of PIN when you do that.
Apr 30 2017
Ping? Otherwise I would provide the required information.
Apr 12 2017
By the commit: rGf053f99ed0b0: scd: Handle unexpected suspend/resume by CCID driver., I put some code to handle such an expected return from the device.
Please try.
I couldn't reproduce this on my machine. (Suspend-to-RAM keeps my USB device running.)
Apr 11 2017
It looks like the device got suspended and resumed.
But the application (scdaemon) didn't get noticed by libusb.
So, scdaemon kept communicating as usual, but got unexpected msg type = 0x81,
which is error report status (RDR_to_PC_DataBlock).
FWIW, the syntax of "vendor-id:product-id" is used for USB for any USB tools.
In T3082#95656, @gniibe wrote:Thank you for your comment.
I think that a practical approach for us would be having a list of vendor-id:product-id in a file under gnupg/doc/ and maintain the list.
It will be up to distributions to use the list to build hwdb, udev rules, or whatever.
Thank you for your comment.
In T3082#95636, @gniibe wrote:(3) We don't know which smartcard reader works fine, while we know some readers don't work well.
While I understand your request, it's complicated.
No way to fix, itself. Better warning/error message can be done.
Apr 4 2017
Apr 3 2017
we are now at 2.1.20 - time to mark this one as resolved.
Mar 30 2017
Mar 24 2017
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
Mar 22 2017
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
Mar 21 2017
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.
Mar 14 2017
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)
Mar 13 2017
I've tried latest master and it no longer hangs for me.
Thanks. Changing the status to not-released as this is fixed.
Mar 6 2017
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.
Mar 4 2017
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.
Mar 3 2017
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