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?

You could verify this with another email address containing a +.

How can I check this, @ikloecker ?

Can you check whether the + character in the email addresses is causing this?

I can't replicate this symptom (gpg1 generated key, no problem after migration).
Could you share the *.key file under private-keys-v1.d?

I think that this commit rG8fd150b05b74: gpg: Remove all support for v3 keys and always create v4-signatures. matters.

Thanks for you patches. Most of them applied cleanly despite that I delayed processing them for half a year.

@mieth sorry for the delay. meanwhile I adjusted the ciphersuite of the WKD gateway to include an AES-CBC suite. would be interested if it works now on the setup you tested before.

Reagarding the OpenPGP specs: there is a new draft with LOTS of changes to already agreed upon formats and conducted interop tests. Almost everything we implemented in GnuPG and RNP has had rough consensus in the WG. Minor things like AEAD chunk size were the contested pieces. However, now they want to change everything with the possible outcome of discretization the long established trust in the stability and durability of the PGP data and key format.

Great, thank you very much!

Thanks for notifying. Will be fixed in the next release (mid Apri).

Sorry. While v5 things in the specification is still in flux, from the viewpoint of the implementation, this patch is 100% valid and it makes sense.

Thank you for the report.

The mails from these days still contain the following header:

List-Post: <mailto:gnupg-devel@lists.gnupg.org>

which is probably causing the mail client directing the mails to this address. Is there a way to change or or make it an alias so it is easier for people to use the mailing list without finding this issue?

Should be fixed.

The patch for T5834 (https://dev.gnupg.org/rMad3aabdd8a64156c7e3a75d695ae1ab2c4bec841) was already applied to the build of GPGME 1.17.0 for Focal, as I did browse the list of latest GPGME bugs first before reporting this bug. Attempting to build with the latest GPGME 1.17.1 (with the included ABI patch) results in exactly the same FTBFS for i386 only, so this does appear to be a distinct issue not related to that of ABI backwards compatibility.

Please see T5834 which is fixed in 1.17.1

Fixed in 1.17.1

Fixed.

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

I'm not sure. In KeyResolverCore::Private::resolve() line 668 reads

const bool pgpOnly = (!mEncrypt || !hasUnresolvedRecipients(mEncKeys, OpenPGP)) && (!mSign || mSigKeys.contains(OpenPGP));

I'd say this is supposed to check if there is an OpenPGP signing key, but I guess mSigKeys[OpenPGP] is an empty list. This may be a regression introduced by the resultion of key groups because in KeyResolverCore::Private::resolveSigningGroups() the entry mSigKeys[OpenPGP] is always set (unless we are in CMS-only mode).

Yes, unit tests still pass. So its ok with you to commit this?

Sounds familiar, that the signing keys are not considered. I think when I worked on this, I thought that is was a bad idea to mix resolving signing and encryption keys. Do the unit tests still pass with your change?

@ikloecker
If I test the resolver code from libkleo with gpg4win-tools keyresolver binary:

pinentry-qt with new icon:

I will add a suitable icon from the Breeze style.

Closing this task since the original feature request is still in the QA queue.

I tend to agree