Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105637
MIME-Version: 1.0
References: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
 <5ac2a666-61e3-877b-6c4d-6b4b78996c91@gmail.com>
In-Reply-To: <5ac2a666-61e3-877b-6c4d-6b4b78996c91@gmail.com>
Date: Wed, 8 May 2019 07:37:42 +0100
Message-ID: <CAJvSBVP41NRu+52f96Cjqjten9HesdeCtsgY_csf746yFPNS2w@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000325a2e05885a9460"
Subject: Re: [PHP-DEV] open_basedir?
From: phpmailinglists@gmail.com (Peter Bowyer)

--000000000000325a2e05885a9460
Content-Type: text/plain; charset="UTF-8"

On Tue, 7 May 2019 at 20:05, Stanislav Malyshev <smalyshev@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

--000000000000325a2e05885a9460--