search

leahneukirchen / mblaze

Unix utilities to deal with Maildir
Other
451 stars 50 forks source link

Improve security when using gpg #158

Open codesoap opened 5 years ago

codesoap commented 5 years ago

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 mblaze did 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:

  1. I've not yet updated the man page, because I don't want to have to change it again, after incorporating feedback.
  2. Resuming to an encrypted draft is not really possible right now, because there seems to be no easy way to decrypt the message in such a way, that mencrypt will be able to encrypt it correctly again. I feel like this is something, that could be figured out later. Maybe something like an mdecrypt tool should be written.
Anachron commented 5 years ago

Please fix resuming mails. This is potentially breaking emails when you start a draft but accidentally close/the EDITOR crashes etc.

leahneukirchen commented 5 years ago

I think this is way to complicated. I could add a special Drafts folder that you can keep unsynced on your local machine.

codesoap commented 5 years ago

@Anachron: When you accidentally close the editor, the message is still editable. It will only be removed once you leave mcom. But I get your point and could try to work out the resuming to encrypted drafts.

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

Anachron commented 5 years ago

@codesoap

$automime is now gone and with it the interactive [m]ime option, which I found confusing as a new user

How did automime make it more complicated? All it did was taking work from you.

Another problem with a special Drafts folder would be, that the drafts will still lie around an the disk unencrypted.

Unless the drafts folder is actually a tmpfs file-system.

codesoap commented 5 years ago

How did automime make it more complicated? All it did was taking work from you.

[m]ime could be removed, because mmime is now always automatically applied, if necessary. Thus there is no need to keep track of whether it has been done or not using $automime anymore. Take a look at the commits.