"file type 2" may refer to symbolic links.

I did some tests. I encrypted the g10/src folder which contains multiple repos (33098 files) with a total weight of about 1.4 GiB.

I made the condition for calling the verify handler more strict by checking if err is a NO DATA error. This should minimize the risk of regression.

This did

AllowSetForegroundWindow(pid == -1 ? ASFW_ANY : pid);

on Windows.

I try experiment using Python PKCS#11 (https://python-pkcs11.readthedocs.io/en/latest/index.html)

• with SoftHSM https://github.com/opendnssec/SoftHSMv2
• with Scute

I concluded that (at first, for the initial try) it's not good to start this under scdaemon, because of two different abstractions for accessing the device (the way of scdaemon and the way of PKCS#11).
It's good to start with something like tpm2d. The goal would be integration into scdaemon or tpm2d.

I have some doubts that signed-only archives are very useful. The only use case is that this allows to sign stuff without saving it first. You would need to do this in my generally preferred detach signature case.

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