[Differential] [Updated] D3432: Initial TOFU support in messageviewer

[aheinecke (Andre Heinecke)]

aheinecke added a comment.


  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.

INLINE COMMENTS

> knauss wrote in defaultrenderer.cpp:1008
> well if it is unknon we should better use Tofu, this is for sure better than Unknown.

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.

> knauss wrote in messagepart.cpp:889
> and what about Validity::Unknown?

>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.

> knauss wrote in messagepart.cpp:920
> 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?

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.

REPOSITORY
  R94 PIM: Message Library

REVISION DETAIL
  https://phabricator.kde.org/D3432

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: dvratil, knauss, aheinecke
Cc: kde-pim, spencerb, dvasin, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20161129/7b3c6d47/attachment.html>