gniibe: Can you check the status?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 20 2017
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
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
Mar 2 2017
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...).
Mar 1 2017
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:~$
Feb 28 2017
Feb 14 2017
Feb 13 2017
Feb 9 2017
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:
/* 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.
Dec 8 2016
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).