I see two possible solutions.

Good catch. The translation of the option descriptions is done as part of the option parser (libgpg-error/src/argparse.c) and thus we need to have gettext support over there. Also for some other error messages.

Seems to work if NLS support is enabled. Updating in https://github.com/Homebrew/homebrew-core/pull/122706. Once merged, users will need to brew reinstall libgpg-error (Homebrew has decided to avoid forcing updates to all users outside of critical fixes).

Probably due to libgpg-error being built without NLS support on macOS as formula currently doesn't have gettext dependency. On Linux, libintl is provided by glibc so doesn't need any extra dependencies.

This is the formula: https://github.com/Homebrew/homebrew-core/blob/c26f1c8714c231ee6796915f033ba229c89af3d6/Formula/gnupg.rb

Gpg4win 4.1.0 comes a slighly newer gpgol which should be tried before we continue. Set to low prioprity because this seems not to be easily reproducible.

I have no idea about Homebrew - can you figure out the maintainer and point him to here?

Nobody stops you from removing any unwanted keys from the keyring. Nobody stops you from importing all keys to a temporary keyring (using a temporary GNUPGHOME), export only those keys you want in your proper keyring, import those in your proper keyring, and then ditch the temporary keyring (resp. GNUPGHOME). gpg doesn't stop you from doing any of this.

With 2.4.1 you will get a runtime error

sendmail tool '%s' is not correctly installed\n

Sorry, I mistakenly closed this task. I reopen it.

Well, I think it's a matter of taste what keys a user wants to have in which keyring. Some users want only the keys they actually use.
I think policy or the algorithm should not take the decision away from the user. "Free software for unfree users" doesn't make much sense. Maybe I'm just so old that I still think the computer should do what the user wants it to do, and not the other way around (which seems to be a current trend).

It does not matter what you have in you keyring. It does not harm to have arbitrary keys there.

This is the Homebrew build. Maybe something not included in the recipe?

No idea what happens. I can't replicate that on a Linux box using GNU gettext and neither in Windows using gnupg's own gettext implementation. It seems that strings without any line feed don't get translated.

Thanks. Looks pretty standard. I will have a closer look.

Could it be the case that your implementation actually used those bits to calculate a public key?

gpgconf -L:

sysconfdir:/usr/local/etc/gnupg
bindir:/usr/local/Cellar/gnupg/2.4.0/bin
libexecdir:/usr/local/Cellar/gnupg/2.4.0/libexec
libdir:/usr/local/Cellar/gnupg/2.4.0/lib/gnupg
datadir:/usr/local/Cellar/gnupg/2.4.0/share/gnupg
localedir:/usr/local/Cellar/gnupg/2.4.0/share/locale
socketdir:/Users/emirsari/.gnupg
dirmngr-socket:/Users/emirsari/.gnupg/S.dirmngr
keyboxd-socket:/Users/emirsari/.gnupg/S.keyboxd
agent-ssh-socket:/Users/emirsari/.gnupg/S.gpg-agent.ssh
agent-extra-socket:/Users/emirsari/.gnupg/S.gpg-agent.extra
agent-browser-socket:/Users/emirsari/.gnupg/S.gpg-agent.browser
agent-socket:/Users/emirsari/.gnupg/S.gpg-agent
homedir:/Users/emirsari/.gnupg

Can you please provide the output of

For a device which only provides PKCS#11 driver, I decide to test with SoftHSM.

Sorry for a bit late follow up. How do you calculate a public key? RNP's crypto backend, Botan, is calculating public key without taking in account bits which should be tweaked. I.e. both tweaked and non-tweaked secret keys would produce the same public key. The same is with decryption. Could it be the case that your implementation actually used those bits to calculate a public key?

Frankly, I don't understand the problem. Without the pinetry-program option you have a ./configure option to set the name of the pinentry. If you don't use that gpg-agent looks for $bindir/pinentry and if not found for $bindir/pinentry-basic.

In rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed#76889, @sandro wrote:

The profiles are not any longer useful because global options are way more powerful (/etc/gnupg/gpg.conf et al.).

How are distros supposed to set a value for pinentry-program now? gpg-agent only looks for the config in the user directory and fails to find pinentry if it is not in PATH.

I was asking because the question came up on NixOS and how we handle this, for us, breaking change.
We don't have a global PATH we could necessarily symlink into but a wrapper could work. NixOS also does not use the alternatives system at all because it wouldn't work well with the distro design.

Use a symlink or the alternatives systems. The --pinentry-program option was introduced for debugging.

The profiles are not any longer useful because global options are way more powerful (/etc/gnupg/gpg.conf et al.).

The gpgme part has been done. Some minor changes in Kleopatra regarding the VERSION file checking would be useful.

As discussed with Werner, the initial default will be changed "guessed" in GPGME to avoid code duplication between libkleo and GPGME.

See the the commit for a description of the changes.

Current status:

• Gnuk Token, Yubikey, OpenPGPcard with some card readers (only w/ specific reliable card readers)
• some cards some card readers (many are not supported well)
• TPM

@MathiasMagnus This change is to support Win32-OpenSSH by gpg-agent emulation of ssh-agent; You can use gpg-agent emulation of ssh-agent when you use Win32-OpenSSH. That is, you can use GPG auth subkey for Win32-OpenSSH.

If you want this to happen, then you should consider contributing a patch. Please see doc/HACKING for the formal requirements.