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.

Thanks for the report. Log looks not unusual.

I think that this might have the same underlying reason as the fixed T4321 (still open because it was not yet released).

Just for history if I ever need it again here is a patch I wrote debugging QIODeviceDataprovider. I have not commited it for fear of regressions and apparently the code is correct for Linux and that it did not work as expected on Windows had other reasons.

The secret import code actually had a bug in that it silently imported the secret key anyway, so that after importing the public key the secret key showed up. That was not intended because we do not want to allow importing arbitrary keys or subkeys if the don't have a corresponding public (sub)key with the mandatory key-binding signature. This has now been fixed. A fix for the actual problem will come soon.

Additionally that workaround is a bad idea because on closing Outlook it
leads to the GPG4Win error "Not all plain text could be removed, it's
possible that plain text from decrypted mails was transferred to your
server." (roughly remembered text-wise)

Thanks.

After further debugging it showed that it had to be an issue in how we use QProcess. So I've rewritten the way we call gpgtar on Windows and replaced it with a simple anonymous pipe solution. I've tested more then ten times with various directories that the data corruption no longer occurs.
The performance is slightly better, but we still use GPGME so it's not as good as if we would pipe it directly. But not using GPGME was not really an option because otherwise I would have had to implement a full blown "how to call gpg" with error handling etc. for Kleopatra and I really did not want that.

The issue for the quality indication is: T2103

In T4346#122371, @gouttegd wrote:

Regarding the quality evaluation, several months ago I proposed to optionally delegate that task to an external tool (specified by a new gpg-agent option passphrase-checker). I posted a first draft as D442 and then submitted a proper patchset to gnupg-devel, but although @werner expressed interest it was never merged. I have just checked that the patchset still applies cleanly to both the master branch and the STABLE-BRANCH-2-2. I can re-submit it to the mailing list if needed.

FWIW I like @gouttegd 's patchset.

In T4346#122098, @werner wrote:

The quality bar is switched off by default. That feature including the quality was ordered and accepted by a client. I don't like it either and thus the new default of having it disabled is a useful solution.

There is a solution for it:

well, Firefox DE on OSX gives same error Unhandled Exception ("HTTPFutureHTTPResponseStatus")

Hi there,