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.
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.
7 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).
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?