PHP Floating Point Bug Crashes Servers 213
angry tapir writes "A newly unearthed bug in certain versions of the PHP scripting language could crash servers when the software is given the task of converting a large floating point number, raising the possibility that the glitch could be exploited by hackers. The bug will cause the PHP processing software to enter an infinite loop when it tries to convert the series of digits "2.2250738585072011e-308" from the string format into the floating point format. The bug only seems to affect version 5.2 and 5.3 of the language." Adds reader alphadogg: "Computer scientist Rick Regan first reported the bug on Monday, and the PHP development team issued patches the following day."
Re:1 day turn-around (Score:3, Insightful)
Or, the OSS software gives it to you for free, but 'as is'. So they can go "Here's a fix for it. If we break something else, we're not responsible. We may try to fix that, or you can go fix it yourself."
In Microsoft's case, if they break something down the line, they have potential lawsuits against them. They try to use EULA's to try and protect themselves, but it's not foolproof. They're dealing with real money, so they have people trying to mitigate further issues. And that usually means heavy testing, on a wide range of their operating system versions and a wide range of hardware configurations.
Re:1 day turn-around (Score:5, Insightful)
Risk management.
Every change is a potential new bug. Even your security patch may bring a new security issue.
You test and you test and you test, but nothing's certain in the eyes of management. So the shipping is delayed, the testing continues, and eventually you have a batch of bugfixes and patches you're fairly certain works well together. Traditionally, you call that collection a service pack, and you ship... ;-)
(Remember the blue-screen problems a Microsoft patch caused some folks a while back? That was embarrassing. So don't kid yourself that this isn't risky.)
This is also why companies prefer to move to an established "cadence" or rhythm. Monthly security patching is Microsoft's preference, for example. IBM has some software divisions which keep to a four or six month "point release" shipping schedule. Not good enough for v9.0.2? Well, it'll probably be in v9.0.3in six month's time...
That cadence helps with testing, and reduces the risk you're taking, and therefore helps to preserve your reputation and therefore your business.
Open source projects often just ship "when it's ready", and are more open anyway. They're not thinking like a company which is trying to manage its reputation and maximise business (well, profits really).
An open source project just wants to ship something that's reliably usable and useful. That changes their motivations, and therefore changes their management of patching and shipping...
Re:1 day turn-around (Score:0, Insightful)
this is the biggest load of BS I've heard in a while... are you a Microsoft lackey or something?
If you want to talk liability: for every published bug they receive, they then _know_ about something that is broken, and (pretending for a second they couldn't use the EULA to protect themselves) they would be liable for any damages that arise from them not acting at that point. Breaking other shit by mistake with the update is not nearly as serious as not taking action against a known problem.
Stop regurgitating the corporate doublespeak... you have presented no good reason for their patches taking forever and open source patches arriving quickly. There may very well be other good reasons, but you haven't stumbled upon any by trying to sound like a middle-management know-nothing suit.
Re:1 day turn-around (Score:4, Insightful)
He's not kidding nor exaggerating at all. If a security fix breaks $foo, then, only because Microsoft and $foo's company is in the USA, can be liable to be sued for it.
When was the last time anyone successfully sued a software company for something like that?
*Now* can we admit PHP sucks? (Score:2, Insightful)
The inconsistent type system, lack of Unicode support, lack of namespaces, quirky parser, and other stupidities (== vs. ===) weren't enough, so. Is this bug inane enough to actually get people to realize that PHP bites?
Re:*Now* can we admit PHP sucks? (Score:3, Insightful)
ignorant hypocritical marketeering = the highest level of insight.
slashdot = stagnated.
Re:*Now* can we admit PHP sucks? (Score:3, Insightful)
The only reason to use PHP is if you're scripting in a shared hosting environment where PHP or Perl CGI scripts are the only options available.
If you're not, you should look at either Python or Ruby. Either will be vastly better, along with some less popular choices like Lua, Groovy, Scala, Erlang...
Basically, anything else. It's not that PHP can't be sufficient, it's that it has a long and hideously compromised development history and actually demands far more of you, the scripter, to make it safe and useful, than does any of the other scripting languages.
Re:*Now* can we admit PHP sucks? (Score:4, Insightful)
"Correct" use of the language is to ignore string functions entirely and use an optional extension, because they don't actually support Unicode. In 2011. Amazing.
You know, C actually has a valid excuse for that sort of thing. But I'm sure you'd rather call people names all day like a retarded skript kiddie, than admit PHP's Unicode handling is ass-backwards and crippled compared to everything else out there.