Front page | perl.perl5.porters |
Postings from August 2016
On Wed, Aug 3, 2016 at 9:49 AM, Todd Rinaldo via RT
<perlbug-followup@perl.org> wrote:
> I will submit a re-based patch later today with my proposal based on ALL (one :) ) of the responses so far.
That sounds like a good plan to me. My only (late) suggestion would be
to avoid words like "safe" and "fortify" in the names of Configure and
environment variables that describe what we're doing to @INC. While I
appreciate the intention of communicating that these things are
security-related, we can't actually guarantee there will never be
other, unrelated security problems with @INC that will need to be
patched. What do we do then, call the new thing extra-fortified,
double-safe @INC and explain to people that even though they have
enabled safe @INC, their @INC isn't actually safe? Remember safe.pm
or safe signals as examples of things where the name promised more
than could actually be delivered. If only we had called "safe"
signals "coalesced" signals and documented that they provide a measure
of safety against *one* of the things that can go wrong with signals,
I think promises and expectations would have aligned better.
Along those lines, my suggestion would be to describe what we're
actually doing to @INC and call it -Dinc_adds_dot_dir or
-Dinc_omits_dot_dir. I think I favor the latter because
$Config{inc_omits_dot_dir} will be false for every perl that has
existed until now, will continue to be false as long as we configure
it to be undef (the initial default), and then will be true when we
configure to refrain from adding '.' to @INC (the eventual default).
I guess this is bikeshedding. Sorry. Todd, if this becomes
controversial, please ignore me and Just Do It with whatever name you
want, but as we've recently seen with base.pm, setting more precise
expectations can be important.
Thread Previous
|
Thread Next