Use perl5143delta to Audit a Perl 5.14.3 Upgrade

A controllable algorithm name reaching eval() is the kind of bug that ends up in a delta note, and perl5143delta has exactly that. It is documentation, not an executable with options, so the real workflow is reading its claims and testing the affected behaviours yourself.

You will finish with a small, repeatable audit: the installed Perl version, the two named security fixes, and a record of tests relevant to your own programs. Allow about 20 minutes. You need a shell, the perl-doc package, and an ordinary user account; nothing here needs sudo. The examples test the Perl installed on this machine, Perl 5.38.2 from Ubuntu package version 5.38.2-3.2ubuntu0.6, not the historical Perl 5.14.3 build the document describes.

1. Confirm what is installed

Separate the document's subject from the interpreter you will actually test, before you record anything as evidence:

$ command -v perl
/usr/bin/perl
$ perl -v | sed -n '1p'
This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi
$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

2. Read the delta as a release boundary

Open the complete document locally:

$ man perl5143delta

It describes differences between Perl 5.14.2 and 5.14.3. Easy to miss its first practical warning: upgrading from an earlier branch such as 5.12? Read the corresponding 5.14.0 delta as well. A point-release note cannot replace the notes for the larger upgrade.

The document reports no intentional incompatible changes and no deprecations since 5.14.0. Useful release information, not a guarantee every application is safe. Your application's modules, configuration, warnings and data still need testing.

3. Check the two security fixes first

The security section names two issues the release fixed:

• Digest->new() algorithm injection. An attacker-controlled algorithm name could reach an eval() call.
• x repeat operator overrun. Before 5.15.5, a count from poorly written code could turn a memory-exhaustion denial of service into a heap buffer overrun, with possible code execution on particular old libc combinations.

Both are input-boundary findings. A current interpreter rejecting one test case does not make an untrusted algorithm name or repeat count safe. Trace where the value comes from, constrain it at the application boundary, and keep the interpreter upgrade in the remediation record.

For the installed interpreter, check the Digest module version and try a deliberately invalid algorithm name. Harmless error-path check, not an exploit attempt:

$ perl -MDigest -e 'print "$Digest::VERSION\n"'
1.20
$ perl -MDigest -e 'Digest->new("not-a-real-algorithm")' 2>/dev/null
$ printf 'exit status: %s\n' "$?"
exit status: 2

The diagnostic is suppressed here because its path and wording vary. The useful result is the non-zero status, not an attempt to treat arbitrary input as Perl source. Keep algorithm selection allow-listed in application code, accepting only names your program explicitly supports.

For the repeat operator, exercise a normal bounded value and record the output length:

$ perl -e 'my $count = 4; my $value = "ab" x $count; print length($value), "\n"'
8

Do not feed large or attacker-controlled counts into a test shell; the release note already identifies memory exhaustion as the risk. In real code, validate that the count is an integer in an application-specific range before using it with x. The safe bound depends on what the program is building.

4. Review the module and build changes that affect you

The document lists focused updates rather than a new feature set: PerlIO::scalar fixed hangs and assertion failures when a filehandle was opened to a glob copy, IPC::Open3 fixed a regression from 5.12 affecting open3 with -, Digest moved from 1.16 to 1.16_01, and Module::CoreList gained the release data.

Search your application and test suite for the affected interfaces; a first pass is read-only:

$ rg -n 'Digest|IPC::Open3|open3|PerlIO::scalar|Module::CoreList|\bx\b' /path/to/application

Replace /path/to/application with a real checkout. A match is a prompt for a test, not proof of a bug. For open3, test the exact way your program connects input, output and error handles. For PerlIO::scalar, test the filehandle lifecycle that previously hung or asserted. Do not copy a production data path into a quick shell experiment.

5. Check the platform notes before compiling

Building Perl rather than installing a distribution package? The delta includes platform-specific notes. On Linux, libutil is no longer used during compilation and the system GCC is used when searching for libraries such as -lm. Fixes are also recorded for FreeBSD, Solaris, NetBSD, HP-UX, Mac OS X and GNU/Hurd.

These notes will not configure a complete build for you. Use them to choose what to inspect in build logs, then follow the versioned Perl source's INSTALL and platform documentation. Keep the old interpreter available until the new one has passed your application's test suite.

6. Record what the audit proves

A successful one-liner proves only that this interpreter handled that one input. It does not prove an application validates algorithm names, bounds repeat counts, or exercises the fixed module paths correctly. Record the interpreter path, Perl version, package or build identifier, test commands, exit statuses, and any warnings.

There is no rollback operation in these examples, because they change no files or services. If an upgrade changes application behaviour, restore the previously packaged Perl through your normal package-management rollback process, or switch the application back to its preserved interpreter path. Do not remove the old runtime until the new one and its dependent modules are verified.