Thanks for the report. underscore followed by an uppercase letter is actually reserved for the system; thus we should not have used that.

Also might I add, this used to work perfectly fine in gnupg14. It seems that somewhere along the line a regression was introduced that is causing this erroneous non-compliant behavior in the HTTP client.

Why? Your explanation is invalid because it implicates dirmngr's HTTP client as not comforming to the spec laid out by the RFC. I've quite clearly explained--and backed up with the spec itself--that when a proxy variable is configured, a client should not be doing DNS lookup of the destination hostname. Is there something about that you are not understanding?

News for 2.2.14, released 2019-03-19:

Please show an example regarding something else than a failed access to a pool of keyservers. I explained why it can't work for pools for you.

Yes you can, and no you do not. Don't believe me? Then read the spec. At no point does the spec say that there is "nothing that can be done" when a hostname cannot be resolved when connecting through a proxy. In fact, it states precisely the opposite, describing the exact procedure a client should take when making a request through a proxy. See section 5.3, paragraph 3:

We can't replicate that and got no more response for 9 months.

TPK ?
TPS ?

In T4393#123047, @dkg wrote:

i don't understand why "import-drop-uids" is useful --

i don't understand why "import-drop-uids" is useful -- it sounds to me like the functionality you're looking for is something more accurately named "accept-certs-without-uids". is that right?

This is caused by the encoding of file in windows. If we directly redirect the stdout to file, windows encodes the file as CRLF+UCSE LE BOM but linux encodes it as LF+UTF-8. To make the file work, I just need to run dos2unix to convert the encoding. Hope it help someone having similar issue.

Your problem is apparently not an issue of upstream development of GnuPG; It is your setup script (agent.sh?) which specifies /dev/shm/SOMETHING.
Standard GnuPG never does that. We have no idea about use of /dev/shm/SOMETHING.

Thanks for the report. Fix will be in the next release.

In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.

NEWS are:

If you specify a pool of keyservers dirmngr selects a keyserver on its won from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

In your second run you added the options after the argument (4E2C6E8793298290) so they won't have an effect. Anyway, I can't see anything from the output. My way to debug that would be to run gpg under strace:

hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with: