Re: Debugger issue solved (two years ago)

[eyepopslikeamosquito]

Hi talexb,

I was a bit surprised to see you fiddling with the system Perl on Ubuntu.

• Re: Prefer Pure Perl Core Modules by Fletch - warns if you're doing anything serious with Perl you DO NOT want to use the OS system perl as that way lies much pain
• Re^2: Trouble with MCPAN by stevieb - highly recommends using a perlbrew perl for your own tasks, leaving the system perl alone

Like Fletch and stevieb, I strongly prefer to leave the system perl alone and build my own perl (as non-root) that I can safely control, and experiment with, and install CPAN modules to, without risking breaking my Unix system. Conversely, Fletch notes that relying on the system perl couples you tightly to the OS' upgrade schedule, for both the language and CPAN modules ... so a "harmless" OS upgrade can potentially break your mission-critical systems, if they are using the system perl.

I also wonder if your Ubuntu system perl has patched the perl v5.34.0 security vulnerabilities described here.

In case it's of use, this node contains a detailed example of securely building perl from source on Ubuntu.

[haj]

I also wonder if your Ubuntu system perl has patched the perl v5.34.0 security vulnerabilities described here.

Ubuntu Perl does apply CVE-related patches. Here's my list from 5.34, perl -V:

DEBPKG:CVE-2020-16156-1.patch - [PATCH] bugfix: signature verification
+ type CANNOT_VERIFY was not recognized
DEBPKG:CVE-2020-16156-2.patch - [PATCH] Add two new failure modes base
+d on cpan_path
DEBPKG:CVE-2020-16156-3.patch - [PATCH] use gpg --verify --output ... 
+to disentangle data and signature
DEBPKG:CVE-2020-16156-4.patch - [PATCH] replacing die with mydie in th
+ree spots
DEBPKG:CVE-2020-16156-5.patch - [PATCH] disambiguate the call to gpg -
+-output by adding --verify
DEBPKG:CVE-2020-16156-6.patch - [PATCH] s/gpg/$gpg/ in system, add quo
+tes where needed
DEBPKG:CVE-2020-16156-7.patch - [PATCH] s,/dev/null,$devnull,
DEBPKG:CVE-2023-31484.patch - [PATCH] Add verify_SSL=>1 to HTTP::Tiny 
+to verify https server identity
DEBPKG:CVE-2023-47038.patch - [PATCH 1/2] Fix read/write past buffer e
+nd: perl-security#140
DEBPKG:CVE-2022-48522.patch - [PATCH] Don't try to Sv[PI]V() on an und
+ef index SV in find_uninit_var()

...plus 50 non-CVE related patches.

[hippo]

a "harmless" OS upgrade can potentially break your serious mission-critical systems

This is true of anything running on the machine whether using system perl, user-built perl or not using perl at all. If this is the sort of thing which concerns you then you may as well go the whole hog and containerise your perl and applications.

I'm in the opposite school here and am perfectly happy to use the system perl, perhaps because I am also the sysadm and therefore my O/S upgrades are planned rather than being surprise events. This ensures that all my applications can be tested in development on the new O/S before the upgrade gets anywhere near to production. It's the approach I have been following for many years (the last user-built perl I used in production was 5.6.0) and has proven solid.

[talexb]

Thanks for your concern -- this is a new (refurbished) machine that I received about a month ago, and on which I installed the latest Ubuntu. I'm the SysAdmin on this machine, as well as the only developer -- my client is happy that I have complete control over this machine, installing any packages and modules that I think I need.

The only change to the system Perl I've made is to fix this problem in the debugger, since I use the debugger when I test. There's no development or staging environment -- the machine is 100% production, but with some tweaks I'm able to have scripts run in development mode. (This gives me an idea for a Lightning Talk. Hmm.)

The two CVEs listed in the node you mention are interesting, but they don't apply in my case. For the first CVE, I don't accept regexes from users; the eco-system I've set up has some CGIs, but they accept SKUs only, as entered by staff. Customers never see or have access to this server. And the second CVE only applies to Windows, so it's irrelevant.