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.
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.
How is what you are describing any different than what happened today? Except the vulnerabilities were also explained. You can say that sites are getting hacked right now due to them releasing the security update.
>I'm some rando so no one's even heard of me
Why do think people need to have heard of you. If you are reporting this issue directly to distro maintainers, security companies, hosting companies, etc first you can help use their names as part of the marketing push to raise awareness.
2 months ago there was no patch and no possibility of a very quick patch. Releasing details then would have been very bad.
If you mean they should have released the patch as soon as it was done, it's true that it would have been before the bug was public... for about five minutes. When a warning a day or two before patch release works, it lets admins prepare to patch immediately and/or shut down their servers before the release time.
Even with the leak, admins still had warning and it was better than an unwarned official patch drop. Which itself is better than an unwarned unofficial patch drop. Which itself is better than an unwarned drop of exploit details.
We are talking about a hypothetical where a patch is made <2 months. With AI agents, I can 100% assure you it would take a max of a few days to pat CB and test a mitigation. Not months.
If you are warning people to turn off their servers. You might as well give them a patch at the same time.
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).
The PHP maintainers have generated a certain amount of goodwill over their long service, which leads downstream consumers to trust their releases over every other packaging of "PHP the open source codebase".
Nonetheless, there are countless forks of that codebase, and there are other releases than the ones made by the PHP maintainers. Any particular downstream could switch to another source of releases if presented with a compelling enough reason.
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.
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.
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?
How is what you are describing any different than what happened today? Except the vulnerabilities were also explained. You can say that sites are getting hacked right now due to them releasing the security update.
>I'm some rando so no one's even heard of me
Why do think people need to have heard of you. If you are reporting this issue directly to distro maintainers, security companies, hosting companies, etc first you can help use their names as part of the marketing push to raise awareness.
> How is what you are describing any different than what happened today?
There was an official patch within a few hours. It probably would have been a lot longer.
And that was the screwup case. If today had gone correctly the official patch would have been out by the time the bug was public.
And in the situation where they released a security patch 2 months ago, there would be a security patch before the bug was public.
2 months ago there was no patch and no possibility of a very quick patch. Releasing details then would have been very bad.
If you mean they should have released the patch as soon as it was done, it's true that it would have been before the bug was public... for about five minutes. When a warning a day or two before patch release works, it lets admins prepare to patch immediately and/or shut down their servers before the release time.
Even with the leak, admins still had warning and it was better than an unwarned official patch drop. Which itself is better than an unwarned unofficial patch drop. Which itself is better than an unwarned drop of exploit details.
We are talking about a hypothetical where a patch is made <2 months. With AI agents, I can 100% assure you it would take a max of a few days to pat CB and test a mitigation. Not months.
If you are warning people to turn off their servers. You might as well give them a patch at the same time.
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).
I mean, it's all semantics at the end of the day.
The PHP maintainers have generated a certain amount of goodwill over their long service, which leads downstream consumers to trust their releases over every other packaging of "PHP the open source codebase".
Nonetheless, there are countless forks of that codebase, and there are other releases than the ones made by the PHP maintainers. Any particular downstream could switch to another source of releases if presented with a compelling enough reason.
Did start writing software this week?