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

Re: [perl #127810] Provide -Dfortify_inc Configure option to remove. from @INC

Thread Previous | Thread Next
Niko Tyni
April 14, 2016 20:17
Re: [perl #127810] Provide -Dfortify_inc Configure option to remove. from @INC
Message ID:
On Tue, Apr 12, 2016 at 10:24:04AM -0700, Todd Rinaldo via RT wrote:

> Q: We should hide the Configure option so people won't be able to compile perl with . in INC any more? (-Accflags=-DPERL_UNSAFE_INC)
> A: Sure you could and I don't feel strongly about it. But IMO, we let people do much sillier things than this in Configure. I prefer to make the rope readily available to anyone who wants to hang themselves. I vote for leaving the option to put . back in @INC during Configure as long as it defaults to off.

Thanks very much for driving this.

So far, this discussion seems to have been mostly about fixing toolchain
issues. While those are of course a precondition for this, I'd like to
discuss the problem of potentially breaking user programs.

For people building perl themselves, it seems fine to remove '.' from
@INC by default and offer a Configure option (hidden or otherwise) to
those who need it. However, various distributions (GNU/Linux variants,
FreeBSD etc.)  offer pre-built (binary) perl packages for a "system
perl".  The Configure option isn't much use in such cases. So once the
distribution starts shipping perl with no '.' in @INC, a system perl
upgrade can break user scripts.  Users then need to take action, either
by setting PERL_USE_UNSAFE_INC=1 in the script environment, or otherwise
fixing the actual issue.

It seems to me that deprecation warnings could be useful here, so that
distributors could turn them on for one release to notify users that
things will need changing.

I'm thinking of something like 

 if @INC is unmodified and
    $ENV{PERL_USE_UNSAFE_INC} is not set and
    require() loads something under "." 
 then warn "using unsafe @INC is deprecated and will break in the future"

I suppose this would need a tri-state Configure option or two separate
ones, but I'm sure such details are solvable.

It may be that I'm just too cautious about local breakage.
Do people see something like this as feasible and/or desirable?
Niko Tyni

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About