<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<br>
I have worked out how to reliably trigger the bug.<br>
<br>
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. <br>
<br>
yours<br>
John<br>
<br>
<br>
<div class="moz-cite-prefix">On 30/10/2013 06:56, Niko Tyni wrote:<br>
</div>
<blockquote cite="mid:20131029195603.GA25751@estella.local.invalid"
type="cite">
<pre wrap="">On Mon, Oct 28, 2013 at 08:05:01PM +0100, Salvatore Bonaccorso wrote:
</pre>
<blockquote type="cite">
<pre wrap="">otrs2 seems to have an anoying (not easy to reproduce bug), which was
reported against otrs2 (and which seems to appear after the perl
5.14.2 -> 5.18.1 update):
<a class="moz-txt-link-freetext" href="http://bugs.debian.org/724972">http://bugs.debian.org/724972</a>
<a class="moz-txt-link-freetext" href="http://bugs.debian.org/726600">http://bugs.debian.org/726600</a>
Does this sound somewhere familiar to you, or does this ring a bell?
</pre>
</blockquote>
<pre wrap="">
Yeah, Patrik mailed me about it too, I just didn't have the time earlier.
John Seymour's comment in
<a class="moz-txt-link-freetext" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726600#75">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726600#75</a>
seems helpful:
[Tue Oct 22 11:56:15 2013] -e: Strings with code points over 0xFF may not be mapped into in-memory file handles
[Tue Oct 22 11:56:15.193665 2013] [:error] [pid 8510] [Tue Oct 22 11:56:15 2013] -e: open body: Invalid argument at /usr/share/perl5/MIME/Entity.pm line 1878.\n
A similar failure can be triggered with something like this:
perl -CO -Mstrict -we 'my $a = "\x{2660}"; open(my $h, ">>", \$a) or die "open failed: $!"; print $h "test\n"; close $h; print $a'
which dies with 5.18 but not with 5.14.
This is by design: the relevant perl5180delta entry is
PerlIO::scalar has been upgraded to 0.16.
The buffer scalar supplied may now only contain code pounts 0xFF or
lower. [perl #109828]
and the change is
<a class="moz-txt-link-freetext" href="http://perl5.git.perl.org/perl.git/commit/02c3c86bb8fe791df9608437f0844f9a8017e3b6">http://perl5.git.perl.org/perl.git/commit/02c3c86bb8fe791df9608437f0844f9a8017e3b6</a>
which was thoroughly discussed in the aforementioned ticket
<a class="moz-txt-link-freetext" href="https://rt.perl.org/Public/Bug/Display.html?id=109828">https://rt.perl.org/Public/Bug/Display.html?id=109828</a>
So the reproducing recipe presumably involves non-ASCII, non-latin1
characters in the ticket. Hope that helps a bit.
Not sure if this is a bug in MIME-Tools. My half hearted attempts to
trigger it by parsing a crafted UTF-8 email message weren't successful
(meaning MIME-Tools was behaving more or less correctly.)
So it needs something more complex to show up. I see OTRS,
Kernel/System/Encode.pm in particular, is using the Encode internal
functions _utf8_on() and _utf8_off() quite a bit. The root
problem might be somewhere there.
I can look at it more (time permitting) if somebody finds a way to
reproduce it.
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font color="gray" face="Verdana" size="2"><b>John Seymour</b><br>
<font color="gray" face="Verdana" size="1">Research Physicist
and NAL IT Manager<br>
<br>
<a href="http://www.nal.gov.au/">National Acoustic
Laboratories</a><br>
<font face="Arial"><i>A Division of Australian Hearing</i></font><br>
<br>
Australian Hearing Hub<br>
16 University Avenue<br>
Macquarie University NSW 2109 Australia<br>
P +61 2 9412 6839<br>
F +61 2 9412 6769<br>
M 0428886661<br>
<br>
<font color="green" face="Comic Sans MS" size="2">Please
consider the environment before printing this email</font>
</font></font></div>
</body>
</html>