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

Any update on this?

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.

Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?

$ 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 error

Contrast 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-30

PERSISTENT 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 available

WHAT?! 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.

1. 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.

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.

Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.

1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.

As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/

Applied with commit ea079d2. Thanks.

Haven't seen this problem for months and npth-1.2 contains the fix.

-> Resolved.

You've actually added code to handle the hostname:port string with rev: 54e55149

But this does not work as the parse_uri check before hat is called with
"no_scheme_check" and so already passes a hostname:port uri as valid and does
not go into the fallback code that adds the http scheme.

D329: 685_0001-Dirmngr-Default-to-http-protocol-for-http-proxy.patch

Regardless of that, I find this is a regression. With my configuration I was
able to search on keyservers with 2.0.x and then with 2.1.x keyserver search no
longer works with the same configuration.

And it's probably easier to default to http protocol for a http-proxy in gnupg /
dirmngr again then it is for me to warn users in Kleopatra / Gpg4win that their
configuration no longer works with 2.1.

Actually I plan to remove (or make them a NOP) all network options from
gpg.conf. This should all be configured in dirmngr.conf.

This seems to work with gnupg-2.1.4. Thanks!

Can you please try with the latest version (2.1.4 will be released tomorrow)

The context menu of the key manager now has a "refresh key" item.

The sem_post in enter_pth can't set ERRNO because we assert the return value
later. However, the sem_wait in leave_npth has the usual EINTR protection and
thus changes ERRNO. Needs to be fixed.

No this was on "the master of the day"

And with the dead server detection the case for "localhost lookup" already got
better.

But you could look at npth src/npth.c
I am pretty sure that npth_enter and npth_leave modify errno and that this
causes at least npth_connect not to set errno as expected.

This was straight 2.1.0, right? Please try again with 2.1.1 there are just to
many bugs fixs that it is not worth to look at 2.1.0. If it is still the case I
can look at (although that you assigned yourself ;-)

I had another go at this bug this evening. I had a keyserver with reproducable
failures (while I still could use it in gpg1). And suddenly during debugging it
all changed and worked flawlessly. I was down to npth_connect and after I had
added debug output in there it began to work (and kept working after removing
the debug output again, hrmpf)

With regards to the test case from T1773 (aheinecke on Nov 26 2014, 10:35 PM / Roundup). This now (after e8c0ed7 ) returns a
dead host.

Btw. I think the error message could be improved for dead hosts.

gpg2 --keyserver hkp://127.0.0.1 --search foobar
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Should be something like "No reachable keyserver found"

Assigned this bug to me to at least provide a clearer example.

Thanks for fixing the 127.0.0.1 lookup error :)

The problem was with that specific keyserver. If I use another keyserver it
works. The keyserver was the first one returned to me by using the
keys.gnupg.net pool and as gpg 1 works with it.

I've debugged the issue.

The test case is now reduced to:
gpg2 --keyserver hkp://127.0.0.1 --search foobar

Dirmngr logs:

2014-11-26 20:35:55 dirmngr[5892.1] getnameinfo returned for '127.0.0.1':
'localhost'
2014-11-26 20:35:55 dirmngr[5892.1] can't connect to '127.0.0.1': Success
2014-11-26 20:35:55 dirmngr[5892.1] error connecting to
'http://127.0.0.1:11371': System error w/o errno
2014-11-26 20:35:55 dirmngr[5892.1] command 'KS_SEARCH' failed: System error w/o
errno

In my case this is because common/http.c (connect_server) ~ line 2200

  ai->ai_family == AF_INET && (flags & HTTP_FLAG_IGNORE_IPv4)

Returns true for 127.0.0.1 (same for 75.75.183.132 which also explains why it
works with gnupg) the address is skipped but it is the only one -> loop finishes
with no errno set.

It is set in dirmngr/ks-engine-hkp.c which looks to me like: "If it is not
indicated that a host either uses IPv4 nor IPv6 ignore it." Which i find kind of
harsh. At least a debug output like:

      if (!hi->v4 && !hi->v6)
        log_debug("Ignoring host\n");

Should be added there and of course connect_server should return an appropiate
error in case it never actually tried to connect to a server.

While debugging this I think I found another issue. You are using errno after
my_connect calls. If this expands to npth_connect the actual calls are

enter_npth()
sem_post() modifies errno
connect() modifies errno
leave_npth()
sem_wait() //modifies errno

Afaik enter / leave in npth should save errno. I could not confirm that this is
really an issue with a test but I think it is.

Tested the patch with 1.4.4 on Windows against
vm-keyserver.spline.inf.fu-berlin.de which did not work previously.

Patch is also included in gpg4win now.

Thanks!

There is no guarantee that you will see a keyid at all. The keyid and the
fingerprint are actually different objects and it is only for v4 key format that
you can compute the keyid from the fingerprint. We have to implement this
knowledge into gpgme.

Meanwhile I did this and master does now work as expected. It even returns the
fingerprint if available. You may this with the also enhanced gpgme-tool.

While working on it I also fixed the --search-key thing for gnupg master.

D209: 447_keylist-shortening.patch

damn, thats the creation date of the last userid - i was too stupid to read the
draft of hkp.
http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-5.2
-> Close

This is a good feature request, but it requires some coding to make it work. I
think that this should be done via a context popup menu on the keylisting
entries (in addition to a menu entry).

We have a lot of changes in the current development version. Please check that
one out or wait until we do a new release.

The fix is in 1.4.8.

Looks like gpgkeys_curl.exe is being run instead of gpgkeys_hkp.exe. I'm pretty
sure this fixed it:

There is a HKP keyserver now running at hkp://demokeys.gnupg.org .
I am currently loading up a snapshot of another keyserver. There won't be any
syncing unless people manually sync.

Makes sense to me.