Improve security when using gpg #158
Conversation
$draft is renamed to $msg_sketch $draftmime is renamed to $draft I'm doing this as a preparation for a rework on the gpg handling. For safe gpg handling, it is necessary to strictly separate the local 'sketch' from the 'draft'. The 'draft' should be a valid mail, might be synchronized with a remote IMAP server and should therefore already be encrypted, when gpg is used. This commit doesn't touch any logic. Further commits will follow, which ensure that the 'sketch' is always transformed into a 'draft' at some point.
Starting encryption only after a draft has been created is too late, because drafts might be synchronized with a remote IMAP server. To use gpg safely, command line options are needed instead of these interactive options.
With this commit, two new functions are introduced: - sketch_to_draft() and - draft_to_sketch() These two functions will - in later commits - be extended to handle the encrption and signing, so that no unencrypted draft will ever lie in the outbox, when gpg encryption is used. $msg_sketch is now a file in /tmp and will always be removed when mcom exits. The introduction of the two new functions required quite some refactoring and even slight changes in the logic. $msg_sketch is not passed to $sendmail anymore. Instead $msg_sketch will *always* be transformed into $draft, before sending or aborting and only $draft will ever be passed to $sendmail. Consequently the $automime variable, as well as the whole 'mime' option could be removed. The do_mime() function will always be called, when $msg_sketch is transformed to $draft via sketch_to_draft().
/dev/shm is a tmpfs directory, using it for temporary files will make it impossible to recover them after a powerdown. Thus security is improved. /dev/shm seems to be only available on Linux.
|
Please fix resuming mails. This is potentially breaking emails when you start a draft but accidentally close/the EDITOR crashes etc. |
|
I think this is way to complicated. I could add a special Drafts folder that you can keep unsynced on your local machine. |
|
@Anachron: When you accidentally close the editor, the message is still editable. It will only be removed once you leave @chneukirchen: I'm sad to hear, that you don't appreciate the pull request. Could you elaborate why exactly you think it's too complicated? I know the pull request introduces a lot of changes, but I don't see how it complicates the code. I actually felt like I was able to remove some complicated code. For example:
Introducing a special Drafts folder seems more like a workaround to me, because some users may want their drafts to be synchronized. Another problem with a special Drafts folder would be, that the drafts will still lie around an the disk unencrypted. With this pull request nothing will ever touch the disk unencrypted (if `/dev/shm' is available). I think if you want the most security something similar to this pull request is needed. |
How did automime make it more complicated? All it did was taking work from you.
Unless the drafts folder is actually a |
|
First of all: I know I've made quite some big changes in this pull request, but I've put a lot of effort into it and tried my best to not break things. I hope you'll take a look at it. I'm very willing to answer questions or do follow-up work.
The motivation for this pull request is, that
mblazedid only encrypt messages after a draft had already been created and placed in the outbox (if configured). This means, that a draft could accidentally be synchronized to a remote IMAP server, before it is encrypted. Other mail clients have had the same or similar issues (e.g. claws mail).I've tried to comment my commits comprehensibly. If any of my decisions seem unclear to you, please let me know.
I am aware that there are still things to do:
mencryptwill be able to encrypt it correctly again. I feel like this is something, that could be figured out later. Maybe something like anmdecrypttool should be written.