A couple weeks ago I submitted Bug #67315: Crashing server by stored function referencing user defined variable in query. If you press that link, you can’t see the bug (though I can as I submitted it).
This is due to Oracle’s policy for security-related bugs. Tomas Ulin, Vice President MySQL Development at Oracle , was kind enough to discuss Oracle’s policy with me, and these are the key points as I understand them:
Oracle’s basic approach is to protect its customers. By publicizing security-bugs, Oracle’s customers are vulnerable to black hatters attacks. Therefore Oracle takes measures and privatizes security bugs (crashing bugs can be treated as security bugs since a crash is a form of Denial of Service).
But what of a bug reported in a RC version, as was in my case? There is no strict policy there, according to Ulin. However with a version this close to GA, it is uncertain that a specific bug would be fixed in time. It may happen, then, that a bug would find itself well into GA releases, thereby exposing customers to attacks.
Moreover, GA bugs that are already fixed may remain private, as customers will not necessarily haste to upgrade their working servers for every bug fix.
My take
Bug privatization has disadvantages, as well:
- One could be left with the knowledge that there’s some serious bug in one’s server, but with no way to defend oneself, or take measures against hitting that bug
- Forks are left outside; and for maintainer could try and tackle that bug, thereby improving the product. But with private bugs, forks just have to sit and wait idly.
I don’t necessarily have to have a take on this, but I got curious: how do other organizations work? And very quickly, I got here. And although the domain reads fedoraproject.org, this is also the RedHat Enterprise Linux way of doing it. A bug can be embargoed, even if it’s upstream.
RedHat/Fedora have a notion of embargo expiry time; but I don’t know exactly how that works – I did some looking but could not determine that there is a fixed expiry time at the time of embargo.
Comparing RedHat/Fedora’s and Oracle’s approaches, I’m not sure there’s that much of a difference. Perhaps Oracle is stricter. I did not make a thorough research, but the logic makes sense to me, which makes the policy reasonable in my view.
> crashing bugs can be treated as security bugs since a crash is a form of Denial of Service
99.9% of the crashes can only be triggered by a user who is logged in, and has permissions to do some actions. For example: judging from description of bug#67315, one needs to be able to create/invoke stored functions in order to cause the crash.
Well, if a user is logged in to MySQL, he can cause a DoS. This has been known for years. Popular blogs have provided examples how to cause a DoS:
http://www.mysqlperformanceblog.com/2008/11/28/mysql-for-hosting-providers-how-do-they-manage/
If Oracle has considered this to be a problem worth paying attention to, I suspect we would have seen some development in that direction, like per-user quotas of memory/CPU/IO usage and stuff like that.
I have not heard of them developing anything like that.
What fraction of new bugs are crashing bugs? I understand marking security bugs private for some time, but if all crashing bugs are security bugs and all security bugs remain private for some long period of time then I think the community loses something and Oracle/MySQL eventually loses too.