Patch lets it build on xenial for me, thank you.

I committed the partial result docker container, so I can restart it for investigation. So:

Oh. T1447 only referenced SRV records, which is why the CNAME case wasn't handled. So T1447 was fixed completely but T1447 did not cover the full extent of the underlying problem.

Am able to reliably trigger the flaw, by using a curl-shim gpg from another
machine on the same network as the keyserver. Close network proximity without
being the exact same machine makes it much easier to trigger the race.

The behaviour matches that observed in released versions; I was debugging a
problem observed in the released versions, not reviewing code looking for issues.

Whether or not it's used in the current development branch, this has caused an
interoperability issue in the real world for the keyserver operators, causing a
functionality deployment to be rolled back and resulting in filtered results,
reducing the pool of available keyservers.

Since Issue1447 is a security impacting issue which will need a CVE and a security
release to fix anyway, it would really be nice to try to get the fix for client
behaviour into a version which is likely to be pushed out widely. Not critical,
security comes first, but if we can leverage the security release to improve
interop, that would be helpful.

In practice, we (the keyserver operators and pool operators) are stuck not able to
use SRV to point to non-default ports for at least a couple of years. This is
very unfortunate, given the efforts currently being made to make deployments more
robust, with TLS more widely deployed.

% git remote -v
origin git://git.gnupg.org/gnupg.git (fetch)
origin git://git.gnupg.org/gnupg.git (push)
% git status

On branch master

nothing to commit (working directory clean)
%

I did the pull on the day I filed the bug, and as of the commit stated, the
directory exists. I just did a "git pull", no change. I didn't write "git current"
in this bug.

http://www.gnupg.org/download/cvs_access.en.html still points to the repo above, so
that's what I pulled. If that's no longer correct, I can pull another repo.

But still, if you check out the revision stated, you'll see the behaviour, which is
reflected in current releases of GnuPG.

Kristian has removed the SRV records at _pgpkey-https._tcp.hkps.sks-
keyservers.net, so the explanation in step 3 might seem to not match reality, but
that's a change, because of this Issue and Issue1446.

If you set up your own DNS pool for testing, I'm happy to send you a CSR for a new
vhost to help with debugging.