Use perl5143delta to Audit a Perl 5.14.3 Upgrade

You will finish with a small, repeatable audit for a Perl 5.14.3 upgrade: the installed Perl version, the two security fixes named by the release notes, and a record of the tests relevant to your own programs. perl5143delta is documentation, not an executable with options, so the useful workflow is to read its claims and test the affected behaviours with the Perl interpreter.

Allow about 20 minutes for a basic audit. You need a shell, the perl-doc package for this manpage, and an ordinary user account. The examples are read-only and do not need sudo. They test the Perl installed on this machine, which is Perl 5.38.2 from Ubuntu package version 5.38.2-3.2ubuntu0.6, not the historical Perl 5.14.3 build described by the document.

1. Confirm what is installed

Start by separating the document's subject from the interpreter you will actually test. This avoids recording a modern result as if it were evidence about an old binary:

$ 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

Checkpoint: write down the version and package source before interpreting any result. If you need to assess a Perl 5.14.3 application environment, run these checks against that environment, not against a development shell that happens to be newer.

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. Its first practical warning is easy to miss: if you are 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. That is useful release information, not a guarantee that 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 fixed by the release. The first affected Digest->new() when an attacker could control the algorithm name. The unsafe input reached an eval() call. The second affected Perl's x string repeat operator: before 5.15.5, a count supplied by poorly written code could turn a memory-exhaustion denial of service into a heap buffer overrun, with possible code execution in particular old libc combinations.

These are input-boundary findings. Do not make an untrusted algorithm name or repeat count safe merely because a current interpreter rejects one test case. 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, inspect the Digest module version and run a deliberately invalid algorithm name. This is a 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 in this short check because its path and wording vary. The useful result is the non-zero status, rather than an attempt to treat arbitrary input as Perl source. Keep algorithm selection allow-listed in application code, for example by 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 a 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 simple 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. Treat a match as a prompt for a test, not as 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

If you build Perl rather than install a distribution package, the delta includes platform-specific notes. On Linux it says that libutil is no longer used during compilation and that the system GCC is used when searching for libraries such as -lm. It also records fixes for FreeBSD, Solaris, NetBSD, HP-UX, Mac OS X and GNU/Hurd.

Those notes do not tell you how to configure a complete build. 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.

Checkpoint: after a package upgrade or local build, repeat the version command from step 1 and run the application's tests with an explicit interpreter path. Do not rely on whichever perl happens to be first in PATH.

6. Record what the audit proves

A successful one-liner proves only that this interpreter handled that one input. It does not prove that 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.