[Enigmail] Problem with automated decryption of encrypted drafts? (Key unlocking popup nightmares)

[sini.ruohomaa at cs.helsinki.fi]

Hi,

Sorry, I was hoping I could find a solution for this so I could report
it but only got to a state where I've minimized the effects by avoidance
behaviour. :/

One "solution" to work around this would be to let my email program
always cache my key until the end of the session and only have this
problem once per session (I have multihour sessions, it wouldn't help a
whole lot to just cache for a couple of hours), but

a) my heart bleeds over the thought that I have to accept the ever so
slightly reduced security just to not be harassed repeatedly for
decryption I have not requested. (Why ask the user in the first place if
this is the only way to go, etc.) Also,

b) it still means that just having Enigmail installed gives me random
key unlock requests, apparently even on sessions where I'm not handling
encrypted mail. As long as this stands I've chosen not to install the
plugin in one of my TB setups where I don't have time for playing
around, just because the hassle is too big; I'd rather have to cutpaste
the mails manually out of TB for decryption if I need them than take the
popup windows. So this bothers me.

This is what I've managed to do. I'd appreciate if someone could
eliminate that some of these actions are not necessary/useful for peace
from popups:

- I turned off all automatic decryption I could find (have to
  manually press the 'decrypt' button now - and have started to wish it
  would be an "Other Actions" in the message preview pane too ;))
- I also turned off all other TB features that sound even remotely
  like they're trying to read messages. This includes search indexing
  and spam filtering.
- I changed my drafts saving to be local instead of on the IMAP server,
  just in case that would spare me from key unlocking popups (this
  too causes minor inconvenience so I may have to revert it, I'm hoping
  it doesn't make a difference).
- I have a per-recipient rule to encrypt mail, so to those recipients I
  don't type in the recipient before I'm about to send.
- I don't click on the encryption key to indicate I want to encrypt
  the message before I'm about to send either. (It'd be really great if
  this wasn't a problem, too, because it increases the probability of
  forgetting.)

This session I got an unwarranted popup asking for a key unlock:
- while I was editing my message filters (I don't *think* I had any
  encryption-related mails open at the time, it just came as a
  surprise and got me to start this mail; it's not easily reproduceable)
- expectedly when I tried to save as draft a mail that was marked to
  be encrypted (to test the window grab one more time),
- after I deleted an encrypted test draft mail from my Drafts folder and
  the preview pane moved on to an unencrypted mail (this one, actually),
- after I first turned _off_ encrypting on the open draft message from
  the yellow key icon in the bottom right corner, and made sure it was
  deleted from the Drafts folder, and THEN tried to save it as draft
  (this seems to be a bug, shouldn't it start saving the draft
  as cleartext at that point?)
- after autosave wanted to save said test mail a couple of minutes
  later; after that I didn't change it so it's been peaceful.

For the most part, I seem to get through my sessions with little
harrassment currently as long as I don't do anything unusual or handle
encrypted mails, but I still have problems replying to encrypted mails
(that is, besides decrypting them to be read and to be replied to, which
I find completely reasonable). Because the replies are by default
encrypted, the draft autosaving keeps wanting to decrypt the result even
though the message is open in front of me. (This also occasionally leads
to a strange effect that my draft folder starts to fill up with copies
of the draft message over time, but I'm not able to reproduce it with my
test message.)

[Pinentry grabs X session]
> On Wed,  2 Jan 2013 19:50, dkg at fifthhorseman.net said:
>>> GnuPG 2.x, and there is nothing Enigmail could do about it. AFAIR
>>> there is an option in gpg-agent.conf to disable blocking the X session.
> 
> It is called --no-grab.

I may be dense since gpg-agent always seems to defeat me whenever I get
close to it. But I added this option to a new file,
~/.gnupg/gpg-agent.conf. It now contains the line "no-grab" and nothing
else. I also made sure the Preferences > Advanced > "Use gpg-agent for
passphrases" option was set. The resulting command in the console is
"gpg --charset utf-8 --display-charset utf-8 --batch --no-tty
--status-fd 2 --decrypt --use-agent".

This has no effect on the blocking effect of the popup windows asking
for my key passphrase. I can change window focus out of the popup by
moving my mouse around, but I cannot do anything in the other windows.
I'm not sure what I'm doing wrong.

>> Do any gnupg contributors have suggestions about the "fails to cache my
>> 'cancels'" concern Sini raised above?  I'm not sure how the pieces could
> 
> I am not sure what he means.  However, recent GnuPG's and pinentries
> have a cancel-all feature: Either the pinentry features an appropriate
> button or you use the close-window button of the pinentry which also
> sends the cancel-all message.
> 
> This is useful if gpg starts looking for --throw-keyid keys and you know
> that you don't have the key.

This feature may also theoretically exist, but unfortunately it makes no
difference for me if I hit 'cancel' or close the window from the upper
right button; I'll still get the dialogue repeatedly if it's coming
repeatedly. I suspect it's just because gpg-agent is immediately being
asked a second time after I cancel, as my Enigmail console seems to
suggest. I've been unable to start an Enigmail log file.

Sorry about the length, too high threshold to complain on mailing lists,
don't want to do it multiple times. X-)

Best regards,

--Sini