Commit 329458a9 authored by Alex Vandiver's avatar Alex Vandiver
Browse files

Ensure that all calls to _EncodeLOB pass bytes, not characters

There are several places that call _EncodeLOB; most are careful to pass
bytes, not characters:

  1. RT::Attachment->Create takes a MIME::Entity; while the transfer
     encoding will have been decoded, ->bodyhandle->as_string does not
     decode bytes into characters.

  2. ObjectCustomFieldValues from file uploads; these are always left as
     bytes.

  3. ObjectCustomFieldValues from Content which is too long; Content is
     passed as characters.

The one codepath which currently might pass characters, and not bytes,
is the third possibility.  While the Mason parameter munging in
RT::Interface::Web ensures that invalid byte sequences (including for
invalid codepoints, like \x{FDD0}) are replaced using PERLQQ, there are
no such guards for character strings passed to ->AddCustomFieldValue
directly via the API.

Ensure that the LargeContent passed to _EncodeLOB, upgraded from
Content, contains bytes and not characters.
parent 74683a70
......@@ -118,7 +118,10 @@ sub Create {
$RT::Logger->error("Content is longer than 255 bytes and LargeContent specified");
}
else {
$args{'LargeContent'} = $args{'Content'};
# _EncodeLOB, and thus LargeContent, takes bytes; Content is
# in characters. Encode it; this may replace illegal
# codepoints (e.g. \x{FDD0}) with \x{FFFD}.
$args{'LargeContent'} = Encode::encode("UTF-8",$args{'Content'});
$args{'Content'} = undef;
$args{'ContentType'} ||= 'text/plain';
}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment