GNOME Bugzilla – Bug 261186
PGP auto-verify can take too long when it has to deal with a new key, holding up rendering the message
Last modified: 2005-02-08 08:11:42 UTC
If you happen to be subscribed to a high traffic mailing lists where you don't necessarily have all the posters' public keys [yet], then you go through the automatic verification cycle for new keys quite a bit. Evolution is [from a user point of view] blocking as the gpg process it fires off: i) fetches the key from public keyserver (see also #38791) ii) updates the trust db [every time - it just got a new key :(] iii) actually verifies / decrypts. It's point (ii) that I think is causing the real problem. This can be both a big CPU hit and can often take 10s of seconds [ick]. Meanwhile, there is no email on the screen, and evo is sitting there with no indication of what it is up to. Real drag! [actually, status bar in shell says "formatting message" - but for 25 seconds? If possible, and alternative might be to get on with rendering the message (if its not encrypted) and put a "pending" or "working" blurb in the bottom where the PGP signature validity and trust indication will ultimately end up. AfC Sydney
i'll just make it say something else other than just formatting message. the delay is just a gpg issue and there's nothing we can do about it
Created attachment 43928 [details] [review] add some progress reporting
missed a #include "camel-operation.h" in the patch
I know you want to just tuck this away in the "it's an external problem" pigeonhole, but I've gotta tell you that this is worse than I originally thought. Scenario: You've been reading through a list of messages, deleting as you go, then hit one which is signed by a person whose gpg key you don't have. Suddenly instead of the usual behaviour of a new message appearing, the previous message just sits there. And sits there. Just as would happen *if you hadn't hit the delete key*. So the natural reaction is to hit the delete key again. [And maybe even a few more times if you're really persistent] The unfortuante result, however, is that you end up deleting the very message that you {didn't realize you were waiting for a key download/trustdb update for}. So, unless you're paying close attention, it's really easy to miss the fact that you've deleted messages you didn't intend to, which is somewhat of a drag. NotZed's patch putting a more useful status message is terrific, but I've just realized that quite often an opened message in it's own window (ie as opposed to preview pane) obscures the shell's status line, meaning that whether it's "Formating message" or "Verifying message" or whatever [I would actually suggest "verifying digital signature" or something a touch more explicit], the user still doesn't actually have any indication that evo is blocking because they can't see said status message. In a sense, this issue has always existed; but before one had to click on the lock icon to cause GPG to run to verify the signature, and so if it took a while (which it most certainly did if signed by someone whose public key you don't have yet) it was understandable. Evo's new behaviour of automatically attempting to verify any message that is signed (which I think is terrific) does however cause a whole lot more key downloading to be necessary, making this issue a rather clear and present usage problem for yours truly. I realize there is a workaround of "disable auto key fetching inside GPG" but that sort of does defeat the utility of this terrific if-there's-a-signature-we-really-should-verify-it feature in the first place. I'd go so far as to suggest you may want to [re]elevate the priority of this issue to Major. AfC
this is no different than if for example an imap server is slow in responding. its a side-effect of what you're doing, so i see no problem with evolution here.
Patch commited by NotZed on July 12th according to e-p list
Patch did nothing to address underlying issue. First of all, all the patch did was change things so that Evolution now sits there with "Verifying, 0%" until a single pulse of "verifying 100% many 10s of seconds later, and then status messages clears. Just sits there at 0%. Not very enlightening - and evo still sits there with a blank screen. As for underlying issue, I find it strange that you consider * people on high traffic mailing lists * in which many messages are gpg-signed * and for which people have their gpg configured to auto-key-retreive. an unusual case. Amongst the hacker communities, at least, this is almost the default case. And because of the blocking, evo is really un-fun to use. Seriously - who *doesn't* have their GPG set to auto-key-retrieve? For those who come across this bug and are frustrated by the issue, running $ gpg --no-sig-cache --rebuild-keydb-caches once in a while can help speed things up marginally (my trustdb checks went from average 45s to under 15s) but no, it doesn't fix evo's problem. AfC
*** bug 213885 has been marked as a duplicate of this bug. ***
andrew: me *doesn't* have their GPG set to auto-key-retrieve. :-) to me this is a NOTXIMIAN, sorry. what at all should evolution do?! what's your explicit advice to the coders? at least there is a status message telling you what is happening...
As I understand it, right now when a PGP signed or encypted message is detected, then immediately Evolution stops, hands off the message to gpg, and blocks. As I've observed, the resulting blank screen (and worse, blocking behaviour) is really tedious. If I may, a slightly more usable solution would be to display the message immediately *before handing off to gpg*, and then, after the gpg exec returns, adding the footer about the signature validity. [perhaps meaning redrawing the message, which would be less than ideal, but since its an addition at the bottom, not top, it shouldn't even be noticable]. This way, the user would get their message (not to mention dramatically improving responsiveness while flipping through the message list), and then the [admittedly secondary] information of whether or not the signature validates can be presented when it becomes available. [an alternate approach would be to make the signature-valid-or-not block an image, with deferred loading...] Obvously if the message is encrypted, then at first gibberish would appear on the screen, but I'd even go so far as to say that that's not a bad thing (emphasizing that it was, indeed, encrypted), and I would display a status message "decrypting" then redraw the screen assuming the decrypt succeeds. Again, just trying to avoid the "blank screen, 0% verifying..." wait, wait, waiting, I'm still waiting!... AfC