Re: From mono-implementation risk to spec: Lessons from CVE-2026-109618/109619 and a path to K/Redex semantics[Idea]

From: 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

« previous php.internals (#132925) next »