ALright, let's go with that latest version (rKLEOPATRAab32b52a6cf8)

High priority since it affects accessibility and was mentioned as problem in the accessibility reports.

This isn't really important at the moment.

Ctrl+A + Ctrl+C to copy to clipboard and Ctrl+V do paste isn't exactly super complicated for people who know how to use the clipboard. -> Low

We decided that Kleopatra should behave the same way as GnuPG when the user clicks "Wrong". Kleopatra should inform the user that the certificate has been marked as not trusted because of the wrong fingerprint.

As discussed today let's use the following heuristic:

• If we find a certificate for the recipient (sub)key in the key cache (ignoring ADSK subkeys) then list this certificate as recipient.
• Else: If we find a single certificate for the recipient (sub)key in the key cache (including ADSK subkeys) then list this certificate as recipient.
• Else: In a second pass, check if any of the already known recipient certificates has a(n ADSK) subkey matching the unknown recipient (sub)key. In this case list this recipient again (so that formatRecipientsDetails doesn't assume an unknown recipient).
• Else: Count the recipient as unknown.

The option can be enabled/disabled via the GnuPG System configuration in Kleopatra (Private Keys -> Disallow clients to mark keys as "trusted"), i.e. you don't have to edit gpg-agent.conf by hand.

@ebo Thank you for your continuous testing.

Unfortunately, this seems not to have ended the sporadic hangs.
I just saw a hanging initial keylisting with gpg4win-beta-70 which has gpg 2.4.6

Kleopatra (master; KF6)

https://invent.kde.org/pim/kleopatra/-/merge_requests/309

ok, I confirm that this is removed in 4win-beta-70 and update the tags

Kleopatra now asks the same questions as the GnuPG backend. The choices the user can make are a bit different because the user already told Kleopatra that they want to trust (or distrust) a root certificate. Therefore, the first dialog only has "Yes" and "Cancel". And the fingerprint dialog (which is only shown for Trust but not for Distrust) only has "Correct" and "Wrong". Another difference is that in GnuPG clicking "Wrong" makes GnuPG mark the certificate as untrusted (which is a bit surprising). In Kleopatra the certificate is left unchanged if the user selects "Wrong".

If gpg-agent's option "no-allow-mark-trusted" is set then the actions "Trust root certificate" and "Distrust root certificate" won't be available. If the option is set while Kleopatra is running then it needs to be restarted to get rid of the actions. If one tries to use the actions then Kleopatra will tell you that you are not allowed to do this. Similarly one needs to restart Kleopatra to make the action available again after the option was unset.

Fix backported to 2.4

Passing ticket to werner to consider backports.

The new API isn't used anywhere. For now it can only be tested with the test runners. -> setting to resolved

Note for testing:
If the environment variable GNUPG_ASSUME_COMPLIANCE is set to "de-vs" and de-vs compliance is enabled then Kleopatra should show "VS-NfD compliant (beta)" instead of "VS-NfD compliant" everywhere. ("Not VS-NfD compliant" doesn't get the (beta) suffix.)

This is related to T6072: Kleopatra: Display "gpgconf -X"

The fix should probably be backported to gnupg 2.2 and 2.4.

I confirm the fix. Using gnupg master the unit test ran 544 times without any failures or suspiciously long run time.

Good catch, @ikloecker !
I located the bug in GnuPG, and the fix is: rG71840b57f486: common: Fix a race condition in creating socketdir.

I found one reason for the intermittently failing concurrent initial keylisting. gpgsm sometimes uses the wrong socket file to (try to) connect to gpg-agent.

I can reproduce this with gnupg 2.2.45-beta27 (STABLE-BRANCH-2-2 69a8aefa) on openSUSE Tumbleweed.

systemd based Linux?

I have reproduced this with libkleo from our gpg4win/24.05 branch and with gpg (GnuPG) 2.4.6-beta102 (HEAD of STABLE-BRANCH-2-4) and current master of gpgme and all GnuPG libraries. It took just 8 runs until a unittest failed.

gpgme logs for a failed test where the keylisting with gpgsm failed

If the keylisting (of OpenPGP and S/MIME certificates; technically, that's two independent keylistings) fails without giving any results then it makes sense to show a error message instead of the welcome page.