I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Oof. That hinges on the certificate, guess we'll need to renew the bunch of them. I reconfigured, might take a while for all pages but ciphers should now be:

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

In the above test, I was using
Windows: 2.3.4
Debian: 2.2.12

I captured some logs server-side, and I do see this error:

Are you using 2.3.4 also on Windows?

I have the same error when using wkd.keys.openpgp.org with a CNAME DNS entry. The error occurs with Windows 10, 11 and Server 2019 (only the most recent versions tested). With Debian it works fine.

see rC67b36154f88e for master.

Will add it. The reason I added Brainpool was due to a question on the performacne between Brainpool and other NIST.

Not applying the change to GnuPG 2.2, users can use GnuPG 2.3 for that.

Done in 1.10.1.

Good idea. Thanks. Goes onto 2.3 and 2.2

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.

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.

Confirmed to work, thanks!

Thank you. Applied.

Thank you for the error output.

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

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

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.

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.

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.)

Adding

GPG_TTY=$(tty)
export GPG_TTY

makes this working so thank you for the pointer.

{F3381469}I uploaded the whole homedir containing the keys after they were migrated by the new gnupg2.3.4. It should have all of the keys in there. Don't worry, these keys are just for testing and not used anywhere.

Is your GPG_TTY set so that pinentry can find the right tty?

the -v does not show more useful info on the gpg side:

# gpg2 --quick-gen-key admin
About to create a key for:
    "admin"

Please run with option -v to see what's wrong with pinentry.

I had some more time to test this bug.

There is a new key filter "Not certified certificates" that is selected if the button is pressed.

I can't replicate this symptom when I use gnupg1 for creating keys with no passphrase.

Yes, makes more sense to me, too. Maybe another filter "bad" certificates, so that you can bulk delete them for example to clean up your keyring?

@aheinecke What do you think?