Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130360
Feedback-ID: id5114917:Fastmail
Message-ID: <1915677b-05a7-4c7c-b53c-9812ed8ac3f2@rwec.co.uk>
Date: Sun, 15 Mar 2026 19:50:29 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven
 PHP.
To: internals@lists.php.net
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
 <299760A8-5C8A-41AD-B2EB-986079D41A47@rwec.co.uk>
 <CB2D54A7-BF48-40A6-A746-34078A05A7DC@gmail.com>
Content-Language: en-GB
In-Reply-To: <CB2D54A7-BF48-40A6-A746-34078A05A7DC@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 15/03/2026 12:20, Daniil Gentili wrote:
> The exact lifecycle is explicitly not defined to allow for more 
> flexibility, but it can have emergency yanks for security issues, just 
> like for all extensions.
>
> [...]
>
> The point here is that users MUST be able to rely on feature 
> extensions, including in the long-term: this is the reason for the 
> stringent removal requirements.
>
> [...]
>
> The feature owners handle all changes to feature extensions.


You can't have it both ways:

- either the PHP project is making a lasting promise to the user by 
accepting a feature extension, and therefore taking on a lasting obligation;

- or, the obligation is entirely on the feature owner, and therefore the 
PHP project can't make any promise to the user


Currently, we have a process for promising a feature will be supported 
"forever" (RFCs); and a mechanism for maintainers to make an independent 
promise which users can choose whether to trust (PIE).

It might be interesting to make a more limited promise, such as "this 
feature will be supported for 1 year, then subject to breaking changes 
or removal". It might even be sensible to automatically "time out" every 
feature version after, say, 1 year, forcing one of three things: a) the 
feature has proven useful and stable, and is adopted permanently; b) the 
feature is still in flux, and users should migrate to a newer version; 
c) the feature has been abandoned, or proven impractical, and will no 
longer be provided.



>> Why will somebody trust this branch containing a bunch of 
>> separately-maintained feature extensions any more than they would 
>> trust a repository of PIE extensions? If anything, it is far *more* 
>> dangerous, because the features aren't limited to the normal 
>> extension API.
>
> Sandboxing plays the single most important rule in building trust.


This is a very different type of "sandboxing" than what is discussed in 
the RFC. We're not talking about "ask the extension nicely not to give 
the user file system access", we're talking about "trust the extension 
not to silently send all user input to a malicious server", and "trust 
the extension not to have memory leaks that will crash the entire host".



>>
>> I think this RFC is trying to do two conflicting things at once:
>>
>> 1) allow users to test far-reaching, experimental, changes to the 
>> language and engine
>> 2) allow users to enable safe, stable, features without installing 
>> untrusted binaries
>>
>
> These are not conflicting things, they complement each other.


Perhaps the confusion is that there are two different kinds of stability 
we can talk about:

- stability of the implementation: are the changes to the engine 
thoroughly tested, and free from crashes and incorrect behaviour?

- stability of the API: can PHP code, and other extensions, be written 
to make use of the feature?

A feature flag is suitable for hiding an unstable API, but it's not 
suitable for hiding an unstable implementation.


-- 
Rowan Tommins
[IMSoP]