we have a similar problem in our organization. We're using Outlook from Office 365. For two weeks now we have set a GPO for Outlook to prefer plain text messages like in @kimmoal's organization environment.
This causes the same problem: We are getting blank emails when they are encrypted or signed.

When we will find reproducible test case, please reopen.

Use a gpg 2.3 version:

Hi Werner
.
Firstly, let me say how much I appreciate the work you and others do at OpenPG.org! Really.

• No we can't because current GnuPG 2.2 versions are able to decrypt such AEAD data.

See also T5537 and commit rG7d1215cb9cba2 for 2.2.

There is actually a much easier fix here. Thanks for pointing out the problem. For histroical reasons we have several places where we create the homedir.

1. So, firstly, can we get an error message that states something to that effect AND can also be displayed by Mutt?

Confirmed to work, thanks!

Thank you. Applied.

Implemented.

Thank you for the error output.

it still shows the no certificate or invalid encoded error message:

Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.

Since decryption is broken, I'm raising the priority level of this ticket.
It would be wonderful if someone can take a more detailed look into this problem. :)

Indeed, different versions of MinGW use different symbols to guard the declaration, and using those symbols in not future-proof enough, IME.
Removing the declaration is definitely the best solution.

I gave it a try. It works now, but it still shows the no certificate or invalid encoded error message:

And I move functions from pinentry.c to pinentry-curses.c, so that pinentry-w32.exe can be build with no libiconv (which is actually not used).

Thank you for your report.

Merged into T5804.

Thank you. Confirmed.

Thank you for the reproducible test case. Confirmed.

Pushed the change removing the definition.

GetNativeSystemInfo. Would you like me to submit a patch that used that in jent_ncpu?

Sorry, HOME and ~/ are not standard on Windows and applying your patch may break existing installations.

Yes, I see the problem:

In T5889#156302, @gniibe wrote:

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Thank you. Confirmed.

Thank you.

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Thank you. I understand the situation by looking at mingwrt-5.4.2-mingw32-src.tar.xz.

In libgcrypt (1.10), we have a copy of the jitterentropy 3.3.0 from:
http://www.chronox.de/jent.html
or https://github.com/smuellerDD/jitterentropy-library

Please refer to the open Mutt Bug issue 401 below regarding the troubleshooting we've performed which seems to suggest there *might* be something a skew on the gpg binaries.

Let me ask a more specific question, since you mentioned "support of detecting numbers of CPU and having more than 1 CPUs": can you point me to the code which detects the number of CPUs on MS-Windows systems, where I could learn how that code is affected by having EOPNOTSUPP defined? I will then hopefully understand better what you are saying, and either agree with you that this is unworkable on Windows, or propose a better solution.

I guess I don't understand what you mean by "native building". This build was with MinGW, which is as "native" as MinGW64 is.
The reason for the problem is (AFAIU) that MinGW64 went after Microsoft's change in stat due to the 32-bit vs 64-bit time and off_t values issue.s That change breaks backward compatibility in more than one way: programs compiled on some versions of Windows will not run on other versions. mingw.org's MinGW kept the original semantics and symbols, which is why _stat32 exists in the mingw.org's headers, but is not exposed by default.

Can you please tell more about how this causes non-working code? MinGW64 defines EOPNOTSUPP to an arbitrary constant which (AFAICT) is never actually returned or used in the MS-Windows runtime. Their documentation, in https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170, says:

This is with mingw.org's MinGW, version 5.4.x.

The version of MinGW is 5.4.x, the latest one. It is available from https://osdn.net/projects/mingw/releases.
MinGW64 is a fork of the above (original) MinGW. They have unfortunately diverged, thus the need to have these changes.

Turned into a feature request because native building on Windows is not supported.

I had thought that we need to combine hkdf so that key and iv can generate within libgcrypt internally.
Probably, this assumption of mine may be wrong.

The original plan was to source copy dns.c from upstream and thus we tried to avoid any changes. Unfortunately we never achieved to push things upstream and thus our own changes got it. Eventually we will cleanup the code and use our own framework.

Thank you. Confirmed and applied.

Thank you for your report.

Please specify your MinGW version.

Please specify the version of MinGW, which you are using. (We use Mingw-w64 for GnuPG Project.)

Using an armor header would allow for this. But well, this blows up the data and frankly, I fear that it can lead to unexpected side effects. Better to use a respective file name or MIME header.