https://invent.kde.org/pim/messagelib/-/commit/f8373bc09b228cc88577ec88b285c58a06122575

Test with Wine (i686) emulation, I encountered another hang at: Checking armored_key_8192

It looks like having the datastream_thread may be not worth.
One possibility is to implement synchronous read from pipe in kbx_client_data_wait, instead of datastream_thread.

Notes for testing:

• First certificates and groups are sorted by their "display name" (i.e. the part of the displayed text before the parenthesis with the other properties).
• Groups are sorted before certificates if both have the same "display name".
• Groups with identical name are sorted by their internal ID. (Probably doesn't make much sense to test this.)
• Certificates with identical "display name" are sorted by validity, then by creation of newest valid subkey, and finally by fingerprint.

Works good enough for me

I agree, but can't give this priority because it is more work then it sounds since we need to start from the bottom with dirmngr feedback and then pass this all the way through our layers to kleo.

As ingo pointed out in the main issue, just using an "inactive" color for the validity might be confusing / inacessible.

When testing please note that the last changes (i.e. "Ignore expired subkeys when looking for newest subkey" and ""Sort by fingerprint as last resort for deterministic sort order") have not been merged to the gpg4win/3.1.27 branch.

I have set T6513: Kleopatra: Require GpgME 1.21 as blocker for this issue because, in my opinion, showing the above mentioned "Operation fully cancelled" error message is from a user perspective worse than showing multiple password prompts.

Fixed.

They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.

Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:

My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.

See also commit rG6fcc263c18 from 2020 where I switched to D-lines.

The problem of hang of tests/openpgp/multisig.scm is solved by rGef4f22b9d98b: gpg: Graceful exit for signature checking with --batch.
But the problem itself is not yet solved.

It is reproducible by testing tests/openpgp/multisig.scm with keyboxd enabled (it hangs), with the modification of following.

The following works, too:

Setting close_button when the user rejected the pin entry (by pressing the close button, the Cancel button or Esc) causes fully canceled. Unfortunately, Kleopatra (and in fact GpgME::Error) has no idea that fully canceled should be treated as canceled and not as error. Therefore, Kleopatra shows an ugly error message:

An error occurred while trying to change the passphrase for [...]:
Operation fully cancelled

The output folder is now checked with enabled NTFS permissions check for writability. Hopefully, this fixes the problem on Windows.

Kleopatra explicitly checks if the output folder is writable using QFileInfo::isWritable. But: QFileInfo::isWritable mentions that NTFS permissions are not checked unless this is enabled explicitly (because it's an expensive operation). I'll try to enable it locally for the check.