A month ago, members of the wider MySQL community complained that the patches to bug fixes included in the 5.5.27 release of MySQL came with no new test cases. As a blog post at MariaDB commented, "We had pretty strict policies about it in MySQL AB (and, later, Sun Microsystems) — every new bug fix always had to come with a test case for the bug." So publishing bug fixes without test cases is a significant change. It is a lack of transparency that disadvantages every community member apart from Oracle, further skewing the market.
So when I heard Oracle's VP of MySQL development Tomas Ulin at the OFE Summit in Brussels assert that "claims Oracle is closing the source of MySQL are just FUD," I felt I had to investigate a little. I had a long conversation with a person extremely well-placed to know the facts (who due to their employer's policy concerning public comments -- even in community contexts -- prefers not to be identified). I learned that:
- A blog posting earlier in 2012 had pointed at test cases as a place to get ready-made source code to exploit security-sensitive defects in MySQL.
- In response to this, Oracle's security team insisted the MySQL developers not publish test cases associated with bug fixes in GA releases any more.
- Although the MySQL team is aware this obstructs co-development and is opposite to the practice of most communities, internally to Oracle they have been unable to make the case for community transparency (even to the extent of giving this explanation publicly)
- Test cases will continue to be published in the future, including those for bug fixes as long as they are not part of a GA release which will end up being widely exposed as a consequence.
That extra background makes some sense, even if it is little comfort to community co-developers. For software like MySQL that plays a critical infrastructure role but is frequently hard to update because of other software dependencies, it is at least arguable one should keep the source code for potential exploits private. On the other hand, open source is a team activity and it's bad for any team player to exclude others from the shared tools needed to co-develop.
Open source depends on the equality of peers, achieved through extreme transparency. As MySQL community members I consulted pointed out, this is hardly the first time Oracle has taken steps that reduce transparency and the ability to co-develop on MySQL, so the assumption the withholding of test cases is a further mis-step is hardly unwarranted.
Is there any way to address both needs? I think there is. Apache HTTPD - the world's most popular web server - faces exactly the same challenges as MySQL. Their solution is to maintain a security team, open to any community member recognised by the community as having both the skills and the need to participate, where bugs can be discussed and patches to them shared.
It seems to work well, with Apache members able to respond rapidly to security issues without automatically exposing details of every vulnerability publicly before deployers have had a chance to respond. The project also honours reasonable embargoes regarding security issues and ensures that (if they want it) the person/entity that found the bug gets credit for finding and/or fixing it.
Jim Jagielski, president of The Apache Software Foundation and a long-time HTTPD contributor, told me: "We at the ASF try to handle security in the same way we do our development: openly, honestly and transparently. The risks of premature exposure of security issues is well known, and it's important that we quickly and completely close these bugs."
If this works for Apache, might it also work for Oracle as steward for MySQL? They would need to include all members of the wider MySQL community who wanted to join (such as those from MariaDB and companies like Percona). If security is indeed not just an excuse for closed behaviour, perhaps they will give it a try.
Find your next job with computerworld UK jobs