Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120902
MIME-Version: 1.0
References: <CAFPFaMLBZixUFa=7=9Gxj60D=4QyfSpF9se-U+6CRoShzCrFrA@mail.gmail.com>
 <64DA7ACC.1050909@adviesenzo.nl>
In-Reply-To: <64DA7ACC.1050909@adviesenzo.nl>
Date: Mon, 14 Aug 2023 21:11:54 +0100
Message-ID: <CAFPFaMJ-TEA9xyvT5gRsGh-4jop-iRXBL+cFvPZSwpNRtXFUWw@mail.gmail.com>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000003249600602e7ad64"
Subject: Re: [PHP-DEV] Removing support for the disable_classes INI setting
From: george.banyard@gmail.com ("G. P. B.")

--0000000000003249600602e7ad64
Content-Type: text/plain; charset="UTF-8"

On Mon, 14 Aug 2023 at 20:04, Juliette Reinders Folmer <
php-internals_nospam@adviesenzo.nl> wrote:

> Hi George,
>
> For what its worth: in my experience, the `disable_classes` and
> `disable_functions` ini directives are mostly used by hosting companies
> providing shared/virtual host environments and, most often for those
> environments, not editable by their users via a control panel or nor do
> these users have (edit) access to the php.ini file.
>

To be clear, I have no intention of deprecating or removing
disable_functions.
This INI setting works very well and does not cause any issue within the
engine.

[...]
>
> Would deprecating it in PHP 8.3 and removing it in PHP 9.0 be an option ?
>

One option is to "keep" the INI setting, but have it basically do nothing.
Is this what you had in mind?


> As for the lack of bug reports - the typical type of end users using
> those hosts will not know to report these type of issues to PHP (or even
> be able to properly identify the issue). Instead they will complain
> extensively to whatever open source project (read: WordPress) they are
> running on the shared hosting without providing enough information for
> the open source maintainers to even begin to identify the actual
> issue... ;-)
>

On a minimal build of PHP, with only the mandatory extensions enabled,
there are 148 classes/interfaces/traits defined. [1]

Other than the SPL ones (and even then), disabling any of these classes
will cause issues within the engine.
Moreover, the SPL ones are not a security concern.

Therefore, any other class that can be disabled must come from an extension
that can be disabled altogether. And "disabling" a class from an extension
without disabling said extension will render it useless anyway.

If a hosting provided is concerned about an extension, then it should not
enable it in the first place. Not break it ad hoc.

Considering the above, I cannot see how this functionality was ever useful.

This is in stark contrast to disable_functions, which can be used to
selectively remove functionality of an extension without breaking it
overall.

George P. Banyard

[1] https://gist.github.com/Girgias/63d55ba1e50b580412b004046daed02b

--0000000000003249600602e7ad64--