tag:blogger.com,1999:blog-3080615211468083537.post4475764085684342838..comments2023-09-27T11:36:08.392+03:00Comments on Blog of (former?) MySQL Entomologist: On responsible bugs reportingValerii Kravchukhttp://www.blogger.com/profile/13158916419325454260noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-3080615211468083537.post-7098887658292027432014-02-09T23:05:09.070+02:002014-02-09T23:05:09.070+02:00(sorry for the removed comment, just had some inte...(sorry for the removed comment, just had some interface problems)<br /><br />I think we should follow the common practice for *real* security vulnerabilities, involving unauthorized access and such. It is all about pros and cons; for regular crashes, benefits of hiding them just don't outweigh disadvantages. For security holes, it's a different story. elensthttps://www.blogger.com/profile/16293598411807790232noreply@blogger.comtag:blogger.com,1999:blog-3080615211468083537.post-58861648926079598692014-02-09T22:56:58.108+02:002014-02-09T22:56:58.108+02:00This comment has been removed by the author.elensthttps://www.blogger.com/profile/16293598411807790232noreply@blogger.comtag:blogger.com,1999:blog-3080615211468083537.post-87392198999743420532014-02-09T20:55:47.487+02:002014-02-09T20:55:47.487+02:00I agree 100% with your statement that hiding bugs ...I agree 100% with your statement that hiding bugs is a disrespect to bug reporters and Community in general. Bug reporter tried to add some value for the benefit of all other users, but it was hidden. Moreover, even bugs fixed in all versions affected often remain hidden just because they are forgotten or as a yet another form of "care" about users (explained as "some poor soul may still use 5.5.0 or even 3.23.xx, so we can not make test cases public to protect them").<br /><br />Now, back to upgrade requests. It does not make sense to ask for check on recent version when there are clear steps on how to reproduce the bug in the report. But when there is no test case or any details to start searching for known bugs, just some random crash happened once in a while and then reported, further steps depends on how much each side care about this. If a person who processes bugs care a lot and feel some serious problem behind, she may spend days and months working of test cases. If, on the other hand, bug reporter really cares, she can spend few minutes for upgrade (that may be useful and planned/postponed for many reasons anyway) or setting up some (virtual) machine to run a slave of recent version and add it to existing setup. These days it should not take weeks and months.<br /><br />But this ("responsible processing of community bug reports") if off topic here. Questions are: should bug reporters or community members who care about MySQL bugs hide known cases of crashes or, instead, write about them everywhere?<br /><br />My position is clear: we should NOT try to hide anything. Oracle (or vendors of other MySQL forks) may try to do this if they want, but why should we do? So, IMHO, all bugs should be reported in public and explained to all community members who care to read.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3080615211468083537.post-21025367680849901982014-02-09T19:56:34.246+02:002014-02-09T19:56:34.246+02:00I think you misunderstood my point in regard to th...I think you misunderstood my point in regard to the old versions. <br /><br />It's perfectly fine if you say, "Yes, there was a bug like that, see link, already fixed, please upgrade". But it is *not* okay to say "your version is rather old, please upgrade, even though you cannot see fixed bugs because they are hidden and you cannot know if your upgrade effort should do you any good at all; and you also cannot search current open bugs for known regressions that will affect you after upgrade much worse than the bug you are trying to get rid of. But please upgrade anyway, just because."<br /><br />Many people cannot "check the new version" just for the sake of it, they don't have a test farm to play with, or time to do it. Yes, we might not owe anything to unpayed users, but everyone who reported a reasonable bug has already made some effort for the benefit of the community, the least they can expect back is some respect. Hiding bugs from them and their bugs from other people (unless they asked to) is anything but respect. elensthttps://www.blogger.com/profile/16293598411807790232noreply@blogger.comtag:blogger.com,1999:blog-3080615211468083537.post-33949706162856047722014-02-09T18:48:14.422+02:002014-02-09T18:48:14.422+02:00One of that cases when comment is much better than...One of that cases when comment is much better than the original post! <br /><br />I agree with almost everything above, even though my sympathy for poor community users without a clearly repeatable test who are asked to check the recent MySQL version first are notably lower...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3080615211468083537.post-40590817456547249182014-02-09T18:08:34.362+02:002014-02-09T18:08:34.362+02:00"All crashes to be hidden" policy remind..."All crashes to be hidden" policy reminds me of a guy who once explained why he wasn't using blinkers on a road. He said that he was afraid of road-racketeers, and by not using blinkers he was making sure they don't know when to make their move to cause the intentional collision. I could never believe that somebody can be so stupid if I hadn't heard it myself. I think for any brain it's obvious that the only people who are *not* affected by his behavior are those road-racketeers because they need much more precision than blinkers provide to make the right move. All innocent people are in danger, though. <br /><br />People with malicious intentions do not need *many* ways to cause harm, they need only one that will always work. And among those, a crash is a quite inefficient way for DoS on a shared server. Server goes down, a few queries fail, server gets restarted automatically, all is up again. Big deal. If one does it several times, you know it is fairly easy to figure out which connection causes a crash and who it belongs to (much easier than to figure out the actual scenario). If the server is watched at all, in no time the user can be warned or blocked. Besides, crashes get fixed and the villain will have to find another one. Legitimate ways to do the same are much better and more reliable.<br /><br />Hiding bugs has nothing to do with users' safety or with reason in general. It is a policy which originated outside MySQL and was simply enforced on it at some point, and users' interests is a rather questionable excuse.<br /><br />I suppose you communicate with customers (or at least communicate with those who communicate with customers). How many times did it happen that crashes in their server were actually caused by a repeating malicious attack? As opposed to -- how many times did it happen that crashes were caused by their own or their clients' software which unwillingly triggered a bug of the server -- in which case, if you already knew about a similar bug, or could google it easily, you would give them good advice right away on how to tweak the query or server options to avoid further problems until it's fixed; or, if you couldn't find the known similar bug, you could spend days or weeks trying to figure out what's going on, while the server would keep crashing. <br /><br />And that's customers who can at least expect that you'll do this research for them. What about community users? Would it not be so much simpler if they could actually look through existing bugs and see which one they are likely to have encountered? Instead, it all works backwards. The only thing they can do is to report a new one, because old ones are not searchable. If they happen to report an original one, they will be asked for a lot of information which they don't necessarily have, in order to reproduce, which they aren't necessarily able to. If they report a bug for an older version, they will be first asked to upgrade, just to see the problem still exists, without being pointed at an old fixed bug that might affect them (as if it's so easy to upgrade a production server on a whim). If they report something already known, their report will be closed as a duplicate without them being able to watch a progress of the original one because it's either private or internal. So, how any of this is in the best interest of users?<br />elensthttps://www.blogger.com/profile/16293598411807790232noreply@blogger.comtag:blogger.com,1999:blog-3080615211468083537.post-61361307040300534282014-02-09T16:58:07.182+02:002014-02-09T16:58:07.182+02:00Yes, I am a human and thus I also was inconsistent...Yes, I am a human and thus I also was inconsistent more than once for sure in my decisions...<br /><br />My main point is: following formal Oracle policy that is public for cases like the one discussed is hardly useful for the community and hardly makes sense for open source software.<br /><br />On the other hand writing everywhere in public about yet another crash may do attract some attention of people with malicious intentions, who can then try to break all kinds of shared MySQL hosting providers using one more hint (on top of other ways they already know above, few of them mentioned in your comment, Peter).<br /><br />Also it was interesting to get email on being more responsible from a company who had not only missed a simple crash for a long time (that is, probably saves on QA efforts), but also do not monitor bugs close enough in 24x7 mode (or at least as close as I do, having other job to spend time on) and, what's more important, has too many assertion failures in the code for cases that can now probably handled more gracefully (just kill the statement that is causing assertion and mark table as "broken" maybe). All this on top of no user limits on CPU/memory or disk use...Valerii Kravchukhttps://www.blogger.com/profile/13158916419325454260noreply@blogger.comtag:blogger.com,1999:blog-3080615211468083537.post-58340012184323803772014-02-09T16:43:55.054+02:002014-02-09T16:43:55.054+02:00It has been discussed many times if an easy way to...It has been discussed many times if an easy way to crash the server by a non-privileged user is a "security issue" or not. Oracle themselves are not consistent in this respect (in bugs.nysql) and you weren't either when you were there. I also remember Shane Bester posted quite a lot af crash reports with single statements not even accessing a table. I don't know if those reports are still open, but they were for a long time.<br /><br />The reason why an easily reproducible crash may be considered a security issue is "shared hosting", where MySQL as everybody will know is the preferred database (even though it is not really fit for it IMO - it lacks sufficinet user based quota settings for instance). But if this is the case any query spinning the server up to 100% CPU for several minutes for the query also is. It is effective 'denial of service' by one user against other users. But who can prevent an unexprienced user to execute a full cartesian JOIN from his phpMyAdmin access to the database anyway? Or prevent him to write and execute a routine entering an infinite loop?<br /><br />In non-shared hosting most of this this can be preventing by securing against SQL-injections, proper use of user privileges etc.<br /><br />I think the Oracle person you contacted overreacted - at least if you FB posts were not shared fully publicly - and only to 'friends' (what ridicolous term, BTW!). I have experienced inconsistence myself wiht "privatization" og bugs - and in a few cases I had the impressison that the real reason was that the bug was too embarrasing for somebody and Oracle/Sun/MySQL and it was not a real security concern. In other words: I suspect it was more concern for "self_protection" than "protection of users" that led to "privatization" in those cases.<br /><br />As a generalreply I would find it relevant to share such bugs to anyone who 1) can understand the underlying reason 2) can do something about it 3) have any legit reason to know about it - but at the same time try to the avoid to shared with person who only have interest in using it as an exploit for bothering other people.. <br /><br />But I realize it is not easy to accomplish that balance!Anonymousnoreply@blogger.com