Re^3: Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38)

Make sure to document your objections in writing to the responsible person(s), dateable documents are best. Send them an email to the list of Perl security vulnerabilities, so the have no excuse of "i didn't know" if the fit hits the shan.

If possible, you should also print your correspondance re. the security issues of old Perl versions on a color laser printer. Those printers usually encode some metadata in nearly invisible yellow dots all over the pages, this makes it easier to prove when the documents were printed. Just in case there IS a larger issue that leads to a lawsuit. Data breaches and similar things are hugely expensive, so the company might try to sue you as a scapegoat. Depending on your jurisdiction, you might even be held criminally liable, since you were knowingly running an insecure system.

So be careful with this stuff.

Sidenote: Personally, i always make sure i require the latest major Perl release in my commercial source code. This helps make sure that the systems HAVE to be upgraded ;-)

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my rather simple sketches/one-panel comics

Comment on Re^3: Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38)

Replies are listed 'Best First'.
Re^4: Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38) by stevieb (Canon) on Jul 05, 2024 at 10:16 UTC
Just in case there IS a larger issue that leads to a lawsuit Your software license can mostly protect you from such issues. If you sell proprietary software commercially, you may be on the hook. If you sell services and support for your Open Source licensed software but don't specifically sell the software itself, it's generally a nice ride ;) I would hazard a guess that probably 50/60 of my CPAN distributions run under 5.8. A few require 5.10. There may be one or two that need 5.10+. IMHO it's not up to the developer to write software to force people to upgrade, it's my job to be as compatible as possible. To me, it boggles the mind that someone would try to use a Perl version that has been unsupported, insecure and end-on-life for a decade now. What's next, running your companies website on an Windows NT server? Trying to force upgrades is a fools errand. Policies, politics, infighting, nonsense, ego, money, you name it, you'll come across it. I was a sysadmin once, trying to advocate for compliance to no end (in the financial/gaming industry even). As we see over and over, companies just won't spend on upgrades until they've been exploited. Until you've done work for a billion dollar corporation where you get to see the problems from the inside, disgust and frustration as to the 'why' will be the case. Write software for the lowest common denominator of users, while at the same time promoting why certain changes would be best. Just because my software will run on 5.8 doesn't mean it won't run on 5.38, and that's the real point here... one doesn't need to force an upgrade, one just needs to position their software in a way that facilitates one. -stevieb	[reply]
Re^4: Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38) by Darkwing (Scribe) on Jul 05, 2024 at 08:40 UTC
Thank you for your advice!	[reply]