The MariaDB Foundation Board has been meeting monthly since February and on Monday this week had the third meeting of the year. Here is an update on a couple of things from the meeting.

We’re happy to announce that has renewed their support to the foundation. As a major corporate sponsor has been offered a seat on the Foundation board. nominated Eric Herman.  Eric has a history with MySQL dating from 2004 where he joined MySQL working on the server and tools.  In 2010, Eric joined where he works on database scaling challenges and BigData. As a community member, he has contributed to the perl MySQL client driver, the perl interpreter, and other Free Software.  To represent community and industry interests in line with the Foundation mission, Eric Herman has joined the Board.

The current Members of the Board ordered by last name are:

  • Sergei Golubchik, Chief Architect, MariaDB Corporation
  • Eric Herman, Principal Developer,
  • Espen Håkonsen, CIO of Visma and Managing Director of Visma IT & Communications
  • Rasmus Johansson (Chair), VP Engineering, MariaDB Corporation
  • Michael Widenius, CTO, MariaDB Foundation
  • Jeremy Zawodny, Software Engineer, Craigslist

Last but not least secretary of the Board is the Foundation’s CEO Otto Kekäläinen.

The list of corporate sponsors so far this year are:

In case your company is interested to support the MariaDB project through the MariaDB Foundation please contact ”foundation ‘at’ mariadb (dot) org”.

It might be of interest that the website is getting a facelift to both look more appealing but also include more relevant information about the project and the Foundation. More about that later.

Last  week, a SSL connection security vulnerability was reported for MySQL and MariaDB. The vulnerability states that since MariaDB and MySQL do not enforce SSL when SSL support is enabled, it’s possible to launch Man In The Middle attacks (MITM). MITM attacks can capture the secure connection and turn it into an insecure one, revealing data going back and forth to the server.

Issue resolution in MariaDB is visible through the corresponding ticket in MariaDB’s tracking system (JIRA):

The vulnerability affects the client library of the database server in both MariaDB and MySQL. But, the vulnerability does not affect all the libraries, drivers or connectors for establishing SSL connections with the server.

The vulnerability exists when the connection to the server is done through the client library libmysqlclient. This client library is provided with the database server and is a fork of the corresponding client library in MySQL. The client library is used by probably the most used tool, the MySQL Command-Line tool of which a forked version is shipped with MariaDB.

In addition to libmysqlclient, the MariaDB project provides the following connectors:

These connectors also support SSL connections to the database server and make use of the similar parameters etc. to establish secure connections. Here is an update on whether the connectors are affected or not:

  • Affected – MariaDB Connector/C is vulnerable in the same way as libmysqlclient
  • Not affected – MariaDB Connector/J does the right thing and aborts any unsecure connections if SSL is in use
  • Not affected – MariaDB Connector/ODBC does not currently support SSL

For MySQL’s Connector/J it is worth mentioning that it has two properties, “useSSL” and “requireSSL”. If “requireSSL” is selected, then unsecure connections are aborted.

Many of the tools that are used to connect to MariaDB or MySQL make use of libmysqlclient. Thus, when using these tools over an untrusted network, it’s highly recommended that you restrict network access as much as possible with normal means, even if you’re using SSL to connect to MariaDB or MySQL. Some best practices that are easy to put in place for decreasing the risk of MITM attacks include:

Finally, since we’re in the middle of fixing the vulnerability in MariaDB, we appreciate your input regarding which versions of MariaDB that should get the fix backported. For background, the SSL support in MySQL (up until 5.7) and MariaDB is not enforceable. This is the intended MySQL behavior, implemented back in 2000, and clearly documented in the MySQL reference manual as:

“For the server, this option specifies that the server permits but does not require SSL connections.

For a client program, this option permits but does not require the client to connect to the server using SSL. Therefore, this option is not sufficient in itself to cause an SSL connection to be used. For example, if you specify this option for a client program but the server has not been configured to permit SSL connections, an unencrypted connection is used.”

MariaDB 5.5 and 10.0 are stable versions and behave as documented – they permit SSL, but do not require it. To enforce SSL, when the appropriate options are given, will change the behavior and might break existing applications where a mix of SSL and non-SSL connections are used. In MariaDB 10.1 this is not a problem since MariaDB 10.1 is still in beta, although it is very close to release candidate status. There we will introduce the fix. As for MariaDB 5.5 and 10.0, we are collecting input to determine whether we should change the behavior of 5.5 and 10.0. Please visit our website for more details, and share your feedback at:

The initial reports on the vulnerability can be found through these sources:

About two and a half years ago I wrote about how the MariaDB project moved bug reporting from Launchpad to JIRA. Every now and then I get contacted about how it was done and whether I would be willing to share the tools used for doing it and of course I’ve done that. Especially in one occasion the scripts were even further developed by one company that was in the process of doing exactly the same, i.e. moving bugs from Launchpad to JIRA. Thanks for the enhancements Philip Colmer from Linaro!

In Launchpad there isn’t a readymade tool for exporting bugs and I didn’t find any 3rd party tools for doing it. Launchpad however has an API through which most (if not all) information in Launchpad can be retrieved. Launchpad has made a library available in Python making use of this API.

By using the Launchpad Python API, I wrote a Python script that pulls out bug information from Launchpad and creates an XML document for each bug. If the bug includes attachments these are also downloaded and named in a way that they can be connected to the XML.

It would, of course, be nice if the bunch of XML files and attachments that you end up with after running the Python script could be uploaded directly into a JIRA instance. Unfortunately this is not possible, unless it has been added recently, and instead a separate format is needed. According to my investigations, JIRA supports importing information best if it’s in CSV (comma separated values) format. That leads to converting a bunch of XML files to a CSV file. The CSV file can include links to the attachments.

I’ve done quite a lot of C# programming in the past and still had the way of dealing with XML in C# in my head, so I chose to do the XML to CSV conversion in C# in a Windows command line application. You’ll find the application named JiraCSV in the Github repository mentioned below.

The scripts described above have been useful for those that have reached out explicitly asking for a copy of them, but maybe the interest is broader. To initially get to the point where migration was successful it took a lot of trials to correct the data, add missing data, change the XML or CSV structure, and so on to get everything accepted by JIRA. I hope that by now sharing these scripts people will save a significant amount of time. That’s why I’ve decided to put them up on Github so that anyone interested in them can pick them up and make use of them or even improve them further. You can find them at