This is the fix.

The removed subroutine still remained in comments and documentation, from where it was finally removed in 5.35.5.

The error was introduced somewhere around 5.17, and was fixed in 5.35.2.

Weird. I just tried on a different machine, and didn't see the 'v' error.

$ perl -v

This is perl 5, version 30, subversion 0 (v5.30.0) built for x86_64-li
+nux-gnu-thread-multi
(with 60 registered patches, see perl -V for more detail)

Copyright 1987-2019, Larry Wall
...
$ perl -d test_email.pl

Loading DB routines from perl5db.pl version 1.55
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

IO::Socket::SSL::CODE(0x5622464f7a78)(/usr/share/perl5/IO/Socket/SSL.p
+m:330):
330:            INIT { init() }
  DB<1> f test
Choosing test_email.pl matching 'test':

  DB<2> v
1       #!/usr/bin/perl
2 
3       #  2023-0925: Test bed for sending E-Mail using the reports E-
+Mail address
4       #  under foobar.ca.
5 
6:      use DateTime;
7:      use Log::Log4perl;
  DB<2>
[download]

That's version 1.55 of the debugger ..

$ grep -m 2 VERSION /usr/share/perl/5.30/perl5db.pl
use vars qw($VERSION $header);
$VERSION = '1.55';
$
[download]

Anyway, I'm glad it was fixed, and doubly glad that Open Source exists. Imagine if this was a binary only situation -- I'd have to go back to an older version, or rely on some questionable binary patch. :/

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

> didn't see the v error

Oh, sorry for the confusion. The work on cmd_l started in 5.17, but it didn't get the final blow before this commit which went to 5.33.1.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

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.

👁️🍾👍🦟

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()
[download]

...plus 50 non-CVE related patches.

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.

---

🦛

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.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.