| ▲ | charcircuit 4 hours ago |
| Why does the PHP security team need to acknowledge it and develop the fix? It's open source software. |
|
| ▲ | lokar 4 hours ago | parent | next [-] |
| If you want an orderly fast global rollout you need to have the maintenance team and distributors working together. |
|
| ▲ | warkdarrior 2 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | sam1714 23 minutes ago | parent | next [-] | | 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). | |
| ▲ | charcircuit an hour ago | parent | prev [-] | | They already were in communication with each other. They could have come together and decided on one that mitigates the issues they've found. |
|
|
| ▲ | weird-eye-issue 4 hours ago | parent | prev | next [-] |
| So anybody can just push out a new release of PHP? |
| |
| ▲ | charcircuit 2 hours ago | parent | next [-] | | Yes, someone could have published a safe version for people to use for the 2 months to get the actual fix done. | | |
| ▲ | john_strinlai 2 hours ago | parent [-] | | >Yes, someone could have published a safe version this is basically the same as releasing a working exploit. | | |
| ▲ | charcircuit an hour ago | parent [-] | | And that's not a bad thing. If it was, the the logical conclusion would be to never publish the fix and don't preemptively patch before active exploitation. | | |
| ▲ | solyin 33 minutes ago | parent [-] | | Yes it is. Say I release a fix. I'm some rando but I go out to the world and say I fixed an issue with php. Use my version instead! Not telling you what I fixed, it's a secret, just trust me. It will take, with LLM help, attackers a couple hours, tops, to reverse engineer my fix into active exploitation. Meanwhile, I'm some rando so no one's even heard of me, people who do hear don't automatically trust me to install my fix, so very few people have my fix. Meanwhile, the exploit is out there thanks to me and people are getting their sites hacked thanks to me. That seems like a problem, no? |
|
|
| |
| ▲ | swiftcoder 4 hours ago | parent | prev [-] | | 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. | | |
| ▲ | LordDragonfang an hour ago | parent | next [-] | | 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). | |
| ▲ | 0x457 3 hours ago | parent | prev [-] | | Did start writing software this week? |
|
|
|
| ▲ | wat10000 4 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | theboblong 3 hours ago | parent [-] | | 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?! | | |
| ▲ | aDyslecticCrow an hour ago | parent [-] | | 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. |
|
|
|
| ▲ | justinhj 4 hours ago | parent | prev [-] |
| What would you have a security team for then? |
| |
| ▲ | 2 hours ago | parent | next [-] | | [deleted] | |
| ▲ | charcircuit 2 hours ago | parent | prev [-] | | 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. |
|