Thanks for the report. underscore followed by an uppercase letter is actually reserved for the system; thus we should not have used that.
Tue, Mar 19
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.
Mon, Mar 18
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.
Thu, Mar 7
Wed, Mar 6
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?
Feb 23 2019
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.
Feb 19 2019
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.
Feb 15 2019
Feb 12 2019
Jan 24 2019
Jan 23 2019
Jan 22 2019
Thanks for the report. Fix will be in the next release.
Jan 11 2019
Dec 17 2018
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.
Dec 15 2018
Dec 14 2018
Dec 13 2018
Dec 12 2018
Dec 11 2018
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:
Nov 19 2018
Nov 18 2018
hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with: