Use perl5342delta to Check What Perl 5.34.2 Fixed

You will use the installed perl5342delta manual to identify the changes between Perl 5.34.1 and 5.34.2, check which Perl you are actually running, and record the security issues that matter to an upgrade decision. The examples are read-only. Allow about ten minutes.

This guide uses the perl-doc package installed here as version 5.38.2-3.2ubuntu0.6. That package supplies a manual describing an older Perl release: the page is about Perl 5.34.2, not the version currently installed. Keep those two facts separate when you write a maintenance record.

1. Check the interpreter and manual you will inspect

Start with ordinary, unprivileged commands. The first prints the interpreter version; the second finds the manual page selected by your MANPATH:

$ perl -e 'printf "%vd\n", $^V'
5.38.2
$ man -w perl5342delta
/usr/share/man/man1/perl5342delta.1.gz

Your path can differ on another host. The useful checkpoint is that perl -e reports the interpreter used by that shell, while man -w identifies the documentation file that man will open. A manual page is not evidence that Perl 5.34.2 is installed.

2. Read the release boundary before the details

Open the page and look at its opening description:

$ man perl5342delta

It describes the differences between 5.34.1 and 5.34.2. If you are upgrading from 5.34.0, the page tells you to read perl5341delta first. That is an easy scope trap: reading only this page gives you the 5.34.1 to 5.34.2 delta, not the complete history of a 5.34.0 to 5.34.2 move.

For a terminal-friendly extract, use perldoc and keep the output separate from commands you plan to run:

$ perldoc -T perl5342delta | sed -n '1,70p'
NAME
    perl5342delta - what is new for perl v5.34.2

DESCRIPTION
    This document describes differences between the 5.34.1 release and the
    5.34.2 release.

The exact spacing may vary with the formatter. Checkpoint: the heading should identify perl5342delta, and the description should name both 5.34.1 and 5.34.2.

3. Record the security fixes without testing the vulnerabilities

Move to the Security section. The page records two issues fixed in the release.

1. CVE-2023-47038 concerns a crafted regular expression and an illegal user-defined Unicode property. The affected range in the page is Perl 5.30.0 through 5.38.0, with a one-byte attacker-controlled write past a heap buffer.
2. CVE-2023-47039 concerns Perl for Windows locating cmd.exe through the system path. The documented path-search behaviour can make a malicious executable in the current directory run when a higher-privilege user invokes Windows Perl.

Do not turn either description into a proof-of-concept. You do not need to compile a crafted regular expression or place an executable in a Windows search path to verify this page. The safe, useful action on Linux is to record the interpreter version, package version and exposure, then use your normal trusted package source for an update.

The second item is Windows-specific, but that does not make the page irrelevant on a Linux fleet. Shared build scripts, developer workstations and deployment images may use more than one operating system. Note the affected platform in your ticket instead of treating every CVE as equally applicable to every host.

4. Confirm package ownership before planning a change

On a Debian or Ubuntu host, identify the packages that own the interpreter and documentation:

$ 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

Use the output from your own machine in the change record. A current interpreter can still have an older release-note page installed, as it does here. Conversely, a package name alone does not prove that a script invokes that interpreter: check the script's shebang and the service environment if the distinction matters.

Do not run package-manager commands as part of this inspection. An upgrade can replace libraries, restart dependent services or alter the interpreter selected by a shebang. If an update is required, follow the host's normal maintenance process, take its backup and rollback precautions, and re-run the version checks afterwards. There is nothing to undo in this guide because every example only reads data.

5. Use the page to make a bounded upgrade decision

Write down four separate facts: the installed interpreter version, the installed package version, the release boundary covered by the manual, and whether the security issue applies to this host or to another platform in the estate. This prevents a common distraction: treating a release-note title as a command that changes Perl.

If the host runs an affected interpreter, escalate the update through the trusted repository or vendor channel rather than downloading an unrelated binary. If the repository offers a version newer than the release discussed here, read its intervening delta pages as well. The SEE ALSO section points to the Perl Changes, INSTALL and README files when you need exhaustive source-level history or build information.

After an approved package change, repeat the first and fourth steps. If the command reports an unexpected interpreter, inspect PATH, the shebang and service configuration before declaring the host fixed. A successful package transaction is not the same as proof that every process now uses that package.