New blank lines introduced after a reply
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
Hallo everyone,
I've been facing this problem since a while.
I use Enigmail under Thunderbird.
Everything is updated with the latest releases.
If someone send me an email encrypted and signed, I received it correctly.
If I do a reply, encrypted and signed, of that email, the recipient will receive the reply wit additional blank lines after each original message line.
Is Are there setting related to this effect?
Any suggestion to fix it?
Thanks
Roberto
Hi CodeVisio,
Apparently the sender's message has an additional CR+LF character at the end of each line. Which OS you and your correspondent are using?
Hi Daniele,
I have Windows. I'll check which OS the recipient uses because I'm not sure.
By the way, what do you mean exactly by 'additional CR+LF'?
Assuming on Windows, do you mean that every time the user presses the enter key, a couple of control characters CR+LF is inserted twice?
Thanks
CR = Carriage Return, LF = Line Feed.
No, I mean that the control characters at the end-of-line are interpreted differently depending on the platform. It's a common problem when handling text between different OSes.
Yes, but there should be no user interaction on the receivers side. In any case: There is no setting you can tweak - this is a malfunction on either the sending or the receiving end.
I have been having the same problem recently and I figured out that this is not a problem of Enigmail or Thunderbird, but GnuPG for Windows. I had been using the Cygwin GPG executable for years when a while ago, Enigmail started to display a warning message stating that the GPG version I was using was deprecated. After switching, I had the exact same problems as described above. I opened an issue here:
https://bugs.gnupg.org/gnupg/issue2060
So the gpg4win people would like me to reproduce the problem on the commandline. Could someone tell me how to find out what enigmail passes to the command line so the problem becomes reproducable?
From the menu option Enigmail -> Debugging Options you can view both the Console and the Log.
Thanks for the tip, but this is not helping as much as I hoped it would. If I use the commands used by enigmail from the console and provide a text written in Notepad++, the problem is not reproducable: Everything works as it should.
I need to have an exact copy of the data that is passed to GPG when I encrypt the email containing a quoted reply. Something must have happened to the text that makes it different from what I am writing in Notepad++.
I can get the source code of the email I receive, but that is not helping. I need the "source code" of the email which is being composed after I hit "reply".
Is there any way to get that data?
No, the data passed to GnuPG is not extractable without changing the source code of Enigmail.
Which type of editor do you use in Thunderbird (HTML or plain text)? What happens if you press the shift key (on the keyboard) while clicking on the reply button (with the mouse)?
I am composing everything in plaintext by default and also in all of the scenarios described. Therefore, when I hold the shift key while clicking "reply", I respond as HTML.
Jesko, which version of Thunderbird, Enigmail and GnuPG are you using? Which version of windows?
Sorry for the late response, I was on holiday. I am using Windows 2008 R2 SP1, Standard, fully updated. My Enigmail Version is 1.8.2 (20150416-1748) inside a Thunderbird is 38.2.0.
Which version of GnuPG are you using exactly?
As stated in the GnuPG bug report which I linked, the version that I last used to reproduce the bug was 2.2.5. I also suggest to direct all GnuPG-related information to that bug report. The guys over there asked me to find a way to reproduce the problem from the command line, which is why I want to find out what enigmail passes to command line exactly.
The best (and only) way to find out is to replace GnuPG with a wrapper application that gets the output from Thunderbird. That's the only 1:1 copy that you can get.
I tried doing this by writing a tiny wrapper in C using popen(), but it does not work. I spent a day trying to make this work, to no avail. If you have any idea how to do it, that'd be great. Otherwise, I am out of ideas.
I'd recommend you start with the following source code and modify it to your needs.
https://sourceforge.net/p/enigmail/source/ci/enigmail-1-7-branch/tree/ipc/tests/IpcCat.cpp
After some work, I was able to make it work and was stunned to realize that the fault is actually not with gpg4win, or rather not directly: gpg4win already receives the text malformed, i.e. enigmail has somehow inserted blank lines before passing the data to gpg4win.
However, I noticed the following: When you encrypt data (and ASCII-armor it) using the cygwin gpg.exe, then the line endings are LF only. When you use gpg4win's executable gpg2.exe however, the line endings in the ASCII-armored ciphertext are CR+LF. I strongly suspect that this CR+LF is the cause of the bug. I am now rather certain that the bug is actually in enigmail and not in any of the gpg's because the blank lines are being inserted by enigmail before passing it to gpg. However, this only happens when the message is a response to something that was previously encrypted with gpg4win.
A solution might be for enigmail to transform CR+LF to LF after receiving a ciphertext from gpg?
I have the same problem on all my Windows machines (7 and 8.1) with Gpg4win and Enigmail 1.8.2.
I've seen it also when replying to mails encrypted by MacGPG2 and GPG v2 on Linux.
The problem is also reproducible when activating the confirmation dialog before sending, reply to an encrypted mail, clicking the send button but cancel it. When the ciphertext gets replaced with the processed plaintext all quoted lines (starting with >) have newlines in between them.
Another way: Reply to an encrypted mail, activate signing and click send. The message updates with the empty line version while the dialog is waiting for the private key passphrase. This shows that the bug is not in Gpg4win but in Thunderbird or Enigmail.
After looking at the code and debugging a while it seems that the encrypted quote is correctly decrypted (with CRLF line endings) when opening the new reply window and given to
Enigmail.msg.editorInsertAsQuotation(). The decrypted quote looks correct in the editor window, but when read withEnigmail.msg.editorGetContentAs()you get the empty lines (independent if called withOutputLFLineBreak,OutputCRLineBreakor none of both).Last edit: d1rgdz 2015-10-03
Which version of gpg4win / GnuPG are you both (Jesko and d1rgdz) using precisely?
I said this before already, I observed this bug first when switching from cygwin's gpg to gpg4win version 2.2.5 (enigmail was complaining about the gpg from cygwin being too old).
I now use gpg4win version 2.2.6, still the same problem. Method to reproduce the bug:
1) Send an encrypted mail to yourself containing several lines
2) Receive that email
3) Respond to that email (to yourself)
I'm using: gpg (GnuPG) 2.0.29 (Gpg4win 2.2.6)
Another method to reproduce the bug: Press reply on an encrypted mail, wait for the quoted text to decrypt, select everything and copy it in a text editor. In the Thunderbird window the quoted message looks fine, but when copied the empty lines are there. My guess is that the empty lines are somewhere added while executing
Enigmail.msg.editorInsertAsQuotation().I can reproduce this with messages created by gpg4win 2.2.5 and 2.2.6 (GnuPG 2.0.27 and 2.0.29), but not with messages created by gpg4win 2.2.4. This is a GnuPG bug, as GnuPG is supposed to always produce identical output, no matter of platform or application version.
I suspect it's the same sort of bug that is in GnuPG 2.1.7. This was fixed in a library that is also used in GnuPG 2.0.x; see here for details: https://lists.gnupg.org/pipermail/gnupg-devel/2015-August/030234.html
I recommend that you downgrade to gpg4win 2.2.4, available from here:
http://files.gpg4win.org/gpg4win-2.2.4.exe