bug has been closed as Wontfix [..] I see no reason to continue the discussion in the bugtracker.

Can confirm this problem still exists in version 3.1.16. The context menu in Windows Explorer and some menu entries in Kleopatra are in the wrong language, while most of the application is in the correct language. This looks very messy.
Gpg4win and Kleopatra should not look at the date/format locale settings for the language, but at the actual Windows display language.

This bug has been closed as Wontfix more than a year ago. I see no reason to continue the discussion in the bugtracker.

Well, the keys are not generated but public keys are imported. @gniibe's key has meanwhile expired but we keep it because it will allow users to verify some older source packages. An expired signature key is not an error but merely means that one should evaluate the meaning of the signature with more diligence.

I share your concerns about centralization of keyserver infrastructure. Rejecting this security fix doesn't help keep keyservers decentralized, though.

As a start, I applied your patches.

It is now over 10 months that the proponents of these additions have not followed up on the discussion.

Works for a long time now (unless we broke it again;-)

dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.

To extend on this: dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems. On Windows we could make it work because DLLs on that platform are well designed and not a hack like the Unix shared objects.

We really want thunderbird users that interact with GPGME to have a great and stable user experience, but the problem with dynamic loading and self compiled versions is that we cannot really know the build settings and enviornment and it is very time consuming to reproduce that. GPGME does some very low level things for optimized IPC that can depend on build options etc. This is why I am mostly in favor that thunderbird ships a defined version that we can debug and see the settings.

Reading the mozilla entry more carefully, there still seems to be an issue.

https://blog.gerv.net/2012/01/mozilla-projects-and-gpled-code/

@kaie, thanks for the pointer!

In T5250#148131, @bernhard wrote:

BTW @kaie

Thunderbird cannot use anything requiring GPL in its default configuration, because Thunderbird wants to distribute a single MPL licensed package that includes all components that are required for OpenPGP.

Any pointer why, they have made that choice, though? A bundle of MPL and GNU GPL components is fully allowed by the licenses as far as I know.

Sorry, I don't understand what you are trying to say, so let me give you some more detail.

@aheinecke Please test this on Windows

Huh, can't believe I somehow missed that this actually got a reply three years ago...

Everything in ~/.gnupg is and has always been private to gnupg unless explicitly stated otherwise.

Last week:

• FIPS 140 support of libgcrypt
  • The interpretation: PCT (pairwise consistency test) for RSA/DSA/ECDSA requires hash+sign
    • Not sure if this is true
• If it is true, _sign_md would not be needed
• Adding enhancement to gcry_pk_sign
  • T5529: Support internal hashing for RSA-PSS
  • T5530: Add "prehash" support to DSA and ECDSA signing
• Fix a race in scdaemon: T5524

For many years I was convinced that my secret keys are stored in an encrypted folder. The .keyring file was there, everything looked correct...

Using GPGME is probably the best way, even if gpgme-json might also work for some operations.

It's worth noting that this issue is particularly impactful for devices with small screens whose sizes cannot be changed. A Raspberry Pi with an Adafruit touchscreen would almost certainly have issues, for example.
This also applies to mobile devices. For context, I use Termux on my Android phone, and this issue manifests there. I can enter the passphrase for an existing key and decrypt/sign with it, but any attempt to create a new key throws me into the same loop that the OP describes. (Interestingly, this happens whether or not I actually supply a new passphrase.)
Since I am on a mobile device in this scenario, my terminal dimensions are 56x115. I'm not familiar with the implementation details of GPG, but is there any chance we could fall back to a single-line, sudo-style password prompt if pinentry fails (or have pinentry fall back to that internally if the normal mode fails)? That should work on terminals of just about any size.
(As an additional note, I've also tried flipping into landscape orientation, hoping that would increase my screen width sufficiently. However, my keyboard then occupies most of the screen, and I receive the expected error message, gpg: agent_genkey failed: Screen or window too small.)

Implemented for X11 and Windows.

ok i found it just add "trust-model always" in gpg.conf