Use perl5222delta to audit a Perl 5.22.2 upgrade

You will turn perl5222delta into a short upgrade 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. That package provides a man page about the older Perl 5.22.2 release, so keep the documentation version and the interpreter version separate.

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 run your application. If you are testing a project with its own Perl, activate that environment or use its absolute path in every command.

Checkpoint: record the version, executable path and package source before changing anything. No elevated privilege is required for these read-only commands.

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

If you 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 that 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 identified as CVE-2016-2381; the path issues are identified as 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 use of temporary files, user-controlled paths, password hashing, environment variables and taint-sensitive path handling.

Checkpoint: make a small table in your change record with one row per relevant security fix, the affected code path, and the test that will exercise it. A fix that only concerns Win32 does not need to become a Linux regression test, but it can still matter if the same code is shipped cross-platform.

4. Check module and pragma changes against the running Perl

The delta says that 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:

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

Those values are examples from the installed 5.38.2 environment, not expected values for a 5.22.2 installation. The useful 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. The release notes mention 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.

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 and its tests are suitable for your environment. If your project uses another test runner, use that instead. The delta does not define a universal test command, and a failed test suite may 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 did alter a project-local version manager setting, restore the previous selection using that tool's documented command. There is no rollback operation in perl5222delta itself.

6. Read the boundaries before signing off

The page says that 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. If you are coming from 5.22.0, read perl5221delta first, as the manual 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, but they do not mean that enabling a configure option is required for an ordinary package upgrade.