USN-2384-1: MySQL vulnerabilities partially also applies to MariaDB

Patch attached. Here are the steps to deploy this patch:

1. apt-get source mariadb-server - on Trusty will download and unpack mariadb-5.5_5.5.39-0ubuntu0.14.04.1.debian.tar.gz

2. Download mariadb-5.5.40.tar.gz from https://downloads.mariadb.org/mariadb/5.5.40/#os_group=source and rename it to mariadb-5.5_5.5.40.orig.tar.gz

3. Check that sha256sum matches:
cbde17f4a31483143490def6fcce33310ebae49eafe92dc4ada0e7227202415a mariadb-5.5_5.5.40.orig.tar.gz

4. Unpack mariadb-5.5.40.orig.tar.gz, mariadb-5.5.40/ is created

5. Replace upstream mariadb-5.5.40/debian/* with mariadb-5.5-5.5.39/debian/* from Trusty

6. Apply the attached patch mariadb-5.5_5.5.39-0ubuntu0.14.04.1__5.5.40-0ubuntu0.14.04.1.diff on mariadb-5.5.40/debian/

7. Build and ship

I've created test packages that build and pass the test suite. Build logs and installable binaries available at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb

This bug was fixed in the package mariadb-5.5 - 5.5.40-0ubuntu0.14.04.1

---------------
mariadb-5.5 (5.5.40-0ubuntu0.14.04.1) trusty-security; urgency=medium

  * SECURITY UPDATE: Update to 5.5.40 to fix security issues (LP: #1391676)
    - CVE-2014-6507
    - CVE-2014-6491
    - CVE-2014-6500
    - CVE-2014-6469
    - CVE-2014-6555
    - CVE-2014-6559
    - CVE-2014-6494
    - CVE-2014-6496
    - CVE-2014-6464
  * Add bsdutils as mariadb-server dependency like upstream does in 5.5.40.
 -- Otto Kekaelaeinen <email address hidden> Wed, 12 Oct 2014 01:04:24 +0200

Thanks for preparing this update Otto. It should hit the mirrors shortly.

Does utopic need a separate patch?

Will vivid automatically sync with Debian to get the MariaDB 10.0 in there?

Otto, thanks for the head's up, I forgot a step in the update, to check that Utopic already had the 5.5.40 update. My mistake. I'm working on fixing it now so people's Trusty -> Utopic upgrades won't fail.

Vivid should sync from Debian sooner or later, a sync request may speed it up. I'm a little less worried about people upgrading to Vivid, occasional breakage is bound to happen there and those users will know how to adapt.

Thanks

Otto, can you please take a look at the utopic packages? I thought it'd be easy enough to take your trusty patch and fix up utopic in a similar fashion, but my build fails:

...
ERROR HY000: Got error 22 from storage engine
insert into t values (1,repeat('a',16*1024*1024),repeat('b',16*1024*1024-8));

 == /«PKGBUILDDIR»/builddir/mysql-test/var/tmp/analyze-timeout-mysqld.1.err ==
mysqltest: Could not open connection 'default' after 500 attempts: 2002 Can't connect to local MySQL server through socket '/«PKGBUILDDIR»/builddir/mysql-test/var/tmp/mysqld.1.sock' (111)

 - saving '/«PKGBUILDDIR»/builddir/mysql-test/var/log/tokudb.rows-32m-1/' to '/«PKGBUILDDIR»/builddir/mysql-test/var/log/tokudb.rows-32m-1/'
***Warnings generated in error logs during shutdown after running tests: tokudb.rows-32m-1

141113 21:57:56 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:57 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:57 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:57 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:57 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:57 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:57 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:58 [ERROR] TokuDB: The largest value allowed is 33554432 bytes
141113 21:57:58 [ERROR] mysqld got signal 11 ;
Attempting backtrace. You can use the following information to find out

tokudb.savepoint-1078 [ pass ] 420
tokudb.savepoint-1078-2 [ pass ] 395
tokudb.savepoint-1078-3 [ pass ] 394
tokudb.savepoint-1078-4 [ pass ] 413
tokudb.savepoint-2 [ pass ] 122
tokudb.savepoint-3 [ pass ] 147
tokudb.savepoint-4 [ pass ] 60

^CE: ABORT: Received INT signal (requesting cleanup and shutdown)

I'll attach the patch I have against the utopic packaging in the hopes it's useful.

Thanks

Yes, the patch for 5.5.39 in Trusty cannot be applied on 5.5.39 in Utopic, because Utopic 5.5.39 is based on 5.5.39 as it was in Debian recently, while Trusty is based on a older branch of Debian.

I think I'll import the upstream 5.5.40 on Debian 5.5.39 and prepare that result to you so you can release into Utopic.

Here is a diff on what the differences are for 5.5.39 in Trusty and Utopic. Utopic has a never version from Debian which has multiple packaging bug fixed and no new features added. I think if would be safe to but also in Trusty. I wonder what the correct process here is?

It would be nice to have same MariaDB 5.5 line in both Trusty on Utopic. MariaDB is approved for MRE (if it helps here).

Otto, thanks for the diff, but I still wasn't able to get a 5.5.40 build for utopic. The build progressed much further than before, but still died during tests:

http://paste.ubuntu.com/9019560/

The last few lines looked liked:

    tokudb_bugs.rpl_mixed_replace_into
    tokudb_bugs.rpl_row_replace_into
    tokudb_bugs.rpl_stmt_replace_into
408 tests were skipped, 165 by the test itself.

make[5]: *** [mysql-test/CMakeFiles/test-force] Error 1
mysql-test/CMakeFiles/test-force.dir/build.make:49: recipe for target 'mysql-test/CMakeFiles/test-force' failed
make[5]: Leaving directory '/«PKGBUILDDIR»/builddir'
make[4]: *** [mysql-test/CMakeFiles/test-force.dir/all] Error 2
CMakeFiles/Makefile2:9073: recipe for target 'mysql-test/CMakeFiles/test-force.dir/all' failed
make[4]: Leaving directory '/«PKGBUILDDIR»/builddir'
make[3]: *** [mysql-test/CMakeFiles/test-force.dir/rule] Error 2
CMakeFiles/Makefile2:9081: recipe for target 'mysql-test/CMakeFiles/test-force.dir/rule' failed
make[3]: Leaving directory '/«PKGBUILDDIR»/builddir'
make[2]: *** [test-force] Error 2
Makefile:2907: recipe for target 'test-force' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/builddir'
make[1]: *** [override_dh_auto_test] Error 1
debian/rules:138: recipe for target 'override_dh_auto_test' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [build] Error 2
debian/rules:213: recipe for target 'build' failed
dpkg-buildpackage: error: debian/rules build gave error exit status 2

I was surprised to see tokudb tests here, I thought part of the packaging changes was to disable it entirely.

Is there any chance you could provide a diff for the utopic package that would bring it up to 5.5.40? At this point I've learned that mariadb is subtle and I wouldn't necessarily trust a package that I prepare even if it does pass the build tests and our simple smoke tests. I believe my only change after your most recent diff was to change the version number line in the changelog:

mariadb-5.5 (5.5.40-0ubuntu0.14.10.1) utopic-security; urgency=medium

Thanks

Sorry Seth for being unclear and wasting your time trying to patch and build something unusable. The file mariadb-5.5.39-diff-trusty-utopic.diff is a visualization of the differences on 5.5.30 in Trusty and Utopic and not intended to be used as a patch on anything.

I was just thinking on the long-term maintenance, if and how we could unify Trusty to be on same level as Utopic so that each MariaDB 5.5 minor update would not require double work for Ubuntu.

The actual patch for the Utopic upload will be named mariadb-5.5_5.5.39-2__5.5.40-0ubuntu0.14.10.patch and I'll upload it as soon I've tested that is really works.

Rewrite of my commment #12:

mariadb-5.5.39-diff-trusty-utopic.diff shows what the differences are for 5.5.39 in Trusty and 5.5.39 in Utopic.

Utopic has a never version from Debian which has multiple packaging bugs fixed and no new "packaging features" added.

I think the latest and best packaging of MariaDB 5.5 (in Debian and Utopic) would be safe to put also in Trusty. I wonder what the correct process here is? Maybe use trusty-updates or trusty-backports to push a next MariaDB 5.5.xx package there?

It would be nice to have same MariaDB 5.5.xx in both Trusty on Utopic. MariaDB is approved for MRE (if it helps here).

Patch for Utopic attached. Here are the steps to deploy this patch:

1. apt-get source mariadb-server - on Utopic will download and unpack mariadb-5.5_5.5.39-2.debian.tar.xz

2. Download mariadb-5.5.40.tar.gz from https://downloads.mariadb.org/mariadb/5.5.40/#os_group=source and rename it to mariadb-5.5_5.5.40.orig.tar.gz

3. Check that sha256sum matches:
cbde17f4a31483143490def6fcce33310ebae49eafe92dc4ada0e7227202415a mariadb-5.5_5.5.40.orig.tar.gz

4. Unpack mariadb-5.5.40.orig.tar.gz, mariadb-5.5.40/ is created

5. Replace upstream mariadb-5.5.40/debian/* with mariadb-5.5-5.5.39-2/debian/* from Utopic

6. Apply the attached patch mariadb-5.5_5.5.39-2__5.5.40-0ubuntu0.14.10.patch on mariadb-5.5.40/debian/

7. Build and ship

Build logs and installable binaries available at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb
(see 5.5.40-0ubuntu0.14.10~utopic1~ppa2)

Otto, thank you so much for preparing new packages for utopic. I built them successfully locally, so I'm uploading to the build servers now. The only thing I changed is the version, to 5.5.40-0ubuntu0.14.10.1, to match the version 5.5.40-0ubuntu0.14.04.1 from trusty. (Note the .1 at the end.)

I believe the next security update would be an ideal time to unify the packaging of mariadb-5.5 for trusty, utopic, and vivid if appropriate. Since every mariadb release is going to fix security bugs, it doesn't necessarily make sense to release a newer version into -updates, and it feels a little bit like busy-work to me to perform the package unification in -updates using the 5.5.40 just so we can re-import it for a future 5.5.41 release in -security.

If you'd rather perform the unification soon, because you're thinking about it and ready, you certainly can do it through -updates. But waiting for 5.5.41 makes sense to me.

Thanks!