| Summary: | x11-plugins/enigmail-1.1.2 fails to connect to gpg-agent | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Stephan Friedrichs <deduktionstheorem> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | 96bd763529be62c7350d43e8ae67f9623c998ddc, alex, alienpenguin, anna.janackova, ben, djc, eXt, gentoo-bugs, ian, icephoenix.nx1729+gentoo, jaak, jimtahu, jnerin, pqGungnir, thanasis, vityokster, xmw |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
enigmail debugging output
paludis --info enigmail thunderbird gnupg Output from binary enigmail-1.1.2 xpi installed from within thunderbird Output from binary enigmail-1.1.1 xpi installed from within thunderbird 80_enigmail-js-fix.patch - Patch to comment out problem lines in enigmail.js Patch enigmail-1.1.2.ebuild to apply 80_enigmail-js-fix.patch Backport of official sources |
||
|
Description
Stephan Friedrichs
2010-07-06 08:48:22 UTC
Created attachment 237683 [details]
enigmail debugging output
Created attachment 237685 [details]
paludis --info enigmail thunderbird gnupg
I have the same problem, using the same arch (x86_64) and locale (en_GB.UTF-8) as Stephan, so my enigdbug.txt output is almost identical to Stephan's, apart from a few environment variables. I've tried running revdep-rebuild, and also tried re-emerging both app-crypt/gnupg-2.0.15 and mail-client/thunderbird-3.1 but this doesn't fix the problem. What *does* fix the problem is unemerging x11-plugins/enigmail and installing the official binary "enigmail-1.1.2-linux-x86_64-gcc4.4.3.xpi" from within the thunderbird client. Created attachment 237719 [details]
Output from binary enigmail-1.1.2 xpi installed from within thunderbird
Here is the enigdbug.txt log from a working binary enigmail 1.1.2 xpi installed from within Thunderbird for comparison with the non-working enigmail installed in the system directories by the enigmail ebuild.
It looks similar until the point after it fails to connect to a running gpg-agent. The system-installed enigmail gave up at this point, but the binary enigmail installed in the user profile ran a wrapper script to start gpg-agent.
I'll try a few more experiments. One of the differences is that one was installed at system level and one was installed in a user profile, so I wonder if that's where the problem lies?
(In reply to comment #4) > It looks similar until the point after it fails to connect to a running > gpg-agent. The system-installed enigmail gave up at this point, but the binary > enigmail installed in the user profile ran a wrapper script to start gpg-agent. Correction: the system-installed enigail didn't give up at this point. It tried to run /usr/bin/gpg-agent directly, whereas the user-profile installed enigmail ran the wrapper script at this point. A system-installed, older enigmail-1.1.1 (installed from ebuild) also runs a wrapper script at this point and that one works okay. Using the system-installed enigmail from the ebuild, I tried deleting the contents of the "/usr/lib64/mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/" directory and unzipping the official binary "enigmail-1.1.2-linux-x86_64-gcc4.4.3.xpi" into that directory. Thunderbird still has the same problem with gpg-agent in this case.
In other words, the official binary xpi only works when installed as an extension in the user profile, not when installed as a system extension.
I also tried it the other way, installing the xpi in the user profile, installing Gentoo's enigmail package, replacing the files in the user profile extansion with the files from the system-installed extension, and then un-emerging the system-installed enigmail. This left me with Gentoo's enigmail files installed as a user profile extension. Thunderbird had no problem running the enigmail extension in this case.
Something else I noticed comparing the enigdbug.txt logs generated by the user-profile installed version and and system installed version is that the system profile version produces the following log message before it tries to run /usr/bin/gpg-agent directly:
enigmail.js: detectGpgAgent: [xpconnect wrapped nsIFile] failed
Created attachment 237737 [details]
Output from binary enigmail-1.1.1 xpi installed from within thunderbird
Another clue: going back to installing the official binary enigmail xpi as a user profile extension (with the system extension not installed), enigmail-1.1.1 fails in a similar way to this bug except that the enigdbug.txt log is slightly different (see attachment). It runs gpg-agent via the wrapper script, but still fails to start it successfully. This is also the case when installing the enigmail 1.1.1 xpi as a system extension.
(In reply to comment #7) > Created an attachment (id=237737) [details] > Output from binary enigmail-1.1.1 xpi installed from within thunderbird > > Another clue: going back to installing the official binary enigmail xpi as a > user profile extension (with the system extension not installed), > enigmail-1.1.1 fails in a similar way to this bug except that the enigdbug.txt > log is slightly different (see attachment). It runs gpg-agent via the wrapper > script, but still fails to start it successfully. This is also the case when > installing the enigmail 1.1.1 xpi as a system extension. Replacing "components/enigmail.js" installed by the enigmail-1.1.1 xpi in the user profile with the one from the enigmail-1.1.2 xpi makes it work (but trying same trick in the system extensions does not work). There isn't a lot of difference between the "components/enigmail.js" files - the one from 1.1.2 sets 'extensionLoc.permissions = 0755;' before running the gpg-agent-wrapper.sh script in two places (one to 'start; the agent and one to 'stop' it), and that's the only difference. I also have the same problem since enigmail-1.1.2, 1.1.1 works fine. I found out that it is not the following upstream bug since the permissions of the wrapper script are correct: https://www.mozdev.org/bugs/show_bug.cgi?id=22959 However that might provide an explanation why it fails with 1.1.1 installed in the user profile (@ comment #7). Sorry for all the noise, but I think I've accidentally stumbled upon a solution! Turns out the very lines that were added to "components/enigmail.js" are the very lines that stop it working when installed as a system extension!
So, a workaround for the problem is to edit the installed "/usr/lib/mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/enigmail.js" file and comment out (or delete) the two lines that say "extensionLoc.permissions=0755;". You can comment them out by adding "//" (without the quotes) at the start of the lines.
Created attachment 237747 [details, diff]
80_enigmail-js-fix.patch - Patch to comment out problem lines in enigmail.js
This patch is intended to be applied by the ebuild at the same point that 70_enigmail-fix.patch is applied. In fact, 70_enigmail-fix.patch doesn't seem to be needed any more.
Patch for ebuild will follow.
Created attachment 237749 [details, diff]
Patch enigmail-1.1.2.ebuild to apply 80_enigmail-js-fix.patch
This patch modifies the enigmail-1.1.2 ebuild to apply my 80_enigmail-js-fix.patch instead of 70_enigmail-fix.patch (which doesn't seem to be needed any more).
(In reply to comment #10) > So, a workaround for the problem is to edit the installed > "/usr/lib/mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/enigmail.js" > file and comment out (or delete) the two lines that say > "extensionLoc.permissions=0755;". You can comment them out by adding "//" > (without the quotes) at the start of the lines. This definitely makes the symptoms go away. But is it safe? (In reply to comment #10) > So, a workaround for the problem is to edit the installed > "/usr/lib/mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/enigmail.js" > file and comment out (or delete) the two lines that say > "extensionLoc.permissions=0755;". You can comment them out by adding "//" > (without the quotes) at the start of the lines. Thanks, this resolved the issue for me. (In reply to comment #13) > (In reply to comment #10) > > So, a workaround for the problem is to edit the installed > > "/usr/lib/mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/enigmail.js" > > file and comment out (or delete) the two lines that say > > "extensionLoc.permissions=0755;". You can comment them out by adding "//" > > (without the quotes) at the start of the lines. > > This definitely makes the symptoms go away. But is it safe? > I think so, because those two lines are intended to change the permissions (chmod) on the script file itself, which is fine for a script in your profile, but not for a script file in the system directories as a normal user won't have permission to chmod that file. The reason for those two lines is explained in this upstream bug report: https://www.mozdev.org/bugs/show_bug.cgi?id=22992 We don't need to change the permissions on the script file because it's already executable. It was resolved upstream by wrapping the problematic lines in a try/except block to ignore any failure to change the permissions. (I'm not sure why they don't just launch /bin/sh instead and pass it the script filename and script argments!) Created attachment 238221 [details]
Backport of official sources
Your proposed solution works for me.
Like you described, there ist no reason for the script not to be executable. So even though I can't think of a use case where the code from the official sources have a benefit over uncommenting the lines, I attached a patch to backport the solution from the official sources.
Either one solution works for me.
downgrading to 1.1.1 worked for me. (bump) will populate to rsync mirrors shortly. *** Bug 326985 has been marked as a duplicate of this bug. *** Bug not solved completely. To complete the work with thunderbird-3.1 gnupg-2.0 it took me two scripts to executable:
chmod +x /usr/lib64/thunderbird/extensions/\{847b3a00-7ab1-11d4-8f02-006008948af5\}/wrappers/gpg-wrapper.sh
chmod +x /usr/lib64/thunderbird/extensions/\{847b3a00-7ab1-11d4-8f02-006008948af5\}/wrappers/gpg-agent-wrapper.sh
In this regard the need to modify the ebuild.
This bug still occurs with Thunderbird 10.0.11... The chmod fix works for me. |
