{"id":5735,"date":"2012-11-08T08:31:16","date_gmt":"2012-11-08T06:31:16","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=5735"},"modified":"2012-11-08T08:31:35","modified_gmt":"2012-11-08T06:31:35","slug":"my-take-on-privatized-mysql-security-bugs","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/my-take-on-privatized-mysql-security-bugs","title":{"rendered":"My take on privatized MySQL security bugs"},"content":{"rendered":"

A couple weeks ago I submitted Bug\u00a0#67315: Crashing server by stored function referencing user defined variable in query<\/a>. If you press that link, you can’t see the bug (though I can as I submitted it).<\/p>\n

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:<\/p>\n

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).<\/p>\n

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.<\/p>\n

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.<\/p>\n

My take<\/h4>\n

Bug privatization has disadvantages, as well:<\/p>\n