You don't need to be "using" POST to be vulnerable. Unless you've explicitly stopped apache (or your web server of choice) passing on any post variables, or explicitly stopped PHP populating the $_POST array automatically, you will still effectively be using POST.

If you get data in from users via any other mechanism, and then you populate an array with it, you will be potentially vulnerable.

Luckily, sane minimal execution times and memory limits will mitigate any vulnerabilities. It's easy to set these in PHP, unlike some other languages,

A quick way to work around for most websites is to set max_execution_time or max_input_time to realistic values (for most sites 10 seconds or such is fine).

The default max execution time (60 secs) will stall casual DOS attempts, though depending on the setup one malicious call can fill 500k+ of memory in that time, so multiple concurrent calls can bring down a memory-poor server. Setting a lower execution time as above (or if your scripts need time but not memory, setting a lower memory_limit) can lower that memory usage and so raise the bar (to the point where a calling a script in a normal way would be just about as effective a DOS).

In my opinion, it is as much an affect of a legitimate design feature as it is a design flaw, and any attempt to fix it must take that into account.

They've actually developed this for use in their iterative development process, not for production. It is significantly quicker than the standard PHP engine but doesn't have the overhead of static compilation. Shaves small amounts of time off, but it all adds up. The original HipHop static compiler which they use in production is significantly faster.

The static version did indeed work for them, it's currently used in production across Facebook. The JIT version was developed for use during development, the existing optimised version of the standard PHP engine they were using wasn't fast enough and had incompatibilities with HipHop. So they developed the JIT version for development to speed iterative development (without the overhead of static compilation), and then they deploy to production. I hate Facebook, I don't have an account, but I do like some of their engineering practises and processes.

They have a static compiler, called HipHop (NOT the HipHop VM that this article refers to) which is used in production as we speak, and it came before the JIT version.

Well now you've met at least one, me. Virtually met, anyway.

I'm probably considered a power user (programmer as a day job, using Ubuntu with Unity at work and home), and for me it does what I need, its intuitive and simple, and gets out of my way to let me be productive (or not be productive, depending on my mood!). I can see a few rough edges/bugs, but 11.10 irons most of those out and I still quite like it.

The only lesson for Canonical to learn, in my opinion, is to take a little more time when releasing a major change like this to iron out bugs first. I think that had it have worked as intended straight off the bat, many more people would have seen the broader picture of the benefits it delivers, and we wouldn't be having discussions like this.

"True, but only in 20/20 hindsight. Nobody expected water to enter the basement."

In most floods, basements get flooded. From small "I've let the bath over-flow" type floods to "once in a century tsunami" type floods, basements flood. It really is that simple and obvious.

"For the first part, pretty much nowhere has such terminals."

Yes, and that's a problem, not an excuse.

" For the second part, the dividing line is a couple of hundred miles away and irrelevant."

Not when the portable generators you need are over that line there because there's been an earthquake locally and it is quicker to fly in those remote ones than get local ones to the plant via the earthquake shot road system.

"A 'flaw' again based on 20/20 hindsight, huge assumptions as to the outcome...."

Sort of, but the trouble is, in a disaster scenario you're unlikely to have much information until its too late, as in this case. So you have a choice to either definitely ruin the reactor (at a huge cost) but definitely avert a major incident, or risk a major incident and risk ruining the reactor. You can't see into the future and so you HAVE to take a gamble. Its a major flaw with (any) centralised power system like nuclear. Big risks for big rewards, assuming you win.

And failing that, what's the best way to set them on fire?

"Alternatively we could make an active effort to promote effective contraceptives, comprehensive sex ed, and tackle poverty."

Its even easier than that. We promote general education.

Education really is the magic silver bullet to most if not all of the worlds problems. When people are educated, you don't need to promote contraception and tackle poverty, they will work on it for themselves.

While it could have been caught, the bug was actually a result of testing, namely the use of the Coverity static analyzer which flagged up "strcat(passwd, "$");". In this particular case it was safe use strcat, but was erroneously changed to "strlcat(passwd, "$", 1);" to avoid the warning. Its a lesson perhaps that automated tests aren't the silver bullet for avoiding bugs, understanding the code itself is just as important. It also raises the question of whether much of the criticism in the discussions below should be directed at C instead of PHP. I'll stay out of that one...!

I don't think they should have pulled it, if you don't use the the crypt() function the other fixes and features of the upgrade may well make it a worthwhile upgrade. However I agree that the download page should be marked with this information, not just the front page.