Comment by asah
5 hours ago
-1: if the fix breaks customers in other ways, they're screwed as well. Damned if you do, damned if you don't...
5 hours ago
-1: if the fix breaks customers in other ways, they're screwed as well. Damned if you do, damned if you don't...
It's a upstream targeted fix that was made available significantly faster in packages/images maintained by volunteers, it's not some untested downstream patch. Customers at this point would have likely taken their applications offline over this issue so it would have been difficult to make the situation any worse.
Given the sheer number of PHP applications out there, it's impossible to conclude with certainty that this targeted fix will have no regressive impact without significant testing. How much testing needs to be done is debatable, but I'm pretty sure the answer isn't zero.
Someone with a single gigabit internet connection can scan the entire IPv4 address space in less than a day. When you have public RCE vulnerabilities like this, your options are "apply the patch", "take the system offline until you can apply the patch" or "get pwned".
5 replies →
Nearly every other vendor has pushed fixes for it, including where they pull their upstream stuff from. There's no excuse.
I don't think you're being understanding or empathetic here.
Any vendor that delivers updated packages without thorough regression testing that ends up causing an incident for their customers as a result will get a thrashing from the community. Remember the CrowdStrike BSOD incident in 2024?
Maybe Ubuntu and others are cutting corners to deliver more quickly. It's their risk to take, but it's still a risk.
Every vendor is winging it there. Even RHEL. Ubuntu ships shit half the time as well even on LTS.
If you need to test it you should pin packages.
1 reply →