[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MySQL 5.5 EOL before Debian 8 LTS ends



Hello!

pe 28. jouluk. 2018 klo 9.27 Jan Ingvoldstad
(jan-debian-lts-2014@oyet.no) kirjoitti:
>
> On 2018-12-27 18:51, Lars Tangvald wrote:
>
> > Upgrading to 5.6 would be less risky than MariaDB 10.1, but it's a
> > similar sort of risk.
>
> I don't know what the risk with switching to MariaDB 10.1 would be, but
> as a general principle, MariaDB lags behind (the already annoyingly
> delayed) Oracle security patches often days, sometimes weeks.

Just to set facts clear: most of the Oracle CVE's are fixed in MariaDB
releases way before the Oracle releases, some times even 6 months
ahead. What happens when the Oracle CVEs are released is to a large
degree just an update to the list of CVEs on what version of MariaDB
fixed what. Sometimes there for sure are cases when Oracle publishes
something first, but it would be very wrong to say that MariaDB is in
any way 'annoyingly delayed'.

If we take as an example MySQL 5.5.62 released on 2018-10-22, it
contained the following CVE fixes:
- CVE-2018-3133 - Fixed in MariaDB 5.5.59 released on 2018-01-19
- CVE-2018-3174 - Fixed in MariaDB 5.5.62 released on 2018-10-26
- CVE-2018-3282 - Fixed in MariaDB 5.5.62 released on 2018-10-26

Source:
https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html
https://mariadb.com/kb/en/library/mariadb-5559-release-notes/
https://mariadb.com/kb/en/library/mariadb-5562-release-notes/
https://mariadb.com/kb/en/library/security/

However, the severity if these CVEs vary very much and there are many
details that blur what should be used as a relevant argument and what
not, so I would not use this as a main factor in the decision.


> Based on our experience with a few thousand databases, though, upgrading
> from 5.5 to 5.6 is as good as invisible for DB users and software using
> MySQL.
>
> A few users noticed the differences between MySQL 5.5 and MariaDB 10.0
> (5.6-based), nearly no-one noticed the upgrade from MariaDB 10.0 to 10.3.

MariaDB has a tradition of honoring backwards compatibility, thus the
upgrade from 10.0 to 10.3 should go pretty smooth, but to be safe we
should maybe build some gitlab-ci.yml file to test this particular
scenario extensively to be safer.
Pull requests on
https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines are
welcome :)

> It would be very welcome if upgrade scripts in Debian would substitute
> configuration options correctly, with the usual dselect option list of
> "compare, keep current, install package maintainer's" versions.

Good idea! Would you want to contribute such functionality to the
MariaDB preinstall scripts (or even upstream mariadb_upgrade binary)?

https://wiki.debian.org/Teams/MySQL/patches
https://mariadb.org/get-involved/

> The risk mostly lies in software relying on the removed features listed
> in the URL you linked
> (https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html#mysql-nutshell-removals).
>
> As a side note, anyone using MySQL WorkBench with MariaDB 10.x or MySQL
> 5.5 will probably be very annoyed about the version warnings.  I expect
> the current issues with 5.6 compatibility alerts to be fixed. :)

This "bug" has been known for years and it does not look like Oracle
will fix their product to be any more MariaDB-compatible
(https://www.mysql.com/products/workbench/). Only thing here is to
either patch it in Debian, or suggest users to migrate to alternatives
(https://mariadb.com/kb/en/library/graphical-and-enhanced-clients/).


Reply to: