Attempts to send signed messages with attachments fail in 1.5.1
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
1 Attachments
#140 Attempts to send signed messages with attachments fail in 1.5.1
For a little while (since using Thunderbird 17), I found that sending signed messages which had attachments would sometimes fail with a "Sending aborted/An unknown error has occurred" message. Occasionally I could save the failed message to draft, reopen that and send it. Sometimes resending the draft would only work after restarting Thunderbird. I don't know what's changed, but I'm now finding that sending signed attachments fails all the time, and that the workaround I found doesn't solve the problem, I only mentioned them in case it provides some insight as to what's causing the problem.
I've created the debugging output (attached) and all I can see is that gnupg seems to return an error code of -2 (despite apparently successfully signing the attachment). There's also mention of statusFlags = 40000000, and I found code within enigmailCommon.jsm's encryptMessageEnd function that handles such statusFlags and unusual error codes, but that doesn't seem to get called for attachments. I couldn't figure out how to check whether that was the problem though.
I'm happy to run tests that might help and provide any further information I can, please just let me know...
Hi,
it's not gnupg that issues "-2" as error. Copying of enigerr.txt fails because it has a double slash in the path (/home/mike/.local/log//enigout.txt/enigerr.txt).
Will analyse the rest, too :-)
Thanks, I'd dug out the gnupg source code to see if I could find it, but it makes more sense that it's related to the line above! That was an easy one to fix (just removed the trailing slash I put on the log dir), but it didn't seem to change the -2. Enigerr.txt contained the lines quotes further down (including USERID_HINT up to and including SIG_CREATED), but enigout.txt was empty.
Forget about enigout and other files. The only relevant file is enigdbug.txt, which contains all information I need.
I believe that this could be a race condition, i.e. some asynchronous tasks are not performed in the correct sequence. Do you have a particularly fast or slow PC?
Patrick, I could reproduce this issue once yesterday evening but not any more today, so your suspicion is very reasonable.
One of my machines is very fast (i7-2600K CPU @ 3.40GHz) and that one always seems to suffer the problem. The other is quite fast (i5-2520 CPU @ 2.50GHz), which often experiences the problem, but occasionally would work after retrying a few times afterwards and/or after saving to draft and then attempting to send.
This confirms my suspicion - I just have to be creative in order to
simulate a fast machine on a slower one ;-)
Could you please install the latest version of Enigmail from the nightly downloads page (http://www.enigmail.net/download/nightly.php)? I don't expect that the bug will have gone, but I improved some of the logging, so I'd be interested in the enigdbug.txt file.
Ok, first off I tried building it from source as I had with my 1.5.1 build (Gentoo does it for me, so I just have to swap out a tar.gz for one I made from git), but unfortunately that didn't build in parallel. Seemed to be a .h file wasn't being created from a .idl early enough for a .cpp and .h file to make use of it. I eventually got it built with MAKEOPTS="-j1". I'll attach the build logs in the next comment, just let me know if you'd like me to file it as a separate bug.
Before I got it built from source, I wiped out the previously built 1.5.1 extension from my extensions directory, and installed the xpi from the website. I don't see any of the additional debugging statements, although instead of "expected type int, got (void 0)", I now get "error: wrote -1 instead of 1 bytes". After I built from source, I got the same output (which is what I attached).
I also noticed with the nightly build that if I started thunderbird and didn't give it time to check mail, etc, but just started composing and sent a file with a signed attachment, the script took a very, very long time to complete (showing the thunderbird "this script is taking too long dialog"), but seemed to succeed eventually and send off the message. I don't know if that's relevant or not, but I've only seen it with the nightly so figured I'd mention it.
Parallel build failure gzipped log
OK, at least the log now states clearly that writing data to the launched process did not succeed.
I won't investigate the Gentoo build error, as I didn't create the package. I have no clue what Gentoo changed and what they might have forgotten, and I don't have a Gentoo environment to investigate this either. If you want to build Enigmail and have my support, then follow the build instructions on http://www.enigmail.net/download/source.php.
I uploaded a new version of Enigmail with some more debugging info and some potential fix as well. Could I ask you to try this one?
Fair enough, I just thought you might like to know that since 1.5.1, and the changes which went into the idl build makefiles, it seems there's a problem building in parallel. Since 1.5.1 built fine and git built with MAKEOPTS="-j1", I doubt it's a Gentoo issue, but I'll stick to the topic of this bug from now on.
I installed the updated xpi from the nightly page and have attached the output. The error appears to be 32 (EPIPE).
I think I found (and fixed) the bug. The problem was the following: regardless of whether gpg-agent is used, Enigmail writes at least a "\n" character to stdin when signing an attachment. However, on fast systems, GnuPG can potentially already have signed the attachment at this point because the passphrase comes from gpg-agent, i.e. gpg is not guaranteed to run at the moment of writing to stdin.
I have now changed the logic such that nothing is written to stdin if gpg-agent is used. A new build is available from http://www.enigmail.net/download/nightly.php
Thanks, I haven't seen a reoccurance of the problem since the nightly build.