See also
https://lists.gnupg.org/pipermail/gnupg-devel/2018-December/034131.html
for a first patch to implement this.

werner wrote:

Great. Thank you.

Thanks for the confirmation. Although I still don't really know how to fix it :-(

We are aiming for this week.

When will the new gnupg program be released so I can install it?

Charles

I can also confirm this bug!

There are reasons why we sometimes don't consult the return code. That is even declared in the code with a cast to void. Further we use gpg_error_t and int interchangeable under the assumption that an unsigned int and an int value have the same bit pattern.

Maybe we should get rid of the _Pragma operator in particular because it is not used often and we cond on compiler type later anyway.

Will you be so kind and look into this?

Thanks.

Applied to master. This is not suitable for 1.8

BTW, for looking at such hexdumps I use this little tool:

for whatever reason, i don't seem to be able to push to the branch on playfair, so i've also pushed the same commit over at https://gitlab.com/dkg/libgcrypt

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?

So where can I get the corrected file to install? I suppose I need the
new gpg4win, it hasn't been updated yet. If I need the signature or TAR
from your website how can I implement that?

Charles

@dkg If you propose a patch here I'm pretty sure that we will accept it. As one of our Python binding users you know better then us how the API should behave.

see: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

This is very strange, common to all the crashes in the log is that they happen while a keylisting is running and before the first key from that keylisting is returned. But this could be a red herring because the keylisting is always started immediately in a background thread and so it would be normal that if the crash occurs immediately that it would still be running. The keylisting code is extremely similar to Kleopatra though. So I don't understand why Kleopatra would then work for you.

News for 2.2.14, released 2019-03-19:

Where can I get the new thing file to install?

Thanks! I've confirmed that it works for me.

Running
valgrind --leak-check=full ./g10/gpg --import clusterfuzz-testcase-minimized-fuzz_import-5751600352591872.dms
gave me at commit f799e9728bcadb3d4148a47848c78c5647860ea4

==11882== 232 (16 direct, 216 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 333
==11882==    at 0x1001C32C5: malloc (vg_replace_malloc.c:302)
==11882==    by 0x100B211B9: do_malloc (in /usr/local/Cellar/libgcrypt/1.8.3/lib/libgcrypt.20.dylib)
==11882==    by 0x100B214D5: _gcry_xmalloc (in /usr/local/Cellar/libgcrypt/1.8.3/lib/libgcrypt.20.dylib)
==11882==    by 0x100058A1D: read_block (import.c:929)
==11882==    by 0x10005B772: import (import.c:584)
==11882==    by 0x1000597FF: import_keys_internal (import.c:486)
==11882==    by 0x1000596FE: import_keys (import.c:526)
==11882==    by 0x10000727B: main (gpg.c:4675)

Thanks. Actually the same as arm7-unknown-linux-gnueabihf. I have added it to the alias table to be released with 1.36.

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.

This file is readable. You must have changed the former one's visibility so that only you can view it.

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:

Ok, I will wait longer next time.
How do I make the file accessible ? (I can download it)

No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.

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

That was an intermediate commit on master - it is likely that there are memory leaks.
Moving the test around is not a solution. BTW {F630817} is not accessible.

Since I configured call tracing the running O365 Client dies immediately after activating the addin. Same happens now if I activate the addin.
Anyways, here is the log.