Answer: When Oracle acknowledges the bug in 5.5.25 (to the owner only), corrects the bug in 5.5.27 (to the owner only), yet hides all information of its existence.
Recently a colleague and good friend discovered a bug in MySQL 5.5 replication that would crash MySQL. This was initially reported as Bug #65740, and after a lot of back and forth, a reproducible test case was found. Excellent work on the part of my colleague to spend the time to clearly identify the specific conditions. I remember looking at this initial thread in detail for an UPDATE statement using variables combined with an –ignore-database configuration option.
For no explanation by Oracle, this bug was subsequently marked as private (after I originally viewed the thread publicly), corrected, and the corrected bug is not referenced in the 5.5.27 Release Notes, yet the private bug clearly states.
[20 Jul 11:59] XXXX Fixed in 5.1.65/5.5.27.
The reason why I raise this concern is due to the lack of consistency. Why this was not included in the Release Notes is not acceptable in my view. However, the installation of 5.2.25 was needed to address another obscure Bug #45670 that was corrected and remains open to the MySQL Community.
I do not know of [yet] a public statement by Oracle that details why certain information about MySQL is open, and certain information is closed.
Yes, I agree. It is inconsistent and guidelines for ‘privatization’ are unclear. I actually filed a bug report about this years back (before Oracle – maybe even before Sun took over) requesting such guidelines. I sometimes have the impression that the primary reason for ‘privatization’ is simply because the issue is embarrassing for specific people in Oracle/MySQL team sitting on the ‘privatization button’.
At least after an updated version with a fix is available the report should be ‘un-privatized’ (and release notes should have details, of course). As long as no fix is available a crashing bug can be hidden I think – in particular if it is easy for a malicious user to utilize the bug to crash a ‘shared server’ and as such cause ‘denial of service’ to other users.
.. but additionally I’d say that it is not worse now than it was for 5 years. I think it is slightly better now actually (without having exact statistics on it) than was the case around the MySQL AB -> Sun ownership (½ year to both sides).
@Peter. I would concur with your comment that security is a concern. However is that a reason to privatize, or to mask some details.
I would like to recommend that when Oracle does mark a bug as private, there is always a public abstract, and a valid explanation for why the “privatization button” was pressed.
Sergei G from Monty Program reported on the internals mailing list that several (many?) bugs were fixed in the most recent 5.5 release without a test case in the regression test suite. He asked for someone to explain whether this was done on purpose. We are still waiting for an answer since August 9.
Slightly less open source
If the crash is something that can be triggered by a non-admin user, it’s likely to be treated as security by Oracle now, and any public info on it heavily obfuscated. It may re-surface months later via a Critical Patch Update in form of a CVE with no details allowing mapping it to an actual flaw. Though, you may ask in bug if it’s treated as security and request information about what CVE is / will be assigned to it and make it public to help those who won’t get it if they ask.
http://www.attrition.org/pipermail/vim/2012-June/002562.html
The above is likely to provide an explanation to the Sergei’s query, as an attempt to avoid similar:
http://www.h-online.com/security/news/item/Oracle-accidentally-release-MySQL-DoS-proof-of-concept-1526146.html
Back when I was pushing hard for answers on Oracle’s non-disclosure policies this was explained to me. Basically mysql engineers have their hands tied by the policy if it is deemed a security problem. A crash caused by non admin users is considered a privilege escalation. So, we will not be seeing test cases (since they are taylor made exploit scripts) nor will these bugs be made public again. :-[ I suspect they the desire not to disclose info about security bugs may also be delaying the bzr tree updates as well.
Hello Ronald,
we also open a bug #65831 (http://bugs.mysql.com/bug.php?id=65831) and it was mentioned as a duplicate of yours by Valeriy Kravchuk. And then it was crossed out..
When we tried to look at your bug, the only message displayed was “You do not have access to bug #65740″ (bug was mark as private)
Thank to Google cache, we were able to look into it and it looks in fact very similar to yours..
Why did your bug was marked as private but not ours ?
When we looked into the changes of 5.5.27, there is no mention of either your bug or ours ??
We also never received a notification that our bug was fixed, or was it ? Message from Hank Eskin is not clear as he mentioned your bug number but crossed out..
Note: an other similar bug listed in Percona (https://bugs.launchpad.net/percona-server/+bug/1028356) was referred as a duplicate.
I filed the original bug 65740. What concerns me is that I’m not sure this qualifies as “A crash caused by non admin users is considered a privilege escalation.” since two independent conditions must be met before the crash happens:
1. Some form of “replicate-wild-ignore-table” or “replicate-ignore-table” has to exist in the my.cnf file
2. An update statement using @ variables (this statement my crashing slave: “update test set rank=@rnk:=@rnk+1″)
Only the update statement can be submitted by a non-admin user. Only an admin user can add the replicate-ignore statements to the my.cnf file in order to cause a crashing slave. If there are no “replicate-ignore” statements in the my.cnf file, the update statements work as expected without crashing the slave.
So I don’t see why this is a security hazard triggered by a non-admin user.
Finally, if the bug itself is replicated and marked as duplicates elsewhere in the MySQL bug database (and Percona’s), then what exactly is being accomplished by marking the original bug as private?
… Because “All people are equal but some are more equal than others!”
Oracle is obviously trying to protect it’s company interest and I do not see anything wrong in it.
The community / customer will pay the price for non-transparency and the price is always fair once paid in full.