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.