Re: From mono-implementation risk to spec: Lessons from CVE-2026-109618/109619 and a path to K/Redex semantics[Idea]
| From: | Larry Garfield | Date: | Sun, 25 Oct 2026 17:12:26 +0000 |
| Subject: | Re: From mono-implementation risk to spec: Lessons from CVE-2026-109618/109619 and a path to K/Redex semantics[Idea] | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132925@lists.php.net to get a copy of this message | ||
On Sun, Oct 25, 2026, at 10:32 AM, Sjoerd Langkemper wrote:
> On Sat, Oct 24, 2026, at 22:59, Brian Nguyen wrote:
>> PHP today has no formal specification. As the KPHP work
>> (Filaretti et al., ECOOP'14) notes, Zend is the de-facto
>> spec. That makes this class of bug hard to catch:
>> ...
>> I am proposing we use this incident to start:
>>
>> A) Formalize Zend bytecode and parser as a living spec
>> B) Reference executable semantics in two formal frameworks:
>
> I think PHP is not starved for bugs. The bottleneck is bugfixes. As I
> understand it the problems leading to these CVEs were already found by
> an earlier security test, but the problem was coming up with a good
> fix. I think creating a spec and a second implementation is not the
> most efficient way to find and solve bugs.
>
> Regards,
>
> Sjoerd Langkemper
To be blunt, the way to address the bottlenecks on bug fixing is to badger PHP-using companies into
becoming significant PHP Foundation sponsors. Or dedicating their own employees full time to PHP
maintenance.
This is a money problem, just like most major OSS projects. It's nothing more complicated than
that. A formal spec may have merit, but it has no relevance to the current situation.
--Larry Garfield