On Tue, 7 May 2019 at 20:05, Stanislav Malyshev <smalys...@gmail.com> wrote:
> So before just swinging the ax and dropping it I think we should really > research what people are actually using open_basedir for. And then try > to formulate a proper description of what it can be used for without > claiming any security guarantees we could not deliver. > Yes. > In general, I think we should slow down a bit (actually, a lot) with > removing things from PHP. We've already accumulated a lot of BC baggage > here, and if we want PHP 8 to become the version of PHP that an average > developer can target without hearing "yeah, we're planning to upgrade > sometimes in the next 2-3 years, probably, maybe", then we should slow > down with the removals. > > PHP 7 had rather short list of removing things, and most of them very > marginally used. And that IMHO worked well. Here we're talking about > things that are used - on my estimation - much more widely. open_basedir > particularly is not that bad in this regard, because likely no app > critically depends on it being there - so it's more of a generic comment > about what I am seeing on the lists nowdays, where tons of removals and > global overhauls with enormous BC costs are proposed. > I agree with Stas. I support a campaign of education by doing Nikita's a) & b), with the addition of: c) highlighting the performance impact (particularly if it can be quantified) d) updating the PHP.ini comment to say it is not recommended to enable, with details of a) b) & c) https://github.com/php/php-src/blob/master/php.ini-development#L295-L300 I will vote against removing if it comes to a vote. Peter
