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.