Comment by charcircuit
15 hours ago
Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
15 hours ago
Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
If you want an orderly fast global rollout you need to have the maintenance team and distributors working together.
So anybody can just push out a new release of PHP?
Yes, someone could have published a safe version for people to use for the 2 months to get the actual fix done.
>Yes, someone could have published a safe version
this is basically the same as releasing a working exploit.
8 replies →
Sort of by definition of open-source, yes. It's just that nobody downstream is likely to accept Joe Public's random fork of PHP.
You're confusing PHP the product with PHP the codebase. The former is what is the only relevant part in the security world, where a product is synonymous with its vendor (even FOSS).
1 reply →
Did start writing software this week?
So if Wiz produced their own patch to PHP, and Calif produced their own (slightly different) patch, and OpenAI produced their own, which version should I use, as a user of PHP? Should I manually merge them? Is Calif's better than Wiz's? Is OpenAI's better than Calif's? Are they complementary?
That does happen with downversion software. Red Hat may distribute a backported patch to some component which isn't the same as Canonical or Debian's.
Most users, who don't know the answer to your questions, rely on the distro to figure this out (and often pay good money for it).
They already were in communication with each other. They could have come together and decided on one that mitigates the issues they've found.
What's the other choice? OpenAI et al could have developed a patch (for all we know they did) but you need the PHP team's participation to get it out. The alternative would be to fork the project and put up a forked release with the fix, which would have been incredibly disruptive.
I'm glad they didn't do anything disruptive, then. Like wind the world's CIOs up into a frenzy of FUD and bring thousands of servers down in a coordinated panic attack synchronised to the minute.
Imagine if they had just patched the code and rolled it out with an advisory?! Oh my GOD! Won't someone think of Sam Altman and his huge pile of debt?!
Pre AI, silently publishing a fix to a security vulnerability was considered bad practice.
Post AI, Its efficiency pre announcing the exploit to bad actors until the official disclosure.
You can just watch the diff log of every open source project with a small local model, and look for anything that touches buffers, function pointers, or shell integration.
It could be an hour between release of a fix before the exploit starts attacking servers.
Guess what also could happen within an hour? A coordinated Internet wide panic that shuts down all vulnerable servers.
---
We actually have a recent example. OpenAI hack.
An undisclosed vulnerability fix to a image formal lib; packages into debian 12 running in a docker, used by imagemagic, used by discourse running OpenAIs user forum.
What would you have a security team for then?
To handle the official solution and drive long term changes to reduce similar security bugs from happening again. The current PHP security team does not seem capable to promptly release a fix, so having a community fix first seems preferable.
Mitigating a bug and developing a proper solution that is maintainable long term and supports future changes being made to the software take different amounts of time to develop.
Because...that's what the PHP security team does?
No one needs to use their work, or indeed PHP at all.
But that's why the PHP security team exists.
If it takes 2 months to do fix a massive security issue, it's best if someone else steps up to the plate to fix it.
I don’t think the parent would disagree.
But the PHP team is the one that got the security disclosure.