PGP/MIME signed message with user signature fails in thunderbird

A mail with IMP standard mechanism to append a user defined

Sat, 01 Feb 2014 15:46:55 +0000

A mail with IMP standard mechanism to append a user defined signature (delimited with "-- \n") is sent addionally signed with PGP. The verification of the signature is successful in IMP and mutt, but fails in thunderbird/enigmail. The problem is reported to enigmail (see also for details https://sourceforge.net/p/enigmail/bugs/248) but meanwhile i got stuck in the discussion if the trailing blank in the signature delimiter is correct or not. Although i tend to the opinon that this is not a problem of Horde/Imp i have to admit that my level of competence is exceeded. Please continue the discussion with enigmail by a Horde developer to achieve a mutually agreed pragmatic solution.

http://tools.ietf.org/html/rfc3676#section-4.3 There i

Tue, 04 Feb 2014 05:36:20 +0000

http://tools.ietf.org/html/rfc3676#section-4.3 There is a long-standing convention in Usenet news which also commonly appears in Internet mail of using "-- " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted or quoted and stuffed) line consisting of DASH DASH SP is neither fixed nor flowed. IMP correctly sends this separator (i.e. in flowed mode, we do NOT add an additional space at the end of the line).

> IMP correctly sends this separator (i.e. in flowed mode, w

Tue, 04 Feb 2014 05:37:43 +0000

> IMP correctly sends this separator (i.e. in flowed mode, we do NOT > add an additional space at the end of the line). Meaning IMP sends "--[SP]", not "--[SP][SP]" as would be expected under the other flowed rules.

"--[SP]" is just the problem. To make thunderbird/enigmail r

Sat, 08 Feb 2014 12:38:37 +0000

"--[SP]" is just the problem. To make thunderbird/enigmail run pgp validation successfully you have to deselecet the usenet style signature tag. For the user this dependency is not obvious and causes mistrust to the horde/pgp-functions. Thunderbird/Enigmal refers to RFC3156 and Horde quotes from RFC3676 and the problem persists.

> "--[SP]" is just the problem. To make thunderbird/enigmail

Mon, 10 Feb 2014 05:50:59 +0000

> "--[SP]" is just the problem. To make thunderbird/enigmail run pgp > validation successfully you have to deselecet the usenet style > signature tag. For the user this dependency is not obvious and causes > mistrust to the horde/pgp-functions. Why do you have to do this? There's no reason to. In fact, we could send signature separators as "--[SP][SP][SP][SP][SP][SP][SP]" if we wanted to. It's totally irrelevant. There is no limitation on trailing spaces within the actual PGP-MIME data itself. (There's a limitation on trailing spaces **AFTER** content-transfer encoding has been employed. But that's a totally different topic, and not an issue here since we protect trailing spaces by using q-p encoding.) > Thunderbird/Enigmal refers to RFC3156 and Horde quotes from RFC3676 > and the problem persists. Please read 3676. It refers to precisely this issue, while directly referencing 3156. In short, there is nothing wrong with trailing spaces for ANY data (let alone signature separators) as long as you are using OpenPGP-MIME (instead of raw OpenPGP format).

This is a good time to move the logic ensuring the text part

Mon, 10 Feb 2014 06:30:14 +0000

This is a good time to move the logic ensuring the text parts are Q-P encoded from the MUA into the library itself, if just for abstraction purposes and for cleaner code. But the point remains that trailing spaces remain perfectly legal and expected in OpenPGP-MIME signed data.

After some tests with plain text mail encoding and PGP it sh

Sat, 15 Feb 2014 15:46:33 +0000

After some tests with plain text mail encoding and PGP it shows that automatically flowtext inserted line breaks will also destroy signature detection in thunderbird. E.g. the phrase "[SP]gestern[SP]bei[SP]" got broken to "[SP]geste=[LF][SP][SP][LF]rn[LF]bei[SP]" (hex: 20 67 65 73 74 65 3d 0a 72 6e 20 20 0a 62 65 69 20 ) For me the problem became more serious because plain text encoding with pgp seems to be not usable in combination with thunderbird reception. My workaround is to use html encoding.

> E.g. the phrase "[SP]gestern[SP]bei[SP]" got broken to

Tue, 25 Feb 2014 06:53:27 +0000

> E.g. the phrase "[SP]gestern[SP]bei[SP]" got broken to > "[SP]geste=[LF][SP][SP][LF]rn[LF]bei[SP]" (hex: 20 67 65 73 74 65 3d > 0a 72 6e 20 20 0a 62 65 69 20 ) What version of PHP? The PHP quoted-stream stream filter was broken until recently - I provided a stream of patches upstream to PHP to fix the issue. i.e. this sounds exactly like this issue: commit 600d6deef9c8983eb8023171c6c5ae90ca60b6c1 Author: Michael M Slusarz Date: Thu Feb 7 12:37:52 2013 -0700 Fix #64166: quoted-printable-encode stream filter incorrectly discarding whitespace If trailing whitespace on a line is detected, mark the linebreak as a soft linebreak. You should be using at least PHP 5.4.25 when testing.

You need at least PHP 5.4.17/5.5.0 (Bug #64166): http://www

Tue, 25 Feb 2014 06:58:48 +0000

You need at least PHP 5.4.17/5.5.0 (Bug #64166): http://www.php.net/ChangeLog-5.php#5.4.17 https://bugs.php.net/bug.php?id=64166 And due to partial regression introduced with original fix, you really need at least 5.4.20/5.5.4 to work properly: http://www.php.net/ChangeLog-5.php#5.4.20 https://bugs.php.net/bug.php?id=65483

My php version is 5.4.4 (Debian 7) - looks like the problem

Tue, 25 Feb 2014 18:08:13 +0000

My php version is 5.4.4 (Debian 7) - looks like the problem is related to this version.

> My php version is 5.4.4 (Debian 7) - looks like the proble

Thu, 27 Feb 2014 06:23:43 +0000

> My php version is 5.4.4 (Debian 7) - looks like the problem is > related to this version. Are you going to be able to upgrade to test? Otherwise, I will close this ticket.

Currently i have no test system available to run an upgraded

Thu, 27 Feb 2014 18:28:22 +0000

Currently i have no test system available to run an upgraded php. Please close the ticket and thanks for your support.

This issue persists. Could you please check the most recent

Wed, 24 Sep 2014 18:20:20 +0000

This issue persists. Could you please check the most recent comments on http://sourceforge.net/p/enigmail/bugs/248/ and consider reopening this issue?

What is there to reopen? As this ticket history indicates,

Wed, 24 Sep 2014 18:27:25 +0000

What is there to reopen? As this ticket history indicates, the only issue would be that you are using a broken version of PHP. I can verify there are no issues with sending messages with a current version of IMP using a non-broken PHP version.

Sorry, I read the ticket from top to bottom, so I thought th

Wed, 24 Sep 2014 21:31:38 +0000

Sorry, I read the ticket from top to bottom, so I thought that the php version was not the solution. This is really a strange order for the comments. I will check the php version. Anyway, I still think that this should be fixed in Horde. Sometimes it is not possible to update php on managed servers. In my humble opinion, Horde should not create broken signatures then. It should either say that creating signatures is not supported with this version of php, or there should be a workaround which e.g. removes spaces before signing or whatever. However, creating broken signatures is really a bad thing to do.

> Anyway, I still think that this should be fixed in Horde.

Thu, 25 Sep 2014 00:23:22 +0000

> Anyway, I still think that this should be fixed in Horde. Sometimes > it is not possible to update php on managed servers There are two alternatives: 1.) Update PHP. The issue has been fixed. This requires no further development work. 2.) Write a new quoted-printable encoding backend. Not only would this be *many* times less efficient than the PHP C-based version, but it is unneeded (see #1), but it would require significant developer resources to do something that has already been fixed. If someone wants to pay me to do option 2, I would gladly do it. I don't see how it is my (or anybody else's) responsibility to do this though when the issue has already been fixed the correct way (option 1). (see, e.g., the current releases of PHP, which have totally broken SSL behavior. The correct resolution is to fix PHP, not for us to try to workaround this behavior)