Implement opportunistic encryption in KMail composer, see T2520 for details.
Details
Details
- Reviewers
mlaurent aheinecke - Maniphest Tasks
- T2520: Improved opportunistic encryption support in KMail
Diff Detail
Diff Detail
- Repository
- R206 KMail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
First at all you need to increase version (for libkleo and messagecore/messagecomposer)
Comment Actions
As I wrote in T2520 how we can disable it when we don't use encryption ?
if we have 10 emails how we can know which icon is for which emails ? (we need to count them ? ) We don't have info in tooltip ?
| kmail/src/editor/kmcomposerwin.cpp | ||
|---|---|---|
| 3275 ↗ | (On Diff #3882) | Let's put this in libkleo. Makes sense for me in Kleopatra to reuse the same icons and strings I have some string changes (e.g. trust are different things in OpenPGP) and there will probably be more changes once our testers look at this. I'm also unsure what to say here exactly and what to show. I'll talk to Björn Balasz about this tommorow. |
| 3304 ↗ | (On Diff #3882) | I think we should store if we already activated it once and then don't check it again. To handle the case when a user wants to Explicitly deselect encryption. It only needs to be done once and not after adding each mail. |
| kmail/src/editor/kmcomposerwin.cpp | ||
|---|---|---|
| 3275 ↗ | (On Diff #3882) | I checked the strings you added in D1642, and I think the strings there make sense as tooltips for the validity icon when used in Kleopatra or other crypto software. I would however find them useless as tooltips to the icons here, because they don't explain what the icon means in *this* context, i.e. that the email will be sent to this particular recipient encrypted with the key. I don't think that you can craft the strings in libkleo in a way that would work everywhere (e.g. both here in composer and in a crypto dialog somewhere in Kleopatra) while still being helpful. I think it would be better to stick with custom more explanatory strings here (we are targeting users with no or very limited knowledge of crypto after all), and I can just use Formatting::iconForUid() to get the icon (so we are consistent across applications in the used icons). |
| kmail/src/editor/kmcomposerwin.cpp | ||
|---|---|---|
| 3275 ↗ | (On Diff #3882) | I think the general "This message will be encrypted" already indicates the encryption and the icons are indicators for the validity of the used keys. With regards to the strings, I'm nor sure about the strings from D1642 either. Björn is creating some mockups for me for T2348 where I have the same challenge to show the validity of a key. This might help us get a better idea how we should communicate it. |
Comment Actions
- Improved the validity strings as Andre suggested
- Switched to gpg icon instead of message-envelope
- New recipient won't enable encryption if user has explicitly disabled it
- Don't check key validity when encryption is disabled by user
- Hide the key status icon when user disabled encryption, update the icon when user enabled encryption
The issue with how to deal with the status icons when there are multiple recipients on single line has been solved in D2313, which allows to have only recipient per each line, so we can keep using the current code. I gave up on writing a widget that would allow having the key status icons mid-text.
Comment Actions
Sry, didn't get around to try it out yet.
One issue I still see with that it that this is enabled by default, right?
So it also shows up if the user does not have configured any encryption stuff. But even with configured and working encryption setup. I'd rather like to see it as an option for now in KMail and disable it by default at least until we have the backend really working the way it should. (e.g. Using TOFU trust, automatic key discovery etc.) Otherwise I think this feature might be more annoying then helpful to users (except hardcore encryption users).
Comment Actions
- Rebased from kdepim.git to kmail.git master
- Only enable when automatic encryption is enabled and configured. I don't want to add another checkbox just to toggle this feature at this point, especially since its only in master. We can decide to completely hide the feature or to add the checkbox if we feel it's not ready yet before the next major release.
Comment Actions
Hi Dan,
Looks good to me. And the option in identity is good.
The Icons need some love though but thats a bit unrelated of the functionality :-)
I think we should untoggle encryption though if a recipient is selected for whom encryption is "Kleo::Impossible"
When testing this I noticed some strange behavior. Icons appear and then shortly after disappear again.
I have keys for all the recipients. In my keyring. But the last andre.heinecke@intevation.de only got the icon for 1-2 seconds then it dissapeared again. This happens more often when I select the recipient from the completion window and not by adding it with "typing + enter". There probably is a problem that two Jobs are started and somehow mixed up and one of the jobs yields no result. Can you reproduce this or should I add some debug code to investigate?
Comment Actions
You mean not encrypt the email at all if all the recipients are Kleo::Impossible, or even if only one is Kleo::Impossible?
I have keys for all the recipients. In my keyring. But the last andre.heinecke@intevation.de only got the icon for 1-2 seconds then it dissapeared again. This happens more often when I select the recipient from the completion window and not by adding it with "typing + enter". There probably is a problem that two Jobs are started and somehow mixed up and one of the jobs yields no result. Can you reproduce this or should I add some debug code to investigate?
I can't reproduce, probably because for me the key lookup finishes immediately due to my keychain being small. I can however see the problem (probably). If the lookup takes a couple of seconds and the lookup for "name@example.com" finishes before the already-running lookup for "name@example.co", then once the lookup for "name@example.co" finishes, it will overwrite the result set by the second lookup.
I guess the lookups take a couple of seconds in a large keychain and some may be slightly faster - I would assume that looking for a known email yields a result faster due to finding a match in some hash table while looking for unknown email hits a slow path as it has to go through each key in the keychain.
Comment Actions
Hi,
Even if only one is Impossible. If the Key Selection dialog comes up we don't think its user friendly anymore. The goal is to be unobtrusive as possible by default and if a user wants to override that e.g. by explicitly encrypting to a key where the user ID does not match the mail he can still push the encrypt button.
We want to encrypt by default if possible and not always encrypt.
This should fix the icon showing and then disappearing after a couple of seconds.
Indeed, I tested and it works now. Thanks.
Comment Actions
Automatically turn off encryption (unless user enabled it explicitly) if we have a recipient without a key.
Comment Actions
I implemented this and it seems to work well enough although it's rather fragile, because we have no way of knowing if we failed to get the key because the address is incomplete or because the address is complete but we simply don't have the key.
Comment Actions
commit e8ecb6edcba3bafb3f163802344d5d98554b5fd4
Author: Daniel Vrátil <dvratil@kde.org>
Date: Mon Oct 3 13:46:07 2016 +0200
Implement opportunistic encryption in composer When enabled KMail will automatically look for public keys for each recipient and if it finds one, it will automatically enable encryption. The key lookup includes fetching public keys from a key server. A small icon will also appear next to each recipient with more details regarding the trustiness of the key and will display dialog with more details about the key being used for encryption when clicked. If we fail to obtain a key for at least one recipient, the email won't be sent encrypted unless user explicitly toggles the encryption on. The feature is only enabled when current identity has "Automatically encrypt messages when possible" enabled.