Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
My take on privatized MySQL security bugs
+4 Vote Up -0 Vote Down

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.

Votes:

You must be logged in with a MySQL account to vote on Planet MySQL entries. More information on PlanetMySQL voting.

Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.