>PHP 5.2.3 was released with several security fixes.
>Again not all security fixes are mentioned in the release announcement.
>Again security bugs known to the developers were not correctly fixed.
So the author knew about it for
two weeks and decided to wait for the release to tell us?
How nice.
On the other hand, what would he gain if he tell us about it? Apparently nothing.
But now he has one more chance to say "Na-na-na-na-naa" (c) Eric Cartman
That perfectly demonstrates how the author "cares" about PHP security.
>PHP 5.2.3 does not fix this vulnerability because the PHP developers tried to outsmart our recommendation how to fix the problem.
I honestly tried to find any recommendations from the author and I can't see a word about it.
Though, I have to admit the report did not contain usual personal insults, which I believe is a good sign.
>They have choosen another fix that has other positive side effects but does not fix this vulnerability.
"Another" means there was some other fix proposed (probably by the author?).
But that's just not true unless it was sent by private mail and not to the list, which I really doubt.
Conclusion: yet another
FUD. Go on, tell us more.
since when do you read security@php.net
Please just shut up or spread your lies/propaganda elsewhere.
Stefan Esser
Since when security@php.net are all php developers?
And when will you begin to tell the truth? You talk to security@php.net, not to all PHP developers.
security@php.net is only a very small set of the PHP developers. You already accused me to do not react to one or another of your report but I actually never heard of them, neither I knew that you were the actual author.
> Please just shut up or spread your lies/propaganda elsewhere.
Secondly, being loud and spreading misleading informations (even if the original issues are valid) and insulting does not make your version of a problem more valid than any other.
The security team is representing the WHOLE development team, they speak for the WHOLE team.
If you don't like that then apply for membership on the team and don't cry that you are not one of the choosen ones.
This is however an internal problem of the PHP developers, not mine.
I am not spreading misinformation.
have you actually read it ?
"This vulnerability has been disclosed on the 14th May 2007 to the PHP developers. They were explicitly told that they SHOULD URL encode the session"
"Another fix" clearly means they didn't do the "recommended fix" by vulnerability author, and this "another fix" didn't solve all issues with not encoding..
Sure, I've read the post dated by 1st of June two weeks ago.
Stefan is a smart person, and he has helped out but the way he approaches things will never get anything done.
You have not the slightest clue how PHP developers react when you talk to them nicely.
They ignore you, because they are arrogant and believe to have all answers.
In the end there is only one way to force them to action. Publicly show their incompetence.
They will whine in their blog like this one here but after that they will fix it (or atleast try).
What you don't understand is that what you call whining like a little 3 year old actually is the thing that works. Talking to them like an adult DOES NOT WORK.
While I disagree with what your doing, I do understand the why. The "If they can't behave neither will I" just doesn't cut it. Most people don't put up with that type of thing from there kid why should they from you?
Are there problems with the way some of the People in PHP handle things.. YES, Are you helping, to some point but the question begs, Are you doing more harm then good?
And what about when you talk to them in your usual nasty manner?
Yeah, undoubtedly he has.
This blog entry is based on some ill-founded assumptions about how security vulnerabilities and patches are disclosed and negotiated. If you don't like Stefan's style, that's fine - you make that clear - but you should probably understand the basics of how this process works before you start making larger accusations.
>vulnerabilities and patches are disclosed and negotiated.
Not sure which assumptions you mean - he has reported the issue and got a nice "Thank you for reporting the issue" etc. reply.
After that a fix has been applied and he apparently had a lot of time to indicate that the fix is wrong or incomplete (that would be very appreciated for sure).
But he decided to wait for the release to point that out and blame stupid PHP developers.
Got the idea? It doesn't look like security is important here, the most important thing seems to be one more chance to repeat that PHP developers are stupid.
That's what really makes me laughing.
You see, the PHP team as a whole has burned up all the karma I've been willing to extend it. The language is full of bad API design, bad release management, and bad politics.
APIs: my first exposure to this was discovering that simplexml didn't have getName(), back in the days of 5.1.1. Now, the JSON extension is changing fundamental behaviors (like json_decode('false')) without changing version number--and since the push for inclusion in core, it's been utterly neglected on PECL.
Which just goes to show you PECL is the PHP Ghetto. Anything in PECL might as well not exist, with a few notable exceptions like timezonedb and zip, because you never know when something's maintained or not. I cringe every time I see someone mention APD for debugging, because it hasn't been released since *2004*, and it makes Apache/glibc spew double-free notices all over the error_log if I'm so daft as to try and use it.
And if the PECL neglect isn't bad enough, the main releases have been botched with such regularity that we held on to 5.1.2 until 5.2.0 was released, then moved to 5.1.6 (as it had a few killer features, such as $sxml->getName(), that would really simplify our life). 5.1.0 didn't last long, 5.1.3 was badly broken, 5.1.5 was missing code. And you want me to trust a random rewrite of the memory manager, after all that?
As for the politics, after enduring several long threads (taint mode?) over the months, I finally unsubscribed from internals during the whole "PHAR! Core! PHK SUX!" debate. Although watching the SquirrelMail developer discuss Unicode semantics was painful, too. PHP6 is basically unusable if there's no compatible way to write literal strings in PHP4/5/6 without Unicode, and PHP6 with Unicode. (You'd end up with a situation where PHP6 was incompatible with *itself*.) But the PHP developers refused to see that. (Although this may be an unfair assessment, because I left while that discussion may have been still going on. Certainly it's an accurate characterization of the first four messages.)
It would also be nice if 5.1.x got at least some security-fix love even though 5.2.x is active. As it stands, though, it's not important. I'm not considering PHP for any new development whatsoever.
>PHP6 is basically unusable if there's no compatible way to write literal strings in PHP4/5/6 without Unicode, and PHP6 with Unicode.
Surely PHP4 is not forward compatible with PHP6, I would not even expect it.
That's the reason why PHP6 is called PHP6 and not 4.10.0.
>(You'd end up with a situation where PHP6 was incompatible with *itself*.)
You seem to be noticing only emails you want to notice and ignore emails you don't like.
>But the PHP developers refused to see that.
Oh?
>Although this may be an unfair assessment, because I left while that discussion may have been still going on.
>Certainly it's an accurate characterization of the first four messages.
Ah, that explains everything.
If you are not able to fix security issues yourself, it's not Stefan Esser's fault. Maybe you didn't have the time, or you didn't notice them, or whatever the excuse is. But you cannot decently claim to the world that it's because Stefan Esser didn't report them that there is security issues in PHP 5.2.3. This is FUD.
... You are not far.
And you should really learn to read what Tony actually said. Nobody (absolutely nobody) said what you suggest, but only that a missing mention in the changelog as well as a wrong/to be improved fix were mentioned after 5.2.3 final has been released. It should have been told during the RC phase, that's all he said.
You knew about the problem(s). Or atleast the PHP developers (that are responsible for security) knew about them. It is the job of them to fix it. A security researcher just reports about the issues.
In this case it was even mentioned 2 times in the email conversation that the bug is caused by not encoding the data. The obvious fix is to encode it. Unfortunately the PHP developer will always do the opposite of what I recommend. Fair game. Do what you want, but don't cry afterwards that you ran against a wall. I warned the PHP developers often enough that I am tired of discussing things. There is no discussion. There is only one correct answer and when you do not choose the way simply because it is my way then this is your choice. Don't blame YOUR mistakes on me.
Blog postings like this one here are a joke. The PHP developers should be thankfull that someone reports security bugs. Instead they attack the messanger with FUD and lies (because I wrote explicitly that the failure is that it is NOT encoded). With reactions like this? Why should the messager care about the reputation of the PHP project. Infact the only responsible action is to NOT ACT and show the world how incompetent the security team is.
What sense does it make when the security team looks good to the outside but in reality it is not them that fixes stuff correctly.