This problem was also reported at https://bugs.kde.org/show_bug.cgi?id=479567#c1

Fixed and backported for VSD 3.3

I'm now using the name "Compliance Check" for the test if no compliance is active/has been configured. I have also checked all other usages of DeVSCompliance::name() in libkleo and kleopatra to make sure it's only used if compliance is active.

I have reverted the commit mentioned by Carl and another text codec related commit for the Qt 5 builds. This will hopefully fix the broken umlauts in the progress messages.

Fixed and backported for VSD 3.3

Looking at the Windows "Problem reports" I saw that it lists many crashes of Kleopatra since 2024-06-19. An older Kleopatra (gpg4win-4.3.2-beta15, built on 2024-04-16) does not crash on exit. The next Kleopatra (gpg4win-4.3.2-beta23, built on 2024-07-05) does crash on exit. The reports point to the libkleo DLL.

Kleopatra shows this option in GnuPG System because gpgconf --list-options gpg-agent lists this option.

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.

Close ticket. We don't need two tickets for collecting group-related tickets.

Remove assignment. Ticket collections are not actionable by a developer.

@TobiasFella prepared the installation in https://dev.gnupg.org/rW9218ebfb7c01478a6fa7b2892fec4d9fd83ba273 . I left some comments on this commit.

Werner backported this to GnuPG 2.2.45.

The last two usages of KIconLoader have been remove in kleopatra master. (libkleo was already good.)

Note that Kleopatra already has clipboard integration via its tray icon, i.e. you can directly sign/encrypt/decrypt/import the clipboard content from there. Unfortunately, it uses a complete different UI for selecting the recipients. Lots of room for improvement/consolidation.

Kleopatra (master; KF6)

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

Kleopatra just checks if the option "default-new-key-adsk" is set (i.e. it doesn't matter if it's an option with scalar value or list value). The other two options that were changed are not used by Kleopatra.

The possibility to drag certificates from Kleopatra to somewhere else has been disabled for Windows builds. The change has also been backported for vsd33. In the vsd33 AppImage it should still be possible to export certificates by dragging them from Kleopatra to, for example, Dolphin. Maybe we still want to remove the vsd33 tag.

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.

In T7322#192972, @ebo wrote:

Which is of course technically correct but why can't we have the much more clear "invalid ADSK ... specified"? I think this would help troubleshooting.

Backported for vsd33

Backported for vsd33