develooper Front page | perl.perl5.porters | Postings from November 2016

Proposal: deprecating PERL_USE_UNSAFE_INC as of 5.30

Todd Rinaldo
November 14, 2016 15:50
Proposal: deprecating PERL_USE_UNSAFE_INC as of 5.30
Message ID:

Prior to the release of Perl 5.26, I propose deprecating support for PERL_USE_UNSAFE_INC. 

IMO, giving CPAN 2.5 years to cleanup seems sufficient to me, so I would be good with dropping support in 5.30. Does anyone have an opinion on if this is too soon or not soon enough? 

For those of you not familiar with the change, see the below email sent to cpan-workers.



I've done a write up of a recent change to blead perl. In the future it will no longer be possible to count on . being in @INC. This will break many of the existing CPAN installs.

It was suggested I send the RFC here:

In Perl 5.26, it will no longer be a safe assumption to assume . is in @INC. This is a good move towards a more secure Perl, but will break the installation of many CPAN modules. For those of you wondering why this was done, see this post for more information.

Many CPAN modules try to do things like: use inc::Module::Install; This depends on . being in @INC. If you invoke Makefile.PL without it, the script will not even run.

We have come up with several ways to mitigate and ultimately fix the problem:

Short Term

Perl 5.26 will support an environment variable "PERL_USE_UNSAFE_INC=1". If you set this, any perl script invoked will include . at the end of @INC. Tentatively, support for this environment variable will be immediately deprecated since long term, the CPAN modules need to simply take this into account.

My current thinking is that if we inject this environment variable into the CPAN clients (cpanm, cpan, cpanplus, etc.), then they will build and install modules as they normally did. Packagers (RPM, deb, etc.) will also need to amend their build systems by also setting this environment variable. It is also possible that a fix will be require to CPAN smoke testers.

Long Term

We need to fix the CPAN modules themselves. The vast majority of modules can be fixed by putting use lib "."; at the top of Makefile.PL or Build.PL. Others will need to fix additional scripts in their tree to also take this into account. In some cases use blib; might be more appropriate, for instance, in unit tests which invoke child scripts.

My original proposal included a patch to ExtUtils::MakeMaker, Module::Build, and Module::Build::Tiny. At this point I think that this might be the wrong place to fix the problem.

These are all my thoughts based on conversations with others about how this transition needs to be addressed. I do not claim to have all the correct answers. I am using this blog post to anchor the conversations that need to be had with multiple groups (CPAN Testers, P5P, Tool Chain Gang, etc.).

If you want to try a Perl with this functionality now, you will need to build Perl with the Configure option: -Ddefault_inc_excludes_dot. This is available in blead and the next development build of perl.

I'll be opening a ticket with the CPAN clients this week. If you know of other items that need consideration, please let me know in comments or feel free to reach out to me or perl 5 porters. Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About