Hi! > b) update the security policy (https://wiki.php.net/security) to state that > open_basedir bypasses are not security issues. I believe this has been part > of Debian's security policy for some time already.
I think we've been treating them this way effectively for a while now. The big question is how we formulate what open_basedir actually *is*. I mean, some people find it rather useful, and in some situation such mechanism can be very valuable - one scenario I can think of it turning on open_basedir, run through application test suite and check that it doesn't reach anywhere it should not. It, of course, does not provide security guarantees, neither do unit tests, but we still find unit tests useful, and in the same vein people may find open_basedir useful. 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. 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. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
