Configure cpanm to install over HTTPS

[zakame]

Follow up for #114 - we add PERL_CPANM_OPT configuration in the Dockerfile and ensure we have install tools for cpanm that can pull over HTTPS.

[zakame]

Current and new tests are all passing, will merge and release this for Hub 💪

[skaji]

Setting PERL_CPANM_OPT="--from https://www.cpan.org" limits some cpanm’s features.
For example, cpanm cannot install dev releases with --from https://www.cpan.org

❯ cpanm --from https://www.cpan.org ExtUtils::MakeMaker@7.65_01
Found ExtUtils::MakeMaker 7.64 which doesn't satisfy == 7.65_01.
# FAIL

❯ cpanm ExtUtils::MakeMaker@7.65_01
! Finding ExtUtils::MakeMaker (== 7.65_01) on cpanmetadb failed.
--> Working on ExtUtils::MakeMaker
Fetching http://cpan.metacpan.org/authors/id/B/BI/BINGOS/ExtUtils-MakeMaker-7.65_01.tar.gz ... OK
Configuring ExtUtils-MakeMaker-7.65_01 ... OK
Building and testing ExtUtils-MakeMaker-7.65_01 ...
# OK

--from https://www.cpan.org means not only to download releases from https://www.cpan.org,
but also to use https://www.cpan.org/modules/02packages.details.txt.gz as only one resolver
(not using metacpan or cpanmetadb resolvers).

[waterkip]

It also limits installs from backpan.perl.org

[zakame]

Thanks @waterkip @skaji for the feedback! 💯

I'd suggest adding a section on https://github.com/docker-library/docs/tree/master/perl for this - I think we can also accommodate using ARG PERL_CPANM_OPT in the Dockerfile template so people can override the new default should they choose to rebuild the images themselves. I recognize that while Perl does not mandate CPAN clients to support HTTPS yet, we can do so here under docker-perl as a frequent use-case of the images is for running applications on production.

Alternatively, would you have other suggestions for this such that we can mitigate supply-chain attacks?

[waterkip]

Personally I think this is a problem that cpanm and/or other package managers should deal with and not this project.

[zakame]

@waterkip I'd normally agree, but the fact remains that this project is a package of Perl + OS dependencies unto itself - we are the package manager on behalf of Docker/container users, and thus we'd want to set a reasonable expectation that whatever additional CPAN packages we can fetch through the docker-perl container can be done so in good faith to the currently available secure means from CPAN. The new default is certainly reversible - I don't think it unreasonable for anyone to opt in and unset/change PERL_CPAN_OPT so they can go ahead and install dev/backpan releases via the metacpandb or alternate resolver, though I admit that a prior notice or update in documentation for this change would have been better.

[waterkip]

While I understand your point I do not agree with it.

You are merely providing the same options as the already existing behavior on any default OS. cpanm (and others) should start offering HTTPS support by default. That is the actual problem, the current solution is a workaround that breaks any cpanfile where something depends on a version that is either on backpan or is a development version.
The former option is probably more likely to happen, as modules are moved to backpan as soon as a module author deletes a package via the CPAN interface. From one moment to the next a docker build breaks: cpanm --installdeps . now requires another invocation with PERL_CPANM_OPT unset.

The solution than requires additional build steps which are not easy to understand, because even if cpanm fails and it is not because of backpan or development releases, it will run again. To prevent this from happening, everyone would need to unset PERL_CPANM_OPT which is what the default now is and thus we don't gain a lot more than we currently have. We actually need to do more to get the same results.

[zakame]

@waterkip valid points, yes, and it could be worse - as you say indeed, cpanm (and others) should start offering HTTPS support by default, and as we are merely including cpanm in docker-perl as a courtesy/convenience as the Perl dist already has CPAN.pm, we could also just take it all away, or replace it with another that does support HTTPS (such as cpm.)

For now though since #116 already came up which supports your claim, I'll revert this change. Thanks again for the feedback!