Use key trust levels to use indicate how much the signature can be trusted.
Diff Detail
Diff Detail
- Repository
- R94 PIM: Message Library
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 16451 Build 16469: arc lint + arc unit
| messageviewer/src/messagepartthemes/default/defaultrenderer.cpp | ||
|---|---|---|
| 1008 | well if it is unknon we should better use Tofu, this is for sure better than Unknown. | |
| 1187 | here you have to support the same logic as above, if tofu < GpgME::TofuInfo::LittleHistory than keyTrust. | |
| mimetreeparser/src/viewer/messagepart.cpp | ||
| 732 ↗ | (On Diff #8341) | Not good to have this in commited code except from tests, plase replace this with a qError or anything, that would allow a running program not to crash. |
| 865 ↗ | (On Diff #8341) | this variable is only set (l919,l933) but never read? So this can be deleted? |
| 889 ↗ | (On Diff #8341) | and what about Validity::Unknown? |
| 920 ↗ | (On Diff #8341) | this is a little bit strage, to read a number here and not anything from gpgme, does that means, that gpg do not give hints, when a key is trust worthy? why is 10 a good number? Is there any discussion about this threshold? |
Comment Actions
Last week we had a meeting in our Team and with the customer and afterwards a gnupg-developer meeting where we discussed how TOFU should be implemented in MUA's. I've used my TOFU Support in GpgOL to demo this and after discussion there were some good points raised. We agreed that I'll write an updated draft how I am planning to use TOFU in GpgOL and how we are planning to use it In KMail and then do another round of discussion so that this can be an "implementors" guide for TOFU usage. As we also want to get it into enigmail etc.
I'll ping in this issue once I've done that. I plan to do it this week.
| messageviewer/src/messagepartthemes/default/defaultrenderer.cpp | ||
|---|---|---|
| 1008 | I trust model TOFU a key is only Unkown if there were no messages seen from this key. The first signature check already results in Marginal. | |
| mimetreeparser/src/viewer/messagepart.cpp | ||
| 889 ↗ | (On Diff #8341) | From the first message on TOFU switches validity to marginal. Unkown + TOFU Info is only reached if the user set the key explicitly to policy "Unknown" which is then handled by the default "Unknown" handling. |
| 920 ↗ | (On Diff #8341) | 10 is the old value for tofuinfo.validity "Basic History". GnuPG changed "Basic History" to include the encryption count. This may make sense for the command line usecase (although I disagree about that, too) but it does not for MUAs. I've discussed this at length with the implementor of the TOFU Support in GnuPG and we agreed that different use cases may use the signcount / enccount differently and gnupg's "TOFU" validity is only a hint. But it's a good point, the discussion should have been on a mailing list (we discussed over phone / or in person) and the rationale for this outlined somewhere. |
Comment Actions
Sorry still no new concept yet. I've updated my draft but it's still under too much discussion for me to say that this will be what we should implement.
Comment Actions
Overall the patch seems fine, but a unittest is missing. And it should surly be tested before we merge it into master, I can do this after the patch is rebased on master.
| mimetreeparser/src/CMakeLists.txt | ||
|---|---|---|
| 11 | remove this. | |
| 170 | just add Libkleo dependency to the normal dependency list. | |
| mimetreeparser/src/config.h.cmake | ||
| 1 ↗ | (On Diff #12427) | remove file |
| mimetreeparser/src/viewer/messagepart.cpp | ||
| 31 ↗ | (On Diff #12427) | remove this. |
| 49 ↗ | (On Diff #12427) | remove #ifdef |
| 876 ↗ | (On Diff #12427) | get rid of #ifdef |
| 930 ↗ | (On Diff #12427) | Get rid of #ifdef parts. |
| 999 ↗ | (On Diff #12427) | Remove those two empty lines |