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 ntyni@debian.orgThread Previous | Thread Next