GNOME Bugzilla – Bug 238791
gpg can make evo hang if keyserver unreachable
Last modified: 2013-09-10 14:03:33 UTC
Description of Problem: To check signatures using gpg, I need to use an http proxy server. This is configured and works from the command line, as long as the http_proxy environment variable is set up. However, evolution does not pass these settings to gpg when verifying signatures. Replacing the 'gpg' binary with a shell-script that sets the env and calls the real gpg binary works. Steps to reproduce the problem: 1. Configure gpg to use a keyserver and an http proxy (in ~/.gnupg/gpg.conf, keyserver wwwkeys.us.pgp.net keyserver-options honor-http-proxy) 2. Bring up a signed message in evolution 3. Click to verify the signature. The shell hangs as gpg attempts to connect directly to the keyserver, and not through the proxy Actual Results: Evolution hangs. Expected Results: The key should be verified. How often does this happen? Every time. Additional Information:
this sounds more like a gpg bug, no? I don't believe that evolution should have to know about any gpg configuration options, if those settings are in ~/.gnupg/options (or, with 1.2.x I think it's ~/.gnupg/gpg.conf or whatever) then it should Just Work (tm).
actually, reopening bug because evolution hangs (right?). I'll consider the hang a bug, but not the http proxy thing (as that is a gpg bug afaik).
I've done a little more research into this. I don't think it is a gpg bug, but more of an interaction between the different components in evolution. If I "setenv http_proxy http://localhost:3128" in an xterm, then start evolution, I see the behavior. In a separate xterm, if I set the same environment variable and start evolution-mail on its own, then start the shell from another xterm, gpg can successfully use the proxy to retrieve keys from the keyservers. I've verified that I have the http-proxy* settings correct in gconf (the Summary page uses them correctly to pull the weather and news feeds). I noticed I forgot to include the version of Evolution I'm running: Evolution 1.2.2, from the redhat 8.0.94 distribution. I'll check this behavior on a stock RedHat 8.0 installation with the latest Ximian 1.2 build from Red Carpet also.
oh, then that is an oafd bug. you see, evolution starts up and tells oafd to start the other components. oafd just reuses the same shell env that it was started with, so if it is running *before* you set the http_proxy env, then evolution-mail won't get it. that part is not an evolution bug. leaving open still only because of the hang.
I think evo 1.5 now checks gpg status in another thread so this shouldn't be a problem anymore. need to verify that tho...
hmm, that doesn't make it an oaf bug. anyway - if the stop/cancel button fixes the hang, then it isn't a bug, just a configuration issue. (actually i doubt the gpg code does)
afaict the gpg code doesn't support cancellation quite fully/properly, and it shouldn't be hard for it to do it, so making this a 2.1 bug
Created attachment 44716 [details] [review] fixes cancellation
*** bug 236142 has been marked as a duplicate of this bug. ***
closing. if gpg 'hangs', but the stop button works in evolution, there is no bug. it should now work properly, so long as checking is done in another thread, which should always be the case.