Thanks. please give a few days.

Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put

Although gpg-agent launching is protected by a file system lock, there is indeed a small race related to the pinentry. The invocation of the pinentries is serialized but if a second pinentry is requested while the first pinentry has not yet returned and put the passphrase into the cache, the second pinentry will be called anyway. Fixing this not easy and should rarely be a problem. The mitigation is to do a dummy decryption to seed the cache or use a custom pinentry.

I guess this is the first time such a key was reported. Printing diagnostics would be a bit of work because the code to compute th. expiration time is deep in gpg's guts.

Here is the output of gpg --full-timestrings --check-sigs:

pub   rsa3072 2019-05-09 12:08:21 [C] [expired: 2022-05-05 12:08:21]
      ABC96B3B4BAFB57DC45D81B56A48221A903A158B
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
uid           [ expired] Linda Mary Patricia Deborah Barbara Susan Maria Nancy <linda@example.org>
sig!3        6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
sub   rsa3072 2019-05-09 12:08:21 [E] [expired: 2022-05-05 12:08:21]
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
sub   rsa3072 2019-05-09 12:08:21 [S] [expired: 2022-05-05 12:08:21]
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]

Indeed. The called function dates back to 2004. We really need to rework this and cache the value - it might be required to take the file_name into account.

I had the same suspicion andIchecked the code. afaics all values are taken from a cache (see dirinfo.c). Thus no real overhead.

If you got a limited list of, say, fingerprints, you should put them into an array and use gpgme_op_keylist_ext_start tolist only those keys. This will be much faster.

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

These are USTAR types:

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.

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.

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?

With 2.4.1 you will get a runtime error

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

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

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.

Can you please provide the output of

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.

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

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

See the the commit for a description of the changes.

Thanks. I fixed the documentation. Will go into 1.19

I guess we need some gpgme support as well.

How with --status-fd passed to gpgtar we will get these progress lines:

What I need in particular is a way to get the output of gpgconf -X.

Those "curated keyrings" and keyservers don't work together. The whole idea of automated but curated keyrings is dead end.

To fix this we also need to fix our key selection test (key-selection.scm) which is can't cope with all combinations. The tests are run with a faked time of 2004-01-01 on all subsets of this ordered list of keys

See also T4713

Let's first collect all keys, assign a priority, sort, and only then send them back to ssh.

Well, I do not yet see a use case for this. The current rush towards PQC makes it unlikely that newer curves will get in widespread use. Iff we have a large application which requires this curves, we can reconsider,

There are two issues here:

1. The overhead due to QT based processing.
2. The compression takes long and gpg used to had no way to detected already cmpressed data when the data was piped to gpg (as Kleopatra) does. See T6332.

The introduction of --override-compliance-check actually hid the real
cause for the signature verification problem in de-vs mode for the
Ed25519 key. The real fix is to handle the EdDSA algorithm in
gnupg_pk_is_allowed.