BUG: Corrupted binary attachments

Hi there!

Can you poke at the database to see if it’s correct as stored in the
database? (Is it being corrupted on input or output)On Thu, Apr 10, 2003 at 08:34:18AM +0200, Jo Meder wrote:

Hi there!

From my own experience I can definitely say, that binary attachments
have been corrupted in the web interface since we installed rt3 some
days ago.

Here’s a small example, the famous 1-pixel-GIF, first the original
file as it was attached to the email:

00000000 47 49 46 38 39 61 01 00 01 00 F0 00 00 00 00 00
00000010 00 00 00 21 F9 04 01 00 00 00 00 2C 00 00 00 00
00000020 01 00 01 00 40 02 02 44 01 00 3B

And now what you get when downloading this attachment from the rt3 web
interface:

00000000 47 49 46 38 39 61 01 00 01 00 C3 B0 00 00 00 00
00000010 00 00 00 00 21 C3 B9 04 01 00 00 00 00 2C 00 00
00000020 00 00 01 00 01 00 40 02 02 44 01 00 3B

As you can see the byte 0xF0 at position 0x0A in the file is changed to
0xC3 0xB0 and the byte 0xF9 at position 0x14 is changed to 0xC3 0xB9
resulting in a file which is larger by two bytes and has changed
“somewhat”.

Following this hint I generated a testfile containing all bytes from
0x00 to 0xff. This shows, that all values from 0x80 to 0xFF are
changed to a two-byte encoding:

00000080 C2 80 C2 81 C2 82 C2 83 C2 84 C2 85 C2 86 C2 87
00000090 C2 88 C2 89 C2 8A C2 8B C2 8C C2 8D C2 8E C2 8F
000000A0 C2 90 C2 91 C2 92 C2 93 C2 94 C2 95 C2 96 C2 97
000000B0 C2 98 C2 99 C2 9A C2 9B C2 9C C2 9D C2 9E C2 9F
000000C0 C2 A0 C2 A1 C2 A2 C2 A3 C2 A4 C2 A5 C2 A6 C2 A7
000000D0 C2 A8 C2 A9 C2 AA C2 AB C2 AC C2 AD C2 AE C2 AF
000000E0 C2 B0 C2 B1 C2 B2 C2 B3 C2 B4 C2 B5 C2 B6 C2 B7
000000F0 C2 B8 C2 B9 C2 BA C2 BB C2 BC C2 BD C2 BE C2 BF
00000100 C3 80 C3 81 C3 82 C3 83 C3 84 C3 85 C3 86 C3 87
00000110 C3 88 C3 89 C3 8A C3 8B C3 8C C3 8D C3 8E C3 8F
00000120 C3 90 C3 91 C3 92 C3 93 C3 94 C3 95 C3 96 C3 97
00000130 C3 98 C3 99 C3 9A C3 9B C3 9C C3 9D C3 9E C3 9F
00000140 C3 A0 C3 A1 C3 A2 C3 A3 C3 A4 C3 A5 C3 A6 C3 A7
00000150 C3 A8 C3 A9 C3 AA C3 AB C3 AC C3 AD C3 AE C3 AF
00000160 C3 B0 C3 B1 C3 B2 C3 B3 C3 B4 C3 B5 C3 B6 C3 B7
00000170 C3 B8 C3 B9 C3 BA C3 BB C3 BC C3 BD C3 BE C3 BF

Jo.


Internetmanufaktur Jo Meder ---------------------- Berlin, Germany
http://www.meder.de/ ------------------- fon: ++49-30-417 17 63 33
Kollwitzstr. 75 ------------------------ fax: ++49-30-417 17 63 45
10435 Berlin --------------------------- mob: ++49-170- 2 98 89 97
Public GnuPG-Key ---------- http://www.meder.de/keys/jo-pubkey.txt


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Am 10.04.2003, 08:38 Uhr
schr�b Jesse Vincent jesse@bestpractical.com:

Can you poke at the database to see if it’s correct as stored in the
database? (Is it being corrupted on input or output)

Ok, I had a look and it is definitely corrupted on input. The MTA is
Exim 3.36, mySQL is 3.23.53-log, Perl is 5.8.0

No additional software is used to transfer the data (except that it is
check for viruses by exiscan), just an entry in /etc/aliases

Jo.

Internetmanufaktur Jo Meder ---------------------- Berlin, Germany
http://www.meder.de/ ------------------- fon: ++49-30-417 17 63 33
Kollwitzstr. 75 ------------------------ fax: ++49-30-417 17 63 45
10435 Berlin --------------------------- mob: ++49-170- 2 98 89 97
Public GnuPG-Key ---------- http://www.meder.de/keys/jo-pubkey.txt

Am 10.04.2003, 08:38 Uhr
schrieb Jesse Vincent jesse@bestpractical.com:

Can you poke at the database to see if it’s correct as stored in the
database? (Is it being corrupted on input or output)

Additional info: The same data corruption happens if I insert a
comment to an existing ticket and attach a file via the web interface.

Jo.

Internetmanufaktur Jo Meder ---------------------- Berlin, Germany
http://www.meder.de/ ------------------- fon: ++49-30-417 17 63 33
Kollwitzstr. 75 ------------------------ fax: ++49-30-417 17 63 45
10435 Berlin --------------------------- mob: ++49-170- 2 98 89 97
Public GnuPG-Key ---------- http://www.meder.de/keys/jo-pubkey.txt

Am 10.04.2003, 16:04 Uhr
schr�b Jo Meder jo@meder.de:

Am 10.04.2003, 08:38 Uhr
schrieb Jesse Vincent jesse@bestpractical.com:

Can you poke at the database to see if it’s correct as stored in the
database? (Is it being corrupted on input or output)

Additional info: The same data corruption happens if I insert a
comment to an existing ticket and attach a file via the web interface.

Ok, after some looking around it is rather obvious that with our setup
here it seems like binary attachments get converted to utf-8 although
they’re marked as “application/octet-stream” or “image/gif” or whatever.

So after some digging around I came upon the following kludge to solve
the problem at least for now. You can try this if you don’t care about
utf-8 encoded text parts of emails.

In RT_Config.pm change:
@EmailInputEncodings = qw(iso-8859-1 utf-8 us-ascii);

Set($EmailOutputEncoding , ‘iso-8859-1’);

This is strictly “works for me”, so you’d better check if it doesn’t
break anything else in other setups.

Jo.

Internetmanufaktur Jo Meder ---------------------- Berlin, Germany
http://www.meder.de/ ------------------- fon: ++49-30-417 17 63 33
Kollwitzstr. 75 ------------------------ fax: ++49-30-417 17 63 45
10435 Berlin --------------------------- mob: ++49-170- 2 98 89 97
Public GnuPG-Key ---------- http://www.meder.de/keys/jo-pubkey.txt