Building Perl and CPAN Modules Securely from Source

[eyepopslikeamosquito]

Reviewing my first attempt to build perl securely from source on Linux (as non-root) today, I felt happy enough with the first part namely:

$ cd $HOME
$ mkdir localperl
$ cd localperl

$ wget https://www.cpan.org/src/5.0/perl-5.38.0.tar.gz
$ sha256sum perl-5.38.0.tar.gz
213ef58089d2f2c972ea353517dc60ec3656f050dcc027666e118b508423e517  perl
+-5.38.0.tar.gz
# (eyeball this to verify it matches the value displayed at:
#  https://www.cpan.org/src/5.0/perl-5.38.0.tar.gz.sha256.txt)

$ tar -xzf perl-5.38.0.tar.gz
$ cd perl-5.38.0
$ ./Configure -des -Dprefix=$HOME/localperl
$ make 2>&1 | tee make.tmp
$ make test 2>&1 | tee test.tmp
$ make install 2>&1 | tee install.tmp
$ type perl
perl is /usr/bin/perl
$ export PATH=$HOME/localperl/bin:$PATH
$ type perl
perl is $HOME/localperl/bin/perl
$ perl -v
This is perl 5, version 38, subversion 0 (v5.38.0) built for x86_64-li
+nux
...

At least that looks safe enough to me.

I was also happy enough with the last part, namely installing CPAN modules more securely via cpanm's --verify option, which verifies the integrity of distribution files retrieved from CPAN using CHECKSUMS file and SIGNATURES file (if found in the distribution).

Now here comes the bit I seek advice on, namely the best/most secure way to install cpanm itself. Please note that I have very limited knowledge of cpanm and how it works.

In my first attempt, I simply installed cpanm via the cpan command:

$ cpan App::cpanminus 2>&1 | tee inst-cpanminus.tmp

Wondering if there's a better/more secure way to install cpanm, I browsed the App::cpanminus doco today, which advises you to install it via:

curl -L https://cpanmin.us | perl - App::cpanminus

Now I don't understand exactly how that command works. Nor do I understand the security implications of installing it like this compared to my original installation of cpanm (and Module::Signature) via the cpan command. Hence this question.

General tips/advice on good ways to securely install Perl and CPAN modules from source as a non-root user welcome.

[Corion]

How the command works is "easy":

curl ...

This retrieves the URL https://cpanmin.us, which sends back the fatpacked cpanm source code.

perl -

Perl can read a Perl program from STDIN and will then execute it. Here, Perl reads the cpanm source and uses that to install App::cpanminus.

If you want security, using the curl download potentially opens up a hole as somebody could inject arbitrary Perl code in that download. As cpanm still relies on the API hosted for it, this is not a huge risk but maybe somebody can hack the download without disabling the API.

As you have an already working cpan client, using cpan install App::cpanminus seems more secure.

[parv]

I was also happy enough with the last part, namely installing CPAN modules more securely via cpanm's --verify option, which verifies the integrity of distribution files retrieved from CPAN using CHECKSUMS file and SIGNATURES file (if found in the distribution).

About last year I built perl for a specific project. During installation of packages via CPAN the package I looked into the the signature/verification thing. The effort seemed like a fucking security theater ...

• not all the modules had the signatures;
• some were still using old, apparently expired, PAUSE GPG key;
• I did not have the luxury to omit the offending packages as they were required in some way, nor did I have the facility to write the replacements.

The packages missing the signatures (or using old PAUSE keys) remaining in CPAN the archive undermine the whole process. They ought to be evicted, or updated/replaced with a version with signatures (along with updated PAUSE keys). Have not installed anything from CPAN for myself (but OSen sure do install software on machines that I use😬).

See also ...

• c 2021 Addressing CPAN vulnerabilities related to checksums by Neil B;
• c 2022 Key Not Certified in CPAN -- "solved" by turning off signature verification🙄🫠

Please do tell me (truthfully) that the above is out of date (all the packages have valid signatures & checksums; all use currently active PAUSE keys; packages are downloaded over "https"/secure connection).

[cavac]

not all the modules had the signatures;

Correct, including mine.

They ought to be evicted,

What? Because they where uploaded before CPAN supported the current security circus? As you have seen yourself, many of those old modules are still in use.

or updated/replaced with a version with signatures (along with updated PAUSE keys).

By whom? The original author who may or may not be willing to put in the work? The people who run CPAN who can't create signatures in the name of the author? You, by taking over hundreds of modules?

packages are downloaded over "https"/secure connection

My cpan client config says https://cpan.org/

That being said, a CPAN module signature doesn't guarantee it's safe to use. If the author has evil intend, generating a fake online identity and a cryptographic signature is not a roadblock.

A lot of that security theater is, in my opinion, required by lawyers and consultants: "If you use that module and we get a security breach, we can sue the author". Newsflash, that doesn't work in OpenSource. Even if you can find the author, the license probably says something about "package is provided 'as is' ... no warranty regarding fitness for a particular purpose".

So, in conclusion: Without doing an in-depth security review of every downloaded file, you don't know if it's secure. (And even with a review, you only have some degree of certainty). And you basically have no recourse if something goes wrong.

Using commercial software doesn't help, either. Those Business-to-Business contracts basically isolate the seller from most legal and financial responsibility. But companies like Microsoft are known to always be on the customer side and provide the best, securest software possible...

[parv]

(Manually quoting & attributing -- more than a level as a direct reply to OP sans explicit attribution -- is excruciating. Feel free to re-edit the quote-in-pre as one sees fit.)

cavac wrote ...
> parv wrote ...
> > or updated/replaced with a version with signatures (along
> > with updated PAUSE keys).

> By whom? The original author who may or may not be willing
> to put in the work? The people who run CPAN who can't create
> signatures in the name of the author? You, by taking over
> hundreds of modules?

Could CPAN/PAUSE maintainers not inject|update the signatures unilaterally with only PAUSE keys (in the modules whose authors "may not be willing to put in the work")? That would indicate that at least they think the files are genuine.

If I had more skin in CPAN, then would have been more than willing to update all the modules myself, yes "by taking over hundreds of modules" if that was what would have been required to do updates.

[parv]

By early 2024, "http" was the default in cpanminus; work on making "https" the default is still ongoing: cpanminus: make cpanm secure by default #674.

Oh, also found CVE-2020-16154 remove the functionality to verify CHECKSUMS signature #638.

One day ... :-/

[eyepopslikeamosquito]

By early 2024, "http" was the default in cpanminus; work on making "https" the default is still ongoing

Good point, thanks for mentioning it. When I was writing this node back in 2023 I was kindly advised by hippo to invoke the cpanm command like this:

$ cpanm --from https://www.cpan.org/ ...

Checking my original inst-cpanminus.tmp log file from that node, I was relieved to see that this cpan command:

$ cpan App::cpanminus 2>&1 | tee inst-cpanminus.tmp

always used https by default. So it seems this is one thing the cpan command does better than cpanm.

[cavac]

Nor do I understand the security implications of installing it like this

The difference between the approaches is:

1. You are downloading a program from the internet and executing it in Perl.
2. You are downloading a program from the internet and executing it in Perl.

In both cases, you are trusting someone to not to anything evil. The main difference is that in the first case. there might be a slightly lower chance of accidentaly executing insecure code. The cpan client loads the software (which may or may not be secure) from a known server. The second approach brings the slightly higher risk that someone is running a fake website (type domain + paying for google ads) to bypass the original author.