Sat, Feb 9
So, the keyserver operator had thrown in a hockeypuck server in the pool, causing this.. While the keyserver remains in the exclude list until confirmation it has been resolved, that explains the behavior and it has been made clear that separate software needs to use different names in the future.
Mon, Feb 4
@kristianf we talked about this on Saturday evening. Would you be so kind and have a quick look at the problem with the hu server?
Fri, Feb 1
Hi Werner and thanks for looking into this.
Wed, Jan 30
According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.
Oct 29 2018
It actually tries several servers but we need to set a limit because we need to cope with longer timeouts. Do you suggest to toggle between v4 and v6 addresses? That is if a v6 address fails, first try the next v4 address and it that fails, another v6 address, etc.
Oct 2 2018
The problem is that the keyserver network is abused as free and
permanent data storage. We can't do much about it without larger
changes on the search capabilities of the keyservers. For more
information see the archives of the sks-devel list starting in July.
Oct 1 2018
Ok. I was not aware that HKPS should already have the highest quality.
hkps pool really should be the most responsive, and it already requires clustered only servers for a couple of weeks to try to increase the responsiveness. Experience has shown that any keyserver with less than 3 nodes in a cluster should not be used towards end-users. But do you have any more debugging output as to the problem at hand?
Sep 11 2018
We assume that this has meanwhile been fixed.
Aug 29 2018
@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?
Nov 19 2017
You know... I think connman and DNS have something to do with this. Connman does some weird DNS thing. And it auto-generates /etc/resolv.conf to use localhost as the DNS server.
Oct 24 2017
Oct 20 2017
Sep 24 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
Jun 23 2017
Any update on this?
Mar 30 2017
Mar 20 2017
Mar 16 2017
I was able to reproduce it again. Maybe this bug depends on which keyserver in
the pool answers. The error is the same for Tor and non-Tor connections.
I don't know why, it is not repdroducible anymore.
Feb 21 2017
Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?
Feb 19 2017
Dec 19 2016
> $ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
> gpg: no keyserver known (use option --keyserver)
> gpg: keyserver search failed: No keyserver available
>
> WHAT?! I just specified --keyserver!!!??
Relax. You forgot the '.pool' in the url.
:facepalm: ... Apparently I need more coffee -- persistent failure state in user
encountered.
Sorry for the noise.
I do wonder about fault-tolerance, though, if a e.g. non-responsive host creeps
in to the pool.
At any rate, this is mainly a cosmetic issue at this point, and this bug report
probably contains sufficient information to help someone who "encounters" the
condition to resolve the protocol error quickly.
For the records, the suggested way to kill dirmngr is
gpgconf --kill dirmngr
this makes sure that dirmngr will not be started if it is not running.
tl;dr: HKPS handler will die when used with non-HKPS hosts in a given pool.
I think dying is reasonable. Maybe it should return a nicer error
than 'general error' and it shouldn't take 10 seconds to figure out
the protocol error.
Using setup directions from
https://sks-keyservers.net/overview-of-pools.php I assumed that
configuring my GnuPG client to use ipv4.pool.sks-keyservers.net
would provide an appropriate response. It took me quite some time to
determine that HKPS is totally incompatible with the ipv4 (or other)
server pools.This is further confused by the fact that an older version of the
GnuPG skeleton files which includes a clause with examples that mix
HKPS and hkp servers (skel may not necessarily be updated in a
user's directory):
Sorry about that. I think the current skeleton file is clearer on
this.
As a result, I kept encountering the errors reported in
T1792
I don't see a connection to this bug.
Here's a simple demonstration of the failure case
$ gpg2 --keyserver hkps://ipv4.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: error searching keyserver: General error
gpg: keyserver search failed: General errorContrast with:
$ gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: data source: https://mud.stack.nl:443
(1) NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>2048 bit RSA key 2071B08A33BD3F06, created: 2014-10-29, expires: 2020-10-30PERSISTENT FAILURE CASE:
Now, once the failure condition is encountered, further queries FAIL:$ pkill dirmngr
A nicer way to kill the dirmngr is:
gpg-connect-agent --dirmngr 'killdirmngr' /bye
$ gpg2 --keyserver hkp://pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: error searching keyserver: No route to host
gpg: keyserver search failed: No route to host
This is strange, and looks like it should work. Works over here. Maybe it is
bad luck and you got a bad host from the roundrobin.
$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver availableWHAT?! I just specified --keyserver!!!??
Relax. You forgot the '.pool' in the url.
Let's see if this can be rectified with clearing the keyserver:
$ gpg-connect-agent --dirmngr keyserver
> keyserver --clear
OK$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available
Likewise.
- Try this with other VALID --keyserver combinations. Bang head against wall. The ONLY command that seems to fix this persistent failure case: $ gpg2 --search-keys 2071B08A33BD3F06 Suddenly, I can use --keyserver again, after this.
I'm pretty sure you just messed up the urls.
Dec 13 2016
Jan 15 2016
Jan 7 2016
Sorry, I can't see any problem here.
The "priotr-old" key is actually the newer key because an expiration date was
added to that copy of the key (2012-07-09) and that key has meanwhile expired.
Thus you can't encrypt using this key.
When you import the "piotr" key that is actually the same key but w/o the update
with the expiration date. Thus gpg does not chnage the exiting in key because
the existing key has a newer self-signature (where the expiration date is
stored) than the new key. So nothing changes, which is correct.
If you delete the .gnupg directory you don't have the newer key and by importing
the key w/o the expiration date you can encrypt to that key.
Jan 6 2016
Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.
Jan 5 2016
1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.
Dec 27 2015
As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/