This is a bit ironic since the Stefan Esser actually is “a pair of active eyes”. He’s a security consultant working with among other things PHP.

I found some notice that he was the first to completely break DRM on XBox.

Solved this on my installation for now by setting max_input_vars to 10 million.

http://www.php.net/archive/2012.php#id2012-02-02-1

^ At least something.

Isn’t this the way it’s supposed to work? Stefan does his work and report his findings which leads to a fix.

I would assume it works the same way in the proprietary world, with the difference that Stefan wouldn’t publish his findings to the public and that the update would be pushed out with little information about what it fixes.

@Kim:

And that would be an entirely incorrect assumption, at least for Microsoft. Either the findings are available through Mitre (and hence very public indeed), or they are published on the Web by Microsoft. Typically Microsoft will even link to the findings when they present you with a list of suggested upgrades and fixes.

The depressing thing about the security fix/hole at hand is the sheer amateurishness of it all. The newly-introduced problem is trivially easy to understand, and not that much more difficult to recognise if you have a proper code-review/test procedure in place.

Really, “I fell off the end of the list” is not a difficult edge-case to test.

I can easily understand one developer (in this case Stefan?) generating such an error. In the Real World™, I would be horrified if something like this made it all the way to Prod and was retrofitted to earlier versions.

So… Perl fixed the original hash collision hole properly nearly nine years ago.

So, if open source works the way Raymondites think it does, why did it take this long for PHP to fix the same problem, and why did they not fix it properly instead of resorting to a clumsy hack?

Could it perhaps be that Sturgeon’s Revelation™ applies equally to both open source and proprietary software?

And could it perhaps be that pretending otherwise of open source software merely leads to crappy software becoming immortalised as crappy software rather than evolving or dying as it should?

“Isn’t this the way it’s supposed to work? Stefan does his work and report his findings which leads to a fix.”

See the fix: http://bit.ly/zbSusR
Reminds me of this one: http://bit.ly/hBzibJ

The thing is that PHP had in both cases absolutely zero revisioning or thought. PHP ships with ~90 unit tests broken currently (both 5.3 and 5.4) and nobody cares ( oops, https://bugs.php.net/bug.php?id=55439 we accidentally unit test ). Yes, 80-90 btw, http://gcov.php.net/viewer.php?version=PHP_5_3 and http://gcov.php.net/viewer.php?version=PHP_5_4 – obviously an OK build. As for the float point vulnerability, this is also awesome -> http://www.exploringbinary.com/a-better-fix-for-the-php-2-2250738585072011e-308-bug/

That all shows that PHP is coded by monkeys without zero understanding of producing production level code. Shipping failed unit tests, clobbing together random and often stupid patches – the volatile fix is moronic, just read http://www.exploringbinary.com/why-volatile-fixes-the-2-2250738585072011e-308-bug/ – and all that is why PHP is of such awful quality. Not to mention that Microsoft made more progress with their WinCache than PHP’s official APC.

I am seriously considering to just scrap this and use Phalanger, but as of 3.0 it is still beta quality only.

> Isn’t this the way it’s supposed to work?
I though that many eyes make bugs shallow. And by shallow among other things I understand that the fix is trivial. And by fix I understand something that doesn’t convert less severe vulnerability into more severe one.

Don’t blame that on Linus (“Linus’ Law”), blame it on ESR. Mind you, I’m not even sure of that; but, if anybody, ESR was the one to derive the false corollary that, if finding a bug is trivial, fixing it is equivalently trivial. I think Linus would be horrified at the thought.

Naturally, if indeed the Loons think about “fixing” things at all (I have yet to be convinced), they cling desperately to the false corollary.

Actually, IMHO, many eyes make fixing a bug exponentially more difficult. It’s hard to hear the brook above the babble.

Sometimes you can take “peer review” a little too far…