Bug 1029016 - Locale::Maketext interpolating escaped backslashes improperly
Summary: Locale::Maketext interpolating escaped backslashes improperly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: perl
Version: 5.10
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: perl-maint-list
QA Contact: Lukáš Zachar
URL: https://rt.perl.org/Public/Bug/Displa...
Whiteboard:
Depends On:
Blocks: 1049888
TreeView+ depends on / blocked
 
Reported: 2013-11-11 13:33 UTC by Petr Pisar
Modified: 2014-09-16 00:32 UTC (History)
4 users (show)

Fixed In Version: perl-5.8.8-42.el5
Doc Type: Bug Fix
Doc Text:
Cause: Translate a string with back-slash character using Perl Locale::Maketext localization framework. Consequence: Back-slashes become doubled. Fix: An upstream fix do unescape back-slashes in literal output strings has been applied. Result: A regression introduced by CVE-2012-6329 fix causing double-escaping some back-slash characters has been corrected.
Clone Of: 1025906
Environment:
Last Closed: 2014-09-16 00:32:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Upstream fix ported to 5.8.8 (3.20 KB, patch)
2014-02-11 12:35 UTC, Petr Pisar
no flags Details | Diff
Upstream fix ported to 5.8.8 (3.56 KB, patch)
2014-02-11 14:51 UTC, Petr Pisar
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1198 0 normal SHIPPED_LIVE perl bug fix update 2014-09-16 04:17:13 UTC

Description Petr Pisar 2013-11-11 13:33:24 UTC
+++ This bug was initially created as a clone of Bug #1025906 +++

Description of problem:
When a literal backslash is in an L10N value, it is treated nonuniformly by the Locale::Maketext::_compile method, as patched by RH in Locale::Maketext::Guts (per https://bugzilla.redhat.com/show_bug.cgi?id=884354).  The result depends on unrelated parts of the string.


Version-Release number of selected component (if applicable):
perl-5.10.1-131.el6_4.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create a language token, whose value is 'Some data\n'
2. Query the language token through Locale::Maketext ($lh->maketext($tag))

Actual results:
'Some data\\n'

Expected results:
'Some data\n'

Additional info:

The behavior changes in the following cases:
1) If the value contains a tokenized field, behavior depends on whether there is a trailing newline:

'[_1]Some data\n' => 'Some data\n'
'[_1]Some data\n'."\n" => 'Some data\\n
'
2) If the escaped backslash is in a function call, it behaves as expected:

'Some data[sprintf,\n]' => 'Some data\n'



NOTE: All of these cases in standard perl (with Locale::Maketext v 1.13 from CPAN) behave exactly the same as each other, and they all produce just a single '\' before the 'n'.

--- Additional comment from RHEL Product and Program Management on 2013-11-01 22:52:05 GMT ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Petr Pisar on 2013-11-04 12:16:19 GMT ---

The 'Some data\n' is due to back-porting the fix to perl 5.10.1.

The parameterized case behaves for me differently and is caused by the changes in the fix. Even latest Locale::Maketext is affected.

--- Additional comment from Petr Pisar on 2013-11-11 09:41:00 GMT ---

Fix accepted by upstream in slightly different form. Only this one is needed to fix the regression.

----

perl-5.8.8-42.el5 is affected.

Comment 2 Petr Pisar 2014-02-11 12:35:30 UTC
Created attachment 861777 [details]
Upstream fix ported to 5.8.8

Comment 3 Petr Pisar 2014-02-11 14:51:57 UTC
Created attachment 861801 [details]
Upstream fix ported to 5.8.8

This solves tests failure at "Unicode literal" test. This bug remained hidden in current upstream code because there is a special short path for literal strings.

Comment 4 Petr Pisar 2014-02-11 15:26:10 UTC
How to test: Use script from bug #1025906 comment 8. This is a upstream test I ported into perl 5.8.8.

Comment 9 errata-xmlrpc 2014-09-16 00:32:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1198.html


Note You need to log in before you can comment on or make changes to this bug.