To connect to their MySQL database from Perl, the elves had always used the DBD::mysql module. It worked with the MariaDB fork, too.

Recently, the new module DBD::MariaDB had been released. There'd been some confusion at the North Pole...Which one should they use?

Minty Cakesprinkler had been to The Perl Conference in Glasgow 2018 and seen a a lightning talk (video, slides), and was able to explain to his fellow elves the advantages of the new module.

Why you should switch

• DBD::mysql has problems to compile with the recent MySQL and MariaDB clients (versions 8.0+ and 10.2.4+, respectively).

• The original module can use insecure connection even if you requested it connect securely, see CVE-2017-10789. This can lead to a man-in-the-middle attack. The new one refuses to connect if secure connection was requested but it can’t be provided.

• The new module fixes CVE-2017-10788 which allowed remote attacker to cause a denial of service (use-after-free), also causing test failures on some platforms.

• There are several more vulnerabilities that the new module fixes (e.g. workarounds for CVE-2015-3152, CVE-2017-3305, or CVE-2018-2767).

• Unicode is fully supported in the new module and uses the standard Perl Unicode model, i.e. when writing code you always use decoded Unicode strings. Recent DBD::Pg and DBD::SQLite implement the same behaviour.

• The new module has better support for prepared statements and bind parameters.

For a more detailed overview, visit the Changes.

Why you shouldn’t switch

• The way how DBD::mysql handled Unicode was broken. It’s possible that switching to the new module would break your application, returning suddenly double encoded UTF-8 strings. Fixing a database where some values are encoded incorrectly is an uneasy task and the risk of breaking the data completely might prevent you from making such a decision.

History

If you’d like to understand the reasons why DBD::mysql was forked, you can read this thread at PerlMonks. Basically, the most critical fixes were originally applied to DBD::mysql, but because of the reason described here under Why you shouldn’t switch, they were reverted. The GoodData company couldn’t wait for months, so they decided to fork the module.

Various combinations of Perl, server and client versions are continuously tested in Travis CI. There were 164 different combinations at the end of November.

Notes

You can report any problems or submit your pull requests to the GitHub repository.

Thanks to Pali for fixing the issues and GoodData for supporting contribution to open source.