Create Task
Maniphest T2520

Improved opportunistic encryption support in KMail
Open, NormalPublic
Actions

Description

For the development Project EasyGPG we would like to see better support for Opportunistic encryption in Kmail.

Currently (I've checked with 4.14) there is the option in "Securtiy -> Composing -> Automatically encrypt messeges whenever possible" I think we can reuse that option and improve it.

With this option enabled KMail shows a Dialog on send:

It's a Dialog and thus an extra click and it is not transparent what happens when you click send.

Also KMail currently only does a keylisting which would not automatically fetch a Key even if "auto-key-retrieve" is enabled in GnuPG. When auto-key-retrieve is enabled in the GnuPG System the retrieval should also happen when composing a mail. This will automatically add support for "more trusted" key directories like the proposed Web Key directory:

http://www.ietf.org/id/draft-koch-openpgp-webkey-service-00.txt

Or other new Key Directories GnuPG might support in the future. The API to use for this is GnuPG's locate-keys command. Though this currently returns a list of all the keys found for a mailbox. I've talked to GnuPG upstream about this and In the future GnuPG will provide API to ask for a single "best" key (upstream issue https://bugs.gnupg.org/gnupg/issue2359 ). For now I'll implement that resolution in libkleo. I'll ping in this issue when It's done.

I imagine it to work this way as a first step (we can of course discuss it):

  • When opening a new composer encrypt is initially unselected even if an encryption key is selected for this identity.
  • Once a mailbox is entered KMail starts a "Locate Keys" command for this mailbox.
  • When this is finished and a Key with at least Unknown Validity for this UID is found KMail toggles the Encrypt action and shows the "This message will be encrypted" Status.
  • Signing is taken from the Identity configuration "Automatically Sign Messages" just as now.
  • If a mailbox is added for which no key can be found and encrypt was toggled automatically encrypt is untoggled.

To indicate for which mailboxes keys were found there could be a status indicator next to the mail like:

This indicator shows the validity of the key. There are six levels. In Kleopatra I've used the following mapping as status Icons for some mockups / Ui work in the signencfiles-3 branch:

switch (uid.validity()) {
    case UserID::Ultimate:
    case UserID::Full:
        return QIcon::fromTheme(QStringLiteral("emblem-favorite"));
    case UserID::Marginal:
        return QIcon::fromTheme(QStringLiteral("emblem-success"));
    case UserID::Never:
        return QIcon::fromTheme(QStringLiteral("emblem-error"));
    case UserID::Undefined:
    case UserID::Unknown:
    default:
        return QIcon::fromTheme(QStringLiteral("emblem-information"));
}

There should probably also be an icon or "waiting" indicator if the locate-keys command does not return quickly.

For KMail we will need new Icons that have some crypto indication. Emblem information for unknown / undefined because this indicates "You have a Key but you have no information that the key really belongs to the User ID". If a key was obtained through the Web Key Service it will probably start out with Marginal trust. In a first iteration we can probably just use two icons next to each other, actions/gpg and the emblems above.

The tooltip should indicate the validity.

In the future and if the TOFU trust model is used there will be five additional states that further define the "marginal" validity TOFU will provide. But I'll leave TOFU Support for another task as there is no GpgME API for this currently.

If the icon is clicked Kleopatra's certificate details dialog should be shown. For now this can work through a process call to kleoptra like it's already done in the messageviewer.

Sending should work the same as now. e.g.

  • If send is triggered before the locate-keys command was finished the usual "Certificate selection" dialog is opened.
  • If "Always show the encryption keys for approval" is selected the dialog is shown, otherwise the located keys are used.

Details

Differential Revisions
D1642: Add Formatting code for UserID Icons and validity
D1639: Implement opportunistic encryption

Related Objects
Search...

aheinecke added a comment.May 17 2016, 2:12 PM

I've added a KeyForMailboxJob in Libkleo. It takes a mailbox as parameter and results in a Key and the according UserID. (And the usual Job result babble)

I've returned the UserID, too because there could be a case where there are multiple UID's for an E-Mail address and we want to show the validity of the most valid one.

dvratil added a comment.May 18 2016, 2:14 PM

Ran into first issue: it's possible to enter multiple comma-separated email addresses into a single AddresseeLineEdit (.e.g when you copy-paste a list of addresses from somewhere). For now I'll just ignore it and will only consider the first address if there's more.

We definitely want to handle this case in the future, but the biggest challenge there is to draw the status icons. I can easily add an icon to left (or right) side of the QLineEdit, however having mixed text and images is not really feasible with QLineEdit, so we'll have to look at other options (QTextEdit, or any other QTextDocument-based classes).

aheinecke added a comment.May 18 2016, 3:08 PM

Yes, had not thought of this.

But I think this still could be handled by QLineEdit and line edit actions if we add multiple actions / icons in the leading position in the order of the entered mails.

E.g.
[X][X][?]foo@bar, foo2@bar, foo3@bar

I think this would be ok as the general Idea is to give an overall status. And this way all the icons are close together and not somewhere in the line.

knauss added a subscriber: knauss.May 19 2016, 1:29 PM

there is an option to split automatically expand groups, i think that could also be used to split different recipients into different lines.

mlaurent added a subscriber: mlaurent.May 19 2016, 1:39 PM

[X][X][?]foo@bar, foo2@bar, foo3@bar

> if we have 50 emails we will have 50 icons ?

How manage when we don't use encryption ? we will have all the time icons ?

There is a settings to disable it ?

aheinecke added a comment.May 19 2016, 2:17 PM

There is a settings to disable it ?

I think we should reuse the "Automatically encrypt when possible" composer setting to enable/disable this and keep it disabled by default as it is currently. When we later change identity configuration to enable some "Easy Crypto" (which would also change the required gnupg system settings). We can change that setting.
This is a better way (imo) of implementing "Automatically encrypt when possible" as it shows if a message will be encrypted _before_ hitting send.

dvratil added a comment.EditedMay 20 2016, 8:05 AM
In T2520#34223, @mlaurent wrote:

[X][X][?]foo@bar, foo2@bar, foo3@bar
if we have 50 emails we will have 50 icons ?

I don't think all icons on the left is a good idea, I'd much more prefer

[x]foo@bar, [x] foo1@bar, [?] foo3@bar

but as I said it will need bit more work to get that implemented (unless you know if there's such a widget already that we could re-use?)

aheinecke added a comment.Jul 20 2016, 12:28 PM

I think with we can move forward with this a bit.

The current ideal plan for this (needing gnupg 2.1 and TOFU support):

#UserID ValidtyIndcationIcon*Rationale / Handling
1Validitiy == UndefinedIt is unknown if the Encryption Key available belongs to this recipient.Question mark over encryption lock.This will be the case if there was no previous communication, no mail seen signed by this key and the key not obtained through a somewhat validating service. In this case there should be no encryption as there is a fairly high chance that the recipient then can't read this mail. It's also probably not to be expect that highly confidential data is exchanged on first contact. The mail should be signed though so that the recipient already gets an indication about the senders key and can respond encrypted in turn. The question mark should be shown to give the user opportunity to open the details of the key and e.g. manually confirm the fingerprint if really neccessary.
2Validitiy == Undefined && Key from verifing sourceMedium securityYellow checkmark over encryption lock.There is a service indicating that the key belongs to someone with this E-Mail Address. It should be visible through the icon and the details that the trust is fairly weak.
3Validitiy == Marginal && TOFU History < Key with enough history for basic trustMedium securitysame as above.Similar to the case where the key was validated by a third party. There is little indication that the key belongs, you have seen a signed mail with this key already.
4Validitiy >= Marginal or TOFU History >= Key with enough history for basic trustHigh securityGreen checker over lockIn this case for GnuPG this key is trustworthy because it belongs to the recpient you already have a communication history with or is valid through the web of trust. Everything fine.
5Vertrauen > MarginalVery high SecurityLock with a starThis is only reached if Web of Trust trust is Full or Ultimate. So either you have signed the key directly (in which case the application must assume that the user actually verified the key through a second channel) or you are a crypto nerd and have set up Ownertrust and a Web of Trust. Congratulations.

This plan was documented and talked over and argued about in our Team and together with Werner Koch from GnuPG. Might be subject to change a bit as there is still some discussion especially how to handle the cases with "Medium security" as just recieving a signed mail and immediately responding gives you questionable security. While on the other hand if you have passively read a signed mail some time ago, maybe even on a public channel like a mailing list, gives you are fair amount of indication that you can use this key. (Or that a very expensive and detectable attack is happening.)

For now we can't handle case two and the TOFU parts of case three and four. I've already added TOFU Support for GpgME++ but this is only for verification and not info on a key. GnuPG also does not yet support saving the key source as neccessary for case 2.

The next steps I see here:

  • Find a solution for Multiple mail addresses (Dan)
  • Make this optional depending on config (default off), and I think we should replace the old auto encrypt with this. (Dan)
  • Fix it up so that it can be part of master (Dan)
  • Add strings and icon lookups to libkleo (Andre, who really want's to have that in Libkleo ;-) )
  • Make more TOFU information available through GpgME (GnuPG / Andre)