[dev] quoted-printable-encode issue (Was Re: [commits] Horde branch master updated. 96483e0d91a027c338b703995e0b123b31684488)

[Michael J Rubinsky]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>
>>> commit 4faaf153875911d05a2329f693ff767cefdc2e7c
>>> Author: Michael J Rubinsky <mrubinsk at horde.org>
>>> Date:   Mon Sep 23 11:24:56 2013 -0400
>>>
>>>   This seems to prevent a PHP bug from being triggered.
>>>
>>>   Without hex-encoding of control characters, PHP is segfaulting on
>>>   numerous platforms with certain strings. Still working out the
>>>   exact string combinations that trigger this for reporting to PHP.
>>>
>>> framework/Mime/lib/Horde/Mime/Part.php |    3 ++-
>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> http://github.com/horde/horde/commit/4faaf153875911d05a2329f693ff767cefdc2e7c
>>> http://git.horde.org/horde-git/-/commit/4faaf153875911d05a2329f693ff767cefdc2e7c
>>
>> This is being reverted.  You can't do this.  This breaks things  
>> like generating PGP and flowed messages, where spaces MUST NOT be  
>> encoded in quoted-printable data.  To say nothing of the size of  
>> messages sent now (this is way less efficient than base64).
>>
>> The correct fix would be to manually change the encoding of the  
>> part to base64 at the location you are seeing issues until you can  
>> figure out the problem.  However, the solution is not to cripple  
>> the software for everyone else that is using it normally.
>
> Yeah, sorry about this. I spent over 8 hours tracking down this  
> issue with a very anxious client. Was just happy that I finally  
> found something that stopped the segfaults.
>
> I've tracked this down to the point that it is triggered by a bare  
> CR at the end of the string, while all other line endings are CRLF  
> (so line-break-chars is set to CRLF), but only if the string is a  
> certain size, and with certain values of line-length.  My guess:  
> Since the stream's line endings are detected to be CRLF, but there  
> exists a *single* bare CR, this screws up the internal calculations  
> for line-length leading to some sort of overflow or divide-by-zero  
> error internally.

Ok. Going to report this to the PHP folks, but, Michael, can you take  
a look at this test case and double check that this makes sense? The  
following code segfaults:

$data = fopen('php://temp', 'r+');
fwrite($data, "test\r\ntest\r\n\r");

$stream = fopen("php://temp", 'r+');
stream_filter_append($stream, 'convert.quoted-printable-encode',  
STREAM_FILTER_WRITE, array('line-length' => 5, 'line-break-chars' =>  
"\r\n"));
rewind($data);
stream_copy_to_stream($data, $stream);

while changing the line-length to pretty much any other value, or  
changing line-break-chars to "\r" does not.


Thanks.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20130927/87e76011/attachment-0001.bin>