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

In T6356#167325, @gniibe wrote:

The interaction goes back to "Your decision?" after you didn't answer "y/N" to the question of "Do you really...?".
What you are asked is: 1, 2, 3, 4, 5 or m.

The interaction goes back to "Your decision?" after you didn't answer "y/N" to the question of "Do you really...?".
What you are asked is: 1, 2, 3, 4, 5 or m.

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,

I edited this task a bit: For compression we have T6332
For Archives passed to Gpgtar we have: T6342

Some technical points:

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.

There is another issue about the performance of Kleopatra when encrypting large archive files

I see no reason to force a certain order of actions on the users, i.e. first they have to certify a certificate and only then they can give this certificate certification power.