GNOME Bugzilla – Bug 724129
[Composer] Encrypt Draft message when encryption is enabled
Last modified: 2018-11-26 09:53:51 UTC
The purpose of message encryption may be to hide the message contents from the email servers including those where message drafts can be send.Similar case can be raised for local storage: evolution should expect that the storage underlying /home is not encrypted so in order to keep the message secret, it should be encrypted as well. IMO the compatibility with encryption-unaware clients should not be taken into account because encryption is usually not enabled by default so when choosing to encrypt, the users know what they are doing and it's better to fall back to secure side. Version: Evolution 3.10 How to reproduce: 1. compose a message, enable PGP or S/MIME encryption (or both) 2. save message draft 3. open or preview the draft Actual result: draft is saved in open Expected result: draft is encrypted Notes: * if recipient is not filled, the message should be encrypted with user's own key(s) * if no user's own keys are available, error should be present to user saying that either keys should be chosen or encryption should be disabled * when such draft is opened, it should be decrypted and reencrypted on sending * when such draft is opened and keys are not available, user should be required to confirm sending of such a message (because they might or might not know what they are sending)
This is particularly bad if the drafts are being stored on a server, and when drafts are being saved automatically. In that case, you've just leaked the contents of your message to the server, which is the main thing that encrypted mail is supposed to protect the user from.
Version: 3.26.2 Still broken ;( Any chance to raise priority a bit higher? Or is it that people using/developing evolution just kind of don't really care that much about proper encryption implementation?
(In reply to Larry from comment #3) > Version: 3.26.2 > > Still broken ;( > Any chance to raise priority a bit higher? > > Or is it that people using/developing evolution just kind of don't really > care that much about proper encryption implementation? No, people doing evolution are wonderful, there's just too few of them. :(
I've done this with the below change. As the same code is used for autosaving also autosaved files on the local disk are encrypted (thus be prepared to enter the passphrase for the key/certificate when it will want to autosave). It encrypts only for the user's key/certificate (the From account), not for other recipients. The change is not giant, but it can have side effects, thus I rather committed it only to the development version, even it's cleanly applicable to 3.30 stable series too. Created commit 9b31b9cb04 in evo master (3.31.1+)
Why is a passphrase needed for key/certificate for autosave? the drafts do not need to be (and should not be) cryptographically signed, and the encrypted draft doesn't need to be re-read during auto-save, right? encryption to a public key shouldn't require any special access. (btw, Yes, a passphrase should be necessary for *restoring* from the draft (autosave or otherwise), but that's an understandable thing -- a user action: restoring the draft.) a quick skim of the commit doesn't clarify to me whether the draft will be encrypted to the message recipients as well, but line 1143 (https://gitlab.gnome.org/GNOME/evolution/commit/9b31b9cb04#fc951a67be18be45996c5d8adde2f367c193bd53_1144_1143) looks like they will be excluded. That is the correct choice! The only person a draft should be encrypted to is the author. If there are circumstances where the draft might be encrypted to another party, then we should open another issue to ensure that gets fixed.
(In reply to Daniel Kahn Gillmor from comment #6) > Why is a passphrase needed for key/certificate for autosave? At least with S/MIME I've been asked by NSS to unlock my certificate database. I just meant to say it can happen the password prompt appears, even it not always will nor should. > looks like they will be excluded. Yes, they are excluded, intentionally.
*** Bug 527367 has been marked as a duplicate of this bug. ***