Hello! pe 28. jouluk. 2018 klo 9.27 Jan Ingvoldstad ([email protected]) 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/).
