Audit a Perl 5.22.2 Upgrade with perl5222delta

Three CVEs sit inside perl5222delta, and skimming past the security section is the fastest way to miss them during an upgrade review. This guide turns the document into a short checklist: identify the Perl binary in use, read the changes from 5.22.1 to 5.22.2, and select tests for the areas that matter to your programme. The document is a release delta, not an executable upgrade tool; it does not install Perl, change configuration or patch your source.

Allow about 15 minutes for a first pass, plus the time needed for your test suite. You need a shell, the perl-doc package and a Perl installation to inspect. The examples below use the installed Ubuntu package perl-doc 5.38.2-3.2ubuntu0.6, which provides a man page about the older Perl 5.22.2 release, so keep the documentation version and the interpreter version separate in your head.

1. Confirm which Perl you are auditing

Start with the executable selected by PATH and print its version:

$ command -v perl
/usr/bin/perl
$ perl -V:version
version='5.38.2';

Your path and version can differ. This check prevents a common distraction: reading a historical release note while assuming it describes the interpreter that will actually run your application. Testing a project with its own Perl? Activate that environment, or use its absolute path in every command below.

2. Open the release delta in the terminal

The manual describes the differences between Perl 5.22.1 and 5.22.2. Read it directly with either interface:

$ man perl5222delta
$ perldoc perl5222delta

Need output for a ticket or a searchable text file? Use the terminal form of perldoc and redirect it to a temporary location outside your project:

$ perldoc -T perl5222delta > /tmp/perl5222delta.txt
$ sed -n '1,35p' /tmp/perl5222delta.txt

perldoc -T requests plain text. The output starts by identifying the document and explaining that it covers 5.22.1 to 5.22.2. If the command says the page cannot be found, install the documentation package through your normal package-management process; do not use sudo merely to read an installed man page.

3. Triage the security section first

Read the section headed Security before the general bug-fix list. Perl 5.22.2 records fixes for an out-of-bounds access in Win32 path handling, loss of taint in File::Spec::canonpath(), unsafe temporary-file permissions around mkstemp(3), uninitialised memory access in Win32 crypt(), and duplicate environment variables passed through environ. The last item is CVE-2016-2381; the path issues are CVE-2015-8608 and CVE-2015-8607.

These notes tell you what to test, not how to reproduce a vulnerability. Do not build an exploit or weaken file permissions to demonstrate the old behaviour. For an upgrade review, map each item to your own use of temporary files, user-controlled paths, password hashing, environment variables and taint-sensitive path handling.

4. Check module and pragma changes against the running Perl

The delta says File::Spec moved from 3.56 to 3.56_01 and Module::CoreList moved from 5.20151213 to 5.20160429. Query the modules loaded by the interpreter you identified in step 1:

$ perl -MFile::Spec -e 'print "$File::Spec::VERSION\n"'
3.88
$ perl -MModule::CoreList -e 'print "$Module::CoreList::VERSION\n"'
5.20231129

Those values come from the installed 5.38.2 environment, not what a 5.22.2 installation would show. The real question is whether your application relies on the corrected canonpath() taint behaviour or on the historical core-module inventory. If it does, add an explicit assertion or regression test rather than comparing package numbers alone.

5. Select tests from the bug-fix sections

Scan Selected Bug Fixes for constructs your programme uses: here-doc parsing, #line directives, C99 hexadecimal floating-point notation, regular expressions with non-ASCII characters, pack with hexadecimal templates, strict-subs hash keys, environment updates on Darwin, and several assertion or segmentation-fault fixes are all in scope.

Run the smallest relevant tests first, then the complete suite:

$ prove -lr t
$ prove -lr xt

Only run the second command if your project has an xt/ directory suited to your environment. Using a different test runner? Use that instead; the delta defines no universal test command, and a failed suite may just as easily reflect an unrelated dependency or platform assumption.

Keep the old interpreter available until the comparison is complete. A safe review changes the test environment or selects a different binary; it does not replace a system Perl in place. If you altered a project-local version manager setting, restore the previous selection with that tool's documented command. There is no rollback operation in perl5222delta itself.

6. Read the boundaries before signing off

The page says there are no intentionally incompatible changes between 5.22.1 and 5.22.2. That is a compatibility statement about this maintenance release, not a guarantee that an application can jump from any older Perl without review. Coming from 5.22.0? Read perl5221delta first, as the manual itself instructs.

Also separate build notes from runtime behaviour. The page includes fixes for DTrace builds, Configure detection of libnm and GCC 5, Darwin debugging builds, ppc64el floating-point detection and Tru64 tests. These matter when building Perl, not because enabling a configure option is required for an ordinary package upgrade.