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

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

Thread Next
Todd Rinaldo via RT
April 14, 2016 20:57
[perl #127810] Provide -Dfortify_inc Configure option to remove .from @INC
Message ID:
On Tue Apr 12 17:14:36 2016, LeonT wrote:
> On Tue, Apr 12, 2016 at 7:24 PM, Todd Rinaldo via RT <
>> wrote:
> > Q: If people need to put . back in @INC like it was, it should be a Perl
> > command line option (--add-dot-to-inc-flag) or even -MDotInc
> > A: If you take this approach, you lose the advantage of the environment
> > variable bleeding through to child processes unless you use PERL5OPT.
> I don't see this as an advantage; I see it as an action at a distance and I
> generally don't like those. While they can be useful it should always be
> the second option, just like how -I has PERL5LIB (though in this case I
> don't really see the advantage of a separate variable for this).

PERL_USE_UNSAFE_INC is a shim to minimize the amount of CPAN installation processes that break immediately when we put the core perl patch in. It is the only approach I see that has little or no risk of side effects. I would envision following this up with a special smoker that would find and identify the CPAN modules that are leaning on . in @INC and submit patches to fix the modules.

> This happens quite a bit in the tool chain, so you'd have to end up fixing
> more stuff.

Not sure which stuff you mean. The patches I linked to were the only ones I seemed to need with my approach.

> I'm not sure it really happens in so many places. It's mostly just running
> the Makefile.PL/Build.PL, and running the tests. That's only two niches
> that need to be adapted, essentially.

It happens in more places than you seem to think from what I've seen.

> Not saying it's trivial, but I don't think an environmental variable makes
> things less complicated than a command line argument.

Ok. I'm not sure what your proposal here is. When I proposed this years ago. One of the major objections was how much of the toolchain and CPAN modules we'd have to fix to make this work. It sounds like you're saying you want to take the pure approach of making everything break and then fixing it. Who's going to do that work? From what I've seen, changes in perl that necessitate a small number of modules be fixed up end up being unachievable by the time we get to RC0. I suspect the pure approach would be an order of magnitude worse.

> > Also I suspect that perl 5.8.8 will not take kindly to
> > PERL5OPT="--add-dot-to-inc-flag".
> >
> "Doctor, it hurts when I do this".
> I can vaguely imagine workflows where this is an issue, but that's the same
> sort of workflow where PERL5LIB falls on its face because perl-5.8.whatever
> can't load perl-5.22's modules.

At this point, the only proposal I've seen that I think has a chance to work without re-releasing 30% of CPAN immediately would be PERL_USE_UNSAFE_INC or something to inject . into PERL5LIB. I am very worried that PERL5LIB will have unexpected side effects since it puts . at the front of @INC, not the end.

> > Right now, I've identified the following as work that has to be done
> > outside perl once this merges. The needed patches are already staged
> > in the issues.
> >
> > 1. 3 tickets to update (Makefile|Build).PL module installers to address
> >
> >
> >
> The way these patches are currently written suggests to me they're intended
> for dealing with tests that assume . is in @INC. In MM these would be
> copied to blib/lib anyway, for MB and MBT I suppose it would help if people
> put some testing library in a weird place. Adding it in
> Test::Harness/TAP::Harness would seem like a more obvious place to me
> though.

They are not just for addressing unit tests. I initially tried patching *::Harness to fix this. It was insufficient to solve the problem.

Makefiles do silly things like generating files with external perl processes, firing up servers for testing, calling a secondary Makfile.PL from a Makefile, etc. When I got to my 20th module that needed special patching beyond harness, I abandoned the approach. You can't just assume unit tests are all that need a @INC fixup. 

> > 2. 3 tickets to fix the CPAN installers (cpanm/cpan/cpanplus) to make use
> > of PERL_USE_UNSAFE_INC (just for good measure)
> >
> >
> >
> Given that there are more than a thousand distributions (according to
> on CPAN that do «use inc::<whatever>» I think it's fairly
> unavoidable to handle this here somehow; Module::Install is largely
> responsible for this. This is singlehandedly the one place where this
> change will hurt the most.

Yes. Though I really didn't need to mess with Module::Install modules at all with my approach.

If we were to immediately deprecate PERL_USE_UNSAFE_INC, would this make you feel any more comfortable? We could then yank it out of perl 5.28. This would give people 2 years to fix their CPAN module, etc so it would be able to work without the env var. I think that would be achievable.


via perlbug:  queue: perl5 status: open

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