Bug#695224: perl-modules: Locale::Maketext code injection

Dominic Hargreaves dom at earth.li
Sun Mar 24 12:19:59 UTC 2013


Hi Paul,

Sorry for the delay in responding to this...

On Mon, Mar 11, 2013 at 02:37:31PM +1100, Paul Harvey wrote:
> Hi there,
> 
> On Fri, Jan 18, 2013 at 03:06:38PM +0000, Dominic Hargreaves wrote:
> ...
> > Debian stable. As such I'd be very interested in hearing from anyone
> > who has real world examples of this breaking things.
> 
> It's worth pointing out that you've now got Locale::Maketext 1.23,
> minus the doc changes and version bump. That's the only real code
> change between 1.19 and 1.23 - so calling this 1.19 makes life
> harder for projects like Foswiki to sanity-check the users'
> environment.

This is a regrettable state of affairs, indeed. 

> Take a look at the Locale::Maketext 1.19..master diff for yourself:
> https://github.com/toddr/Locale-Maketext/compare/84a644...master
> 
> Compared to the diff which I think was applied in perl-modules:
> 
> http://perl5.git.perl.org/perl.git/blobdiff/569ba91fcdabdc53eb4284f860a25273bd7fe4e1..1735f6f53ca19f99c6e9e39496c486af323ba6a8:/dist/Locale-Maketext/lib/Locale/Maketext.pm
> 
> Foswiki uses Locale::Maketext when internationalization is enabled,
> so we've had our own CVE response -
> http://foswiki.org/Support/SecurityAlert-CVE-2012-6329.
> 
> As part of the fix, we perform additional escaping before calling
> Locale::Maketext if the version is < 1.23.
> 
> The Debian-patched 1.19 of course already has the escaping code, so
> we end up with double-escaping issues.
> 
> As we're now getting user complaints on Debian systems, we will have
> to come up with a technical solution to this problem but I think
> it'd also make sense for Debian to simply ship Locale::Maketext 1.23
> proper.

There's a bit of an awkward issue here in that Locale::Maketext is
bundled with perl, and although I agree it is potentially confusing
to have these sorts of changes applied without version number changes,
changing the version number on the Debian branch is quite likely to be
the source of even more confusion; I don't think there's any precedent for
doing that with a dual-lived module. Practically speaking, I think we will
need to stick with what you'd probably term a workaround, which I assume
is to do some sort of probe for behaviour before using it for real?

Interested in hearing opinions from others, however!

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)




More information about the Perl-maintainers mailing list