Howto not treat bugreporters...Monday, November 27. 2006Monday, November 27. 2006 Today I stumbled by accident upon two wonderful examples how bugs should not get treated. One is from the Zend Framework and another one is from the PHP bug system. In both cases bugs are immediately blamed on Suhosin-Patch, although the patch is quite small and is used with lots of software without a single problem.
Comments
Display comments as
(Linear | Threaded)
I'm a dotdeb user, and I totally agree with all your points.
I personally think that the suhosin patch should not have to exist if only the php developers were quick and proactive enough to allow this patch in the main core.. By the way, I have found not a single problem adopting the patch and I use a pretty complex setup with lots of php and a bunch of pecl extensions. posted on Monday, November 27. 2006
Is this the first time you've seen bug reporters treated like this, or if not, are you really surprised at all?
IMO, one of the single largest inhibitors to PHP development & progress is the way bug reporters are treated. It is so common for non-internal developers to be treated so badly that many simply choose to not report the bugs they find and instead just find a way to work around them and live with them, rather than reporting the problem only to be treated like pure shit. OS X also has a number of problems with PHP that have remained unfixed for years ... or go back and forth between being fixed to broken again to fixed to broken again ... largely because the internal developers refuse to take a serious look into the reports and automatically tag them as bogus or already fixed when in fact they haven't been fixed. Though I doubt anything will change anytime soon. Internal developers have commented before that they are aware of the problem (with how bug reporters are treated), but have shown less than little motivation or desire to do anything about it. In other words, they're aware that reporters are treated poorly, and they really could care less. posted on Monday, November 27. 2006
Of course it is not the first time ...
But when "my users" (Suhosin-Patch Users) are victim of this ignorance I have to step in. I do not say that Suhosin-Patch might not have bugs but simply refusing to accept bugs because Patch A,B,C is used is ignorant. Especially because CORE PHP developers should know that I found and fixed several bugs in PHP that I only found because I use Hardening-Patch. Otherwise they would never have hit me, but most probably people on Solaris or with MacOSX because of PPC architecture. (This is just one more reason for PHP CORE developers to have their own systems patched, because that way they will find more bugs. But most PHP CORE developers do not even test with DEBUG versions of PHP) posted on Monday, November 27. 2006
#2.2
Derick
()
[quote]
OS X also has a number of problems with PHP that have remained unfixed for years ... or go back and forth between being fixed to broken again to fixed to broken again ... largely because the internal developers refuse to take a serious look into the reports and automatically tag them as bogus or already fixed when in fact they haven't been fixed. [/quote] I think this is more the result of having a severe lack of any sort of usable debugging tool on MacOSX. posted on Monday, November 27. 2006
When trying to resolve a bug the first step is to isolate the relevant code, which makes identifying the problem easier. When you have a version of PHP that includes added patches, or non-standard modules the first step is to see if the issue can be resolved by disabling the relevant modules and/or removing patches. This is not something Suhosin specific, the exact same thing is done for APC, Zend Optimizer and other extensions that alter the engine's behavior.
You also need to keep in mind that there is a VERY VERY small number of people who deal with bugs day and day out. And those people don't have the time to test every single possible combination of PHP under the sun, hence the narrowing down. Tony is one of those few people and if you look at the NEWS file and ChangeLog you'll see the enormity of his contribution to the PHP project. In regard to claim that most PHP core developers don't compile with debug, I'm sorry Stefan, but that is utter bullshit. I must admit that most developers do not compile their development builds with ZTS, but every single core developer I know, that's actively developing PHP has --enable-debug flag enabled in their dev installs. As far as people who post on blogs and whine about how they are being mistreated by PHP developers in regard to their bug reports. How about you try to deal with bugs everyday and see just how much faulty, incomplete and downright bogus reports are posted and then talk... posted on Monday, November 27. 2006
Sorry Ilia, it is unprofessional to declare a bug BOGUS because person XYZ uses patch ABC.
I don't care if this is Suhosin specific or not. A bug is a bug and you cannot simply declare it as bogus because you don't like the configuration. PHP.net should be happy that people report bugs. It is not the task of the user to recompile his PHP and do all the necessary steps to reproduce it. You can leave it open and marked as Not-Yet-Reproduced but simply closing it as bogus is unprofessional. A simple search on google will reveal that a lot of people had problems with recode.so in the past, long before suhosin existed. I know of the problem and believe this is caused by a (dynamic-)linker error on FreeBSD. Whatever as long Antony and co. declare this bug as bogus and pretend it does not exist, it will never get fixed in PHP (or FreeBSD). And say what you want. PHP 5.2.x DEBUG was broken due to miscalculations in the new Zend Memory Manager. If PHP developers would all use DEBUG PHP they should have found overflows or leaks BEFORE the IBM guy reported the miscalculations... I wish the PHP.net bughunters would stop whining everytime someone talks about bugs in public. posted on Monday, November 27. 2006
I have PHP 5.2 compiled with DEBUG mode and I even have valgrind tests done on it periodically not to mention "make test". Guess what, neither of those showed that there was a problem with the memory manager. In fact the publicly available test harness at gcov.php.net did not exhibit any errors that could've been traced to the allocator.
It is possible Sunohin or other engine level extensions helped to trigger the fault making it far more obvious but a stock PHP, even with APC extension (with cli mode enabled) did not show anything unusual. Now going back to recode.so thing. Based on your own analysis you are saying that the issue has to do with FreeBSD linker and not PHP. As such this is a problem outside of PHP and therefor is bogus as far as PHP is concerned. Perhaps the reason for why the bug was marked bogus was wrong, but it does not change the fact that the bug was not a problem in PHP itself. posted on Monday, November 27. 2006
Well Antony revealed the real reason for the bug beeing marked as bogus in his comment:
User does not react when ordered to use vanilla PHP means the problem is in Suhosin-Patch. And my statement is still true. PHP Users (and more and more will come with Suhosin-Patch by default in the future) have to be aware that they do not get any help at PHP.net. Requiring the user to recompile their PHP unpatched is simply no option. The correct reaction to the bug report would have been: 1.) Give us a backtrace 2.) If the backtrace does not directly reveal the problem then tell him to contact FreeBSD or me 3.) Otherwise fix it. It is no help for the guy to recompile and maybe forget one of the extensions or whatever and the bug is suddenly gone. Then the problem is never solved. The current bug processing is like: Microsoft: Deinstall all your 3rd party device drivers before we look into a msword.exe backtrace posted on Monday, November 27. 2006
Most distros patch their PHPs often it is backporting of security patches from newer releases into older versions shipped by the distro. Which is perfectly fine and reasonable. However a number of distros have started applying other patches that are not found anywhere inside the PHP source and as such PHP developers have no point of reference is regard to that code. In most cases they don't even know how that code works, nor can they be expected to.
So, it seems perfectly reasonable to me that the first request would be that the user revert to a stock version of PHP, to quickly identify if the problem is related to PHP itself, or an external component. Especially so, when a report does not contain a backtrace within itself, which is a the most common situation. In fact most bug reports even fail to provide reproduce code, which makes tracking down the reason behind the extremely difficult if not impossible. Going to Google and spending a long time doing research is fine when you have a few bug reports or a lot of people looking at them. When you have posted on Monday, November 27. 2006
Antony never asked for a backtrace, he was just asking the user to test with a vanilla PHP.
So after the user, that maybe has no idea how to create a vanilla PHP because he only uses the FreeBSD ports system to compile stuff, has learned howto compile his own PHP and invested a lot of time in it, he would get ordered to do this again with a Debug PHP and produce a backtrace. Oh wait maybe one of these compilations changed the size of a struct and suddenly everything works without a crash. So maybe in the end the bug is either not resolved because the crash went away, or because PHP developers do not understand the backtrace, or the bug is blamed on Suhosin or the user ends up submitting the bug to FreeBSD. At FreeBSD it might be found that the linker does some strange thing because the PHP build system uses some unstable flag. Maybe the bug is fixed in FreeBSD's port afterwards but not forwarded to mainstream. So in future the bug is still not fixed for NON-ports installations of PHP on FreeBSD. Yeah and now... All the vanilla PHP compilation was for nothing. The user would habe been helped more if he would have been asked directly for the backtrace or if he was told directly to submit this bug to the FreeBSD PHP maintainer. Yeah and now I am awaiting the next excuses. posted on Monday, November 27. 2006
Let's see now, on https://bugs.php.net/ there is a fairly detailed page talking about how to make good bug reports. This page includes information about what kind of things developers are looking for in a bug report, such as backtraces & short code examples. It even goes as far as provide instructions on generating backtraces on *nix and Windows systems.
The user of the bug report either didn't read the instructions or chose to ignore them, since they clearly state that we need a backtraces for PHP crashes. If the user couldn't be bothered to provide adequate information, we can't be bothered to look into it until they do. If people are under the impression that their time is more valuable then those of a small group of volunteers fixing bugs, then they can fix those bugs themselves or hire other people do it for them. Such is the beauty of Open Source software, anyone can open the code and change it to their heart's contents. If the FreeBSD tool chain is broken, hopefully FreeBSD folks will fix it, but given their stance on the realpath() and other similar issues, you maybe in for quite a wait. posted on Tuesday, November 28. 2006
What realpath() issue?
Unlike GLIBC FreeBSD has a beautiful correctly implemented realpath() implementation. And the realpath() Thread Safety Issues were fixed YEARS ago. BTW: For me this thread is closed now. You are not coming up with arguments but with excuses. Of course somewhere there is an explanation howto do something best. That does not change the fact that some users either do not read these instructions, don't know about them or do not follow them. Do what you want, choose to act like you act, but stop to pretend that situation is a user friendly one. Other Open Source Projects are also able to choose less arrogant ways. posted on Tuesday, November 28. 2006
"I also like the statement by the Zend Framework guys that compatibility to Suhosin-Patch is not a requirement."
If you cite correct, they say: "It is not part of our required testing configuration. It's a good idea though to make sure ZF works in this environment. I'll create a separate development task to document the required environment for support and testing." So this reads to me: currently it is not a requirement. However they are thinking about making this configuration a requirement in the future. posted on Monday, November 27. 2006
Hi, this is Bill Karwin, the one who stated that Suhosin is not currently supported by Zend Framework.
Thanks Björn for pointing out that I did acknowledge that it would be good to support hardened PHP, and we will evaluate our testing matrix. I would be delighted if we could add that to the list of supported platforms. My feedback in that bug report should not be taken to indicate anything else. We do not currently have access to a FreeBSD server for regression testing. I'll try to set up a Vmware image and do testing on FreeBSD, but please understand that we must prioritize the work we do. posted on Monday, November 27. 2006
Bill,
if there is really a test that behaves different when Suhosin-Patch is loaded then a) a bufferoverflow was discovered and Suhosin terminates the script b) there is really a bug in Suhosin-Patch because Suhosin-Patch unlike Suhosin-Extension should NEVER break any script. The use of Suhosin-Patch is supposed to be completly invisible to the script. (Suhosin Extension actually can break scripts depending on its configuration, however the default configuration should meabwhile be good enough to not break most of the scripts.) posted on Monday, November 27. 2006
In reply to Stefan, who is known to hate "Antony from Zend" for unknown reason (I'd really like to know this reason, btw):
Unfortunately, the bug tracking system located at bugs.php.net is for bugs in PHP and not for bugs in Suhosin patch. I can understand that you can't imagine there can be any problems in the Suhosin patch, but the truth is that it does change the behaviour of vanilla PHP, hence my polite and reasoned reply to the bug report, where I asked the reporter to try clean PHP sources first and then reopen the report, if he's able to reproduce the problem. Btw, as you can notice, I didn't use "shut the fuck up" or "it's ridiculous" or any other reply, which you personally seem to like so much when you speak to other developers. And since the reporter didn't reopen the report, I believe the real problem was in the Suhosin patch indeed. Unfortunately, I don't have a FreeBSD 6.1 machine near at hand, so I can't test it myself, but I'm sure you do, since you have so much confidence in your words. I would be very thankful if you provide some more information on this issue (gdb backtrace, some reproduce code etc.). Thanks in advance for you cooperation. posted on Monday, November 27. 2006
Antony you are amusing...
"And since the reporter didn't reopen the report, I believe the real problem was in the Suhosin patch indeed. Unfortunately, I don't have a FreeBSD 6.1 machine near at hand, so I can't test it myself, but I'm sure you do, since you have so much confidence in your words." You fail to realize that people just stop loading recode.so or use one of the other tricks they might find when searching for solutions on google, after help from PHP.net was refused. Sometimes these load problems can simply be fixed by moving the extension= statements around in php.ini. You might have stumbled about this if you had actually tried HELPING the guy instead of refusing to help and blame Suhosin. Your comments clearly show that you have no understanding about what the Suhosin-Patch actually does and what not. posted on Monday, November 27. 2006
I read this blog on a regular basis and normally its pretty good but this is just stupid.
You state only partial comments and fail to let people see the picture in its full context, That is just poor "blogging", are you that bad off that you need to troll for traffic? Maybe you should of posted the full response to the Zend Framework issue?? You forgot to post the rest of that comment including "More investigations are needed but I think the bug is not critical because it is related to a specific php configuration." It wasn't marked bogus it was just marked as not critical because it could not easily be reproduced, The bug is still open for anyone to deal with if they have time. Most of the people fixing bugs do because they love what they do and love php, posts like this don't help and if anything push people away from the community. Be part of the solution not part of the problem. posted on Monday, November 27. 2006
Please read the Zend Framework problem correctly...
The guy blamed Suhosin and said that the bug is not that important because it would only happen with one configuration: Suhosin activated. Which was proved to be not true. posted on Monday, November 27. 2006
He made a suggestion based on the current inability to replicate the problem, but left the bug open for further looking into.
Are you that hurt that someone might "suggest" your product was the cause of the problem, He stated it needed further looking into, What more do you want? You keep forgetting to quote the words used "maybe there is something wrong with" "More investigations are needed" That was his assesment at the time based on his current platform and ability to test further. Do you expect him to drop everything on what looks like an edge case? No he marked the problem for later review. The fact that suhosin is or is not part of the problem doesn't matter the least bit, He did what he could to the best of his ability based on the info he had in front of him and in the time he had and your chewing him out for it, Shame on you. So I repeat myself, "Be part of the solution not part of the problem" posted on Monday, November 27. 2006
Richard what are you trying to prove?
The report clearly states that after beeing unable to reproduce it they directly believed this might be caused by Suhosin-Patch and then note that this configuration is currently not supported. It is a bad habit to believe a 3rd party is responsible just because the current system does not allow reproducing it. A "professional" developer tries to recreate the same environment (or atleast a very similiar one) and then checks the problem. After that he might state that Suhosin-Patch is indeed the problem. If Suhosin-Patch is really not a testing requirement there is still the possibility to recreate the environment and leaving out Suhosin-Patch. Which would have resulted in the bug beeing reproduced instead of FUD spread that Suhosin-Patch might be responsible for the problem which ends up in Google and is found when someone searches around. Oh btw... I am not part of the problem. And it is only fair that Google now knows about this, too. PS: Ahh I NOW understand why you are trying to defend the ZF guys. It seems you are also a ZF contributor. posted on Monday, November 27. 2006
#7
Sebs
()
Wht is this here ?
Steffan, calm down. Or it gets a popcorn session. And you like to be serious with your tools, dont you ? posted on Wednesday, November 29. 2006
Sebs,
answering your questions is quite hard because you obviously have spelling problems. "Wht is this here ?" I can only guess what you are trying to ask and if I am correct the answer you are searching for is: "I am showing the public how ZF and PHP developers like to immediately blame 3rd parties before considering the error to be theirs or to even look into it" "Steffan, calm down." I don't know any Steffan but when I get to know one I will forward this advice. "Or it gets a popcorn session." It already is a popcorn session. Seeing ZF and PHP trying to deny that they blame Suhosin for errors that were not caused by Suhosin, or even repeat to blame it within the comments is really entertaining. "And you like to be serious with your tools, dont you ?" I have no problem with being serious. People (including security organisations) are using and recommending my tools in a lot of places. They don't care about PHP.net's ANTI-ESSER campaign, they just look at the facts and see that I am right. posted on Wednesday, November 29. 2006
Sebs,
please spread your propaganda elsewhere. You have no fucking clue about my discussions with the PHP Group or anyone else. And you obviously have no experience about discussing things with PHP.net. And you have no fucking clue about the nice emails I get from PHP.net members wishing me dead, calling me a traitor or similiar attacks/swearwords. And yes I know exactly what I write and in what tone. Because only this tone is realised and wakes people up. And it would not be the first time that after I blogged about something it suddenly gets corrected. And now continue dreaming about your illusionary PHP world... posted on Thursday, November 30. 2006
Add Comment
|
Calendar
Archives Categories Syndicate This Blog Protected By 
|
|||||||||||||||||||||||||||||||||||||||||||||||||
