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

[Paul Harvey]

For the Foswiki project, we can deal with things as-is.

But you have created a new bug, Locale::Maketext 1.23 is being shipped 
as 1.19 and I still don't see how this can ever be a good idea. These 
two versions have different version numbers for a reason: there has been 
a deliberate change which the caller must consider carefully before use. 
If the caller can't trust the API version being reported, what is the 
point of version numbers in the first place?

Our hack to detect Debian's special franken-version is exactly that, a 
hack - and additional complexity we'd very much rather not incur at 
runtime. Or complicate by pre-computing from yet another admin/configure 
UI prompt which could get out-of-sync should liblocale-maketext be 
updated (resulting in double-escaping mess until the user re-runs 
configure UI).

Perhaps I don't know enough about Debian infrastructure but how can this 
situation be easier to deal with than simply updating the rest of the 
.pm including the $VERSION string and POD lines? Especially given that 
your own grepping hasn't exactly overwhelmed with many dependencies on 
Locale::Maketext.

We always try very hard to work with vendor perls, which as you probably 
know, isn't the done thing - try telling perlmonks or #perl on freenode 
you've got this kind of problem, and you'll be asked what kind of idiot 
doesn't compile their own local perl.

Then try telling our userbase they must compile and maintain their own 
local perl.

I didn't start this message intending to drag out my soapbox - I just 
think it's tragic there has to be such a large impedance mismatch 
between distros and perlers.

Thanks for listening

- Paul

On 24/03/13 23:19, Dominic Hargreaves wrote:
> 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.
>