The Display of trust in a certificate is insufficient in Kleoptra. It seems that it doesn't matter wich trust state (except for "not trusted") a certificate has or gains, it always will be shown in the tab "trusted certificate". Reproducible: Always Steps to Reproduce: 1. Create 3 Keypairs (Frank, Lisa & Bart) 2. Export Barts Public Key 3. Delete Barts Keypair 4. Import Barts Public Key 5. Sign Barts Key with Lisas ID 6. Export Lisas Public Key 7. Delete Lisas Keypair 8. Import Lisas Public Key 9. Sign Lisas Key with Franks ID 10. Set Lisas Trustlevel to "marginal" Actual Results: Now all certificates are shown in the Tab "Trusted Certificates". Expected Results: Only Franks and Lisas should be shown in the Tab "Trusted Certificates". Franks, because its an Identity you created by yourself and Lisas because its signed with Franks key. But Barts identity should not show up here, because the trustlevel in this certificate is set through Lisas signing, which is just trusted on level "marginal".
I'm not sure how to handle marginal trust in the UI. Is marginal trust really something we should warn about? I think we need to have this information available for the advanced user and generally treat marginal keys as "ok". E.g. in the trusted certificates group there is some trust there and trusted certificates does not say "Fully trusted certificates ;-) " I think it is more important to highlight the case where there is no indication that the key belongs to the UID. With Tofu this is important because TOFU will return marginal trust with a sub validity: Values for VALIDITY are: - 0 :: conflict - 1 :: key without history - 2 :: key with too little history - 3 :: key with enough history for basic trust - 4 :: key with a lot of history I think generally we should stick with the three levels "Green, Yellow and Red" and make further information available in details and for advanced users. Here I would say that after a validity of 2 we switch to "green". For "Encrypting to this certificate" and in some overall "UID validity status indicator" and "yellow" (or whatever gnupg tells us to do, when verifying signatures). Here is what I'm currently proposing to use for the Indicator for Opportunistic Encryption in KMail: https://phabricator.kde.org/differential/changeset/?ref=34677 (And what I plan to reuse in Kleopatra for recipient selection) Pretty unsure about this though.
Hi Andre, to me this is a clear defect in the current gui. The gui aims to be for power users (aka Bob and Annika in https://wiki.gnupg.org/EasyGpg2016/VisionAndStories ). And the GUI claims to help you manage the Web of Trust, which some power users still want to do. In the Web of Trust (and some other trust context) a trusted certificate comes with a strong indication that it belongs to the userid and is a base for trusting other certificates. A certificate that is marginally trusted should not fall in this category, at least it is missleading. The certificate in questions falls in the category "some trust" and when in doubt this meant: not enough trust. If a user starts to understand the WoT implementation of GnuPG, she will be surprised by the different behaviour of the kleopatra display and the GnuPG backend. If there is an easy fix, it probably should also be done on older product lines as long as they are still in usage. Best, Bernhard
The proper fix here would be to use the trust levels that we use in GpgOL throughout Kleopatra and KMail (libkleo) https://wiki.gnupg.org/AutomatedEncryption#Trust_Levels There is already some work on this done in libkleo as I would like to move it also there. (GpgOL also uses libkleo for GUI Elements). We had an issue in phabricator for KMail to do this but never gotten around to it. I hope to do some more work on this later this year to have KMail use the same keyresolver dialog from Libkleo that GpgOL uses.