Do you mean this?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 8 2017
Sep 7 2017
Sep 4 2017
No, there isn't any error message or output, and it not accept any input.
Here is a GIF capture, but may not helpful.
dirmngr is meanwhile an integral part of GnuPG. The old 1.1 dirmngr is entire obsosolete and won't do what gpg expects from it. To better diagnose the problem you can do this:
Aug 28 2017
Aug 27 2017
Well, I'm able to reproduce this issue on Parabola. I was also get a different error when I turn off my vpn: `server indicated a failure```, but now I get the dns error again.
elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net gpg: using character set 'utf-8' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg gpg: DBG: chan_3 <- # Config: [none] gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.1.23 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/ gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr> gpg: error searching keyserver: Connection closed in DNS gpg: keyserver search failed: Connection closed in DNS gpg: DBG: chan_3 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=0 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks elonsatoshi@tyger ~> sudo rc-service openvpn stop [sudo] password for elonsatoshi: * WARNING: openvpn is already stopped elonsatoshi@tyger ~> pidof openvpn elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net gpg: using character set 'utf-8' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg gpg: DBG: chan_3 <- # Config: [none] gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.1.23 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/ gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr> gpg: error searching keyserver: Connection closed in DNS gpg: keyserver search failed: Connection closed in DNS gpg: DBG: chan_3 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=0 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks
Aug 14 2017
In T3331#101967, @werner wrote:If you don't have a TCP enabled OS, you can use configure --disable-dirmngr.
Aug 5 2017
I see your point.
BTW, dirmngr has an option --disable-ipv4.
If you don't have a TCP enabled OS, you can use configure --disable-dirmngr.
Jul 28 2017
why should it wait for the timeout in the pselect call? shouldn't it be able to respond immediately to the final connection closing?
Jul 26 2017
FWIW, using a Debian specific thing is not portable and Unix sockets won't work on Windows. Thus using the standard localhost connection is simpler than adding extra complexity.
Okay, I implemented the second part and Tor is now used if availabale.
--no-use-tor disables Tor.
--use-tor forces use Tor and can't be reset.
Jul 25 2017
Sufficient workarounds have been found.
It takes a couple of seconds for dirmngr to terminate after closing the last connection, maybe due to the timeout in the pselect call. Apart from that, it works as expected.
Jul 19 2017
Fixed in e7fc6e3bf0eb6ffe53e1f099d28ce45cef4a8a87.
Implemented in da91d2106a17c796ddb066a34db92d33b21c81f7.
Jul 18 2017
Fixed in b231959728a0056094134e0fca8cc916c24ef37e.
Jul 17 2017
Jul 13 2017
Jul 12 2017
Agreed, i think the OP is asking for X when he wants Y, so that makes this request a little bit strange.
Jul 11 2017
Note that the documentation clearly says that --nameserver expects an ip address. Now we could make it accept a port too, but that would not make the OP happy, as he wants to talk to localhost, but in tor mode, all dns requests are routed through tor (this is actually one of the main motivations for using a custom DNS resolver).
Jul 6 2017
Jul 1 2017
This works now, there have been many changes in how homedir is handled since then. For example 70a8584ec4389209762eb65bb77f20f7881577be and aab8a0b05292b0d06e3001a0b289224cb7156dbd, among many others.
Digicert TERENAPersonalCA3 doesn't use issuingDistributionPoint anymore. It's hard to survey CRLs that are actually in use, so I don't know if there are other important users, but the fact that nobody else reported such problems is an indication that it is not widely used among dirmngr users. Supporting this is a lot of work, because it makes validating certificates much more complicated, so this is unlikely to happen without strong motivation, so I am closing this here.
Jun 30 2017
I added a new task status "Testing".
Jun 29 2017
On Wed, 28 Jun 2017 15:47, noreply@dev.gnupg.org said:
What tests do you want to be done?
Jun 28 2017
What tests do you want to be done?
Given that we have no TESTING status, the only way I can handle this is by keeping the ticket open and add the TESTING flag. Closing a bug which has not been tested is a bad idea.
Jun 27 2017
@werner An open ticket should mean there is something that can be acted upon. Unless you are saying that we should actively look for regressions or should actively do more testing, this ticket should be closed now. There is plenty of peripheral information that will remind us of this ticket in case more issues resurface related to this change.
Jun 26 2017
Jun 23 2017
Any update on this?
Libgcrypt 1.6 reaches EOL in 7 days, so we won't fix it.
This is such a large change that I feel uneasy to close the bug before we know that there are no regressions. This Means we need to wait whether the next release will break.
Jun 20 2017
Fixed in 48aae8167dcae80d43b08167a88d9eb170781a04.
Jun 13 2017
This is fixed now. The fix 15d2a009931f44a60b9df6325f837add208459d6 should be easy to backport.
Jun 12 2017
Jun 8 2017
Jun 7 2017
Problem with your DNS server We had a similar bug report here or on the ML. IIRC the DNS does not do what it is supposed to do. Need to lookup the details.
@werner I've done the changes you suggested. This is what I get in dirmngr.log:
Given that this is just a warning, we should not consider it a bug.
Please add
May 29 2017
May 28 2017
Dirmngr uses its own resolver for these reasons:
May 27 2017
debian stretch's 2.1.18 also suffers from this (debian bug tracker). As there is only 13 days left for fixing issues in stretch, swift action is needed.
May 24 2017
May 21 2017
Just as a remainder: unlike Arch, Debian has gnupg and dirmngr in 2 different packages. The bug is in dirmngr.
May 19 2017
I'm using 2.1.21-2 from the debian experimental build, and i'm not seeing this misbehavior.
May 16 2017
Fixed in 2.1.21.
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 8 2017
This seems to work just fine on our archlinux box with the nsswitch configuration above.
Justus, will you please so kind and take care of this.
May 3 2017
Apr 28 2017
Apr 25 2017
Thanks for your confirmation. I pushed the commit.
You're right this function is the culprit. The
I suspect compiler optimization.
If you are with debugger, please check the function dns_ai_setent in dns.c.
When type==DNS_T_A, it sets sin_family = AF_INET. But it does some violent memory access for modern C.
Then, the value is accessed through saddr->sa_family.
I wonder if (*ent)->ai_family is correctly set here.
This is what I see in gdb after the host resolution is called:
The machine is x86_64 qemu-kvm virtual on x86_64 host.
Apr 21 2017
Apr 7 2017
Apr 4 2017
I don't have one of these systems handy to test with, but if the fix in dee026d7 does what it says it does, this sounds like it's probably OK to close in my book. if there are more problems, i'm sure we can re-open it.
Apr 3 2017
dkg: Can we close this now that 2.1.20 is out?
Mar 31 2017
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.
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.