Comment by eviks
5 hours ago
> 2024, PHP underwent its first external security audit
> PHP security team, operating on consensus, struggled to choose
What an unfortunate waste of a security audit. (and consensus is an obvious flaw in decision making)
> PHP runs a large share of the web... Yet security work on PHP itself still depends on a small group ...
Another unfortunate big structural issue that's unlikely to change.
Are there structurally much safer ecosystems out there?
I wonder if that isn't a side effect of how its structured...
When a corporation sponsors the language, such as Java, Go, .Net, there's an inherent economic component which acts as a forcing function.
PHP being a foundation sounds nice. But consensus wasn't strong enough to affect the key outcomes.
why nobody in foundation management was not intereated in resulta of rhe security audit?
making php is the core of (checks notes) php foundation
or is the management full of completely not technical people who use it to boost their CVs?
Rust and go don't have a C backbone like PHP does. So they are inherently safer to these kinds of vulnerabilities.
Garbage collection is also an option. Lots of backends on the JVM!
(Of course there's Log4shell, but that could've happened to a Rust-based stack too, and might be more likely to, considering the proliferation of deeply-nested dependency trees full of tiny libraries in that ecosystem.)
it's a good point. I wonder if we'll see a PHP fork and rewrite in rust. like tcrs. given the recently issues they would seem to benefit the most...
There are plenty of alternative interpreters or compilers out there already, no need to start a new one again: https://github.com/gakowalski/alternative-interpreters#alter...
> Are there structurally much safer ecosystems out there?
Several attributes make a safer ecosystem. An important one is diversity - technical diversity.
For an interpreted language, the runtime is important. Python has several runtimes, as does Ruby. Javascript also has several, from the few browsers, to node, deno and bun. PHP has for all practical purposes, only one. So if there's a security incident in PHP, it affects almost all users. But when e.g. JRuby has a vulnerability, it will affect only a fraction of the installed ruby applications.
For compiled languages, the tooling, libraries and runtimes is where diversity is important. With e.g. rust, the vast majority of CVEs come from libraries (crates). But since there often are several crates for a single concept, diversity helps mitigate here too.
> PHP has for all practical purposes, only one.
I know you added a caveat and all, but no, PHP has a number of alternative runtimes just like the other languages you mentioned: https://github.com/gakowalski/alternative-interpreters#alter...
But again with all the ones you mentioned, they have a "core" runtime that the vast majority of production apps use, so if NodeJS has a vulnerability it would be just as big.
The interesting one will be whether "boring" ports - like recently Typescript's TSC from Typescript to Go and now to Rust - will be safer for being the same code and logic, converted to another "safer" language (by transpilers or LLMs).
if there's a use case for re/decompiling, it's this one. with at least one strong alternative implementation, there would be less incentive on the attacking side to go all out on either PHP implementation.
...given amount of CVEs for Ruby that appears to not matter much
Yes. They're operated by big tech and called C# or Java.
While the main Java and .NET virtual machine implementations are much more secure than PHP, they were still written at least partially in unsafe C++. I won't be surprised if frontier LLMs eventually find more vulnerabilities in those platforms.
[flagged]
Sure, because there are a zillion other people looking to step up.
Also, blameless post-mortems exist for a reason.