Am 03.11.2013 15:04, schrieb Niko Tyni:
tag 726600 - moreinfo unreproducible
reassign 726600 libmime-tools-perl 5.504-1
thanks
On Fri, Nov 01, 2013 at 08:17:03AM +1100, John Seymour wrote:
I have worked out how to reliably trigger the bug.
If you enter a Unicode character in the the "system standard
signature" and reply to a ticket that uses that signature the bug
will be triggered.
Thanks. It doesn't need a signature in my tests, just replying to a bug
and copy-pasting non-latin1 chararacter to the text field triggers it.
It can be reduced to this:
% perl -w -MMIME::Entity -e 'print MIME::Entity->build(Data =>
"\x{2660}")->body_as_string'
Strings with code points over 0xFF may not be mapped into in-memory file
handles
open body: Invalid argument at /usr/share/perl5/MIME/Entity.pm line 1878.
or just
% perl -w -MMIME::Body -e 'MIME::Body::InCore->new("\x{2660}")->open("r") or die
"open failed: $!"'
Strings with code points over 0xFF may not be mapped into in-memory file
handles
open failed: Invalid argument at -e line 1.
I'm reassigning this against libmime-tools-perl again - if this is an
intentional limitation there, it should at least be documented better.
Preferrably, I suppose MIME::Body::InCore should transparently encode
Unicode data before making an in-memory file out of it. (This needs to
be discussed upstream, of course.)
In this case, OTRS hits it in Kernel::System::Email::Send() when it gets
a body containing HTML elements that map onto non-latin characters,
for instance ♠ . The $Self->{HTMLUtilsObject}->ToAscii() call
around line 288 of Kernel/System/Email.pm then converts the elements into
Unicode characters, which are later passed to MIME::Entity->build() as-is.
If necessary, OTRS could work around the problem by encoding the string
first. It already does for some cases, around line 316 or so:
# body encode if utf8 and base64 is used
if ( $Header{Encoding} =~ /utf(8|-8)/i && $Header{Encoding} =~ /base64/i )
{
$Self->{EncodeObject}->EncodeOutput( \$Param{Body} );
}
Making this EncodeOutput() call unconditional fixes the crash for me,
probably at the cost of some double encoding later. (I don't use OTRS
myself so I didn't really test that any further, but it seems too simple
minded to be a proper fix.)
Much thanks for working this out, I have also sent the information to
OTRS upstream, so that they also could workaround this problem.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
