Issues with pgp-opportunistic-encrypt=true

  1. An error is raised when replying to an email with missing keys. This should not be an error. Or, if an error is desirable (so that users don't accidentally send unencrypted emails), then pgp-opportunistic-encrypt could be replaced with something like pgp-mode=[never|opportunistic|always].
  2. Encryption is automatically enabled when running :compose - it doesn't know who the recipients are at this point so it cannot opportunistically enable PGP. It should wait until the message review step to choose if PGP should be enabled or not.
Assigned to
a month ago
a month ago
bug pgp

~rockorager a month ago

This boils down to how to tell the user what's going on with the encryption status. I agree we shouldn't display encryption status until the review message screen for opportunistic encryption.

There are a few options at that point:

Case A: we can encrypt

  1. Push a Success message that we can encrypt
  2. Push a Normal message that we can encrypt
  3. Do nothing, the encryption status is shown with the headers anyways
  4. Create a config option for what should happen

Case B: we can't encrypt

  1. Push an Error message that we can't encrypt, and why (ie whose keys are missing?)
  2. Push a Normal message that we can't encrypt, and why
  3. Do nothing, the headers won't have an encryption status so the user can infer it's not encrypted
  4. Create a statusline Warning style, and push a Warning message that we can't encrypt, and why
  5. Create a config option for what should happen

I like A.1 and B.2 personally, but I also like A.3 and B.4. Open to input here, it's a pretty simple change so I can put it in once we have consensus.

~sircmpwn a month ago

My 2c:

Case A: 3

Case B: User-configurable between 1, 3, 4; 3 by default

Use-cases are:

  1. Does not care about encryption (default)
  2. Wants to encrypt opportunistically, but fine if not always
  3. Only wants to send encrypted emails
Register here or Log in to comment, or comment via email.