[ic] [interchange] Fix potential "use of uninitialized value" if called during startup

[Jon Jensen]

On Fri, 23 Jun 2017, Mike Heins wrote:

>> David makes a good point: Because TLS 1.2 is required for PCI DSS, and 
>> because older Perl systems are built on older OS/distros with old 
>> OpenSSL, and because almost all Interchange usage is for ecommerce, it 
>> is probably a good time for us to consider raising the minimum Perl 
>> version. We have not done this for many years, so it's a good time 
>> anyway. We should increase the Interchange release to 5.12 to indicate 
>> the break in backward compatibility.
>>
>> RHEL/CentOS 6 is the oldest supported in that family, and include TLS 
>> 1.2 and Perl 5.14.1. RHEL/CentOS 7 comes with Perl 5.16.3.
>>
>> Debian 7 is the oldest supported in its family, in its LTS phase. It 
>> came with Perl 5.14.2. Debian 8 comes with Perl 5.20.2, and 9 with 
>> 5.24.1.
>>
>> Ubuntu 14.04 is the oldest supported, with Perl 5.18.2. Ubuntu 16.04 
>> has 5.22.1.
>>
>> Based on the lowest common denominator of the above, I propose we 
>> increase the minimum Perl version to 5.14.1. That's still 6 years old, 
>> from 2011!
>
> I am against this unless there is significant feature content added by 
> increasing the minimum version. Allowing // in one or two places doesn't 
> meet that bar to me.

I certainly understand the desire to avoid change for change's sake. It's 
tedious dealing with upgrades anyway, without adding unnecessary pain. 
There's a balance to be struck between bleeding-edge and dead.

This is a lot bigger than // - that's just one example of an over 
decade-old basic Perl operator that we still can't use in core 
Interchange. Even without making a big list of desired newer Perl features 
we want to use, it's tiresome to be stuck on such ancient perls and have 
to keep track of what syntax worked in the old days and what didn't.

The only supported versions of Perl right now are 5.24 and 5.26. 
Everything else is end of life. The reason we can sanely support back to 
5.14 is the long-term support Linux distros maintain their old versions 
with backported patches, so at least serious security and bug fixes are 
covered there. Anyone building their own perl should be watching those 
Linux perl maintainers' release notes to see if there are important things 
that should be backported to their own perl.

By way of comparison:

Perl 5.6.0 was released in March 2000, and less than 3 years later in 
early 2003 Interchange began requiring 5.6 or later.

Perl 5.8.5 was released in July 2004, and about 4 years later in late 2008 
Interchange began requiring it.

If we bump our minimum version requirement only up to 5.14.1, that will be 
the most tolerant we've ever been upon requiring a newer version: a full 6 
years old. We can't use OpenSSL that old. Web servers that old won't 
support HTTP/2. OpenSSH that old doesn't work with newer key types. Etc.

Imagine if, in the year 2008, we had still been trying to support a 
13-year-old Perl version. That would mean Perl 5.002. Anyone who was 
around back then can imagine what a pain that would be. To those who are 
used to more recent Perl versions now, it's the same feeling. Lots of 
little annoyances that add up.

> If you go above 5.8, you are basically consiging yourself to using 
> global Perl, as you will have myriad runtime require problems introduced 
> by 5.10 and above.

That is true, and it is highly annoying. Since it's clearly not a 
temporary blip, I think we need to cope with it and completely make the 
move as a group. Most of us have already had to do that during upgrades, 
and we're not doing the rest of the userbase any favors by not having 
Interchange work comfortably with current Perl.

The old OS versions are dead. Moving to a new supported OS version should 
mean getting a more current Perl build. Most people on an old Perl would 
also have an end of life distro, Perl, and CPAN modules. If that's what 
someone wants, they're of course free to do that, and can just as well use 
an unsupported older version of Interchange. And even backport later fixes 
if they want.

I didn't think I cared that much about this but apparently I do, based on 
how long this is getting. I feel it is becoming urgent for Interchange to 
get with the times on the Perl front.

Interchange is nothing without Perl. If everything has to be global to 
work with newer Perl versions, then we should just accept that's the way 
things have gone with Perl and deal with it. We should do what we can to 
make working with a current OS, Perl, CPAN modules, as easy as possible, 
since most people on ancient versions aren't upgrading their Interchange 
either.

So everyone please speak up on this: Who is still using Interchange with 
Perl older than 5.14.1 and why?

If the only reason is that it's running on an end-of-life server OS that 
you need to migrate away from anyway: Have you tried to keep using the 
outdated, unsupported Perl on a newer server OS? Have you gotten the old 
CPAN modules to work with newer glibc and other libraries?

Jon


-- 
Jon Jensen
End Point Corporation
https://www.endpoint.com/