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