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, d...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users