USN-2170-1: MySQL vulnerabilities also applies to MariaDB

[Otto Kekäläinen]

The security notice http://www.ubuntu.com/usn/usn-2170-1/ also applies for package mariadb-5.5 in Trusty universe. The fix is included in 5.5.37 and was just released for Debian Sid and has also landed into Ubuntu Utopic proposed: https://launchpad.net/ubuntu/+source/mariadb-5.5/5.5.37-1

The same package should also be synced to trusty. I do not have Ubuntu upload permissions. Either the security team should take care of this or I need a sponsor to help me out with the process.

The package mariadb-5.5 version 5.5.37 builds without errors for trusty i386 and amd64, and the test suite passes error free. Testable binaries, build logs and test suite logs are available at https://launchpad.net/~mysql-ubuntu/+archive/mariadb.

[Dimitri John Ledkov (xnox)]

A fake-sync from utopic-release pocket into trusty-security might be appropriate - similar to DSA fakesyncs.

[Dimitri John Ledkov (xnox)]

Well my comment above is not correct, given the intentions of ongoing security updates and/or eventual MRE.

<mdeslaur> in this case, he needs to get a couple of updates sponsored by the security team, and then can apply for a MRE
<mdeslaur> so he needs to file a bug, propose some updated packages that only touch the tarball, etc.
<mdeslaur> if that goes well for a couple of releases, he can get an MRE and then do non-security updates too

Additional guidance on preparing a debdiff for security team sponsorship is at https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation

[Otto Kekäläinen (otto)]

I now branched https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/mariadb-5.5/trusty and pushed at https://code.launchpad.net/~otto/maria/5.5.37-0ubuntu0.14.04.1 and built in my own PPA using recipe at https://code.launchpad.net/~otto/+recipe/mariadb-5.5-security-update.

Build was OK and all 3014 build tests were successful.

I will do some more testing of the binaries from Launchpad and compate them to the binaries I build myself from the branch https://github.com/ottok/mariadb-5.5/tree/5.5.37-0ubuntu0.14.04.1

If I've managed to use Launchpad to correctly build this, then I think this should be ready for a merge request. This process is new to me so please help/comment if you spot issues.

[Seth Arnold (seth-arnold)]

Hello Otto, thanks for taking on this work.

The Launchpad branches may be a convenient mechanism for managing
packaging in the devel branch but it is not an ideal fit for security
updates. I suspect that you can make it work, but working with the raw
packaging pieces alone may be easier.

When we update MySQL, the process usually looks like this:

1) Download the MySQL sources for all releases that are going to be
updated. (We use 'umt download mysql-5.5', where 'umt' is an unpackaged
tool that helps standardize the updates process; apt-get source should
also work, but it won't automatically download versions from all supported
releases.)

2) Download the new MySQL tarball from Oracle and check signatures.

3) Rename the tarball to *.orig.tar.gz

4) Edit debian/changelog to indicate a new upstream release, CVEs closed,
reference a launchpad tracking bug to make it easy to see which releases
get the updated packages, and give each release a version-specific number
to ensure upgrades go smoothly.

5) quilt push -a -- note failures, determine if patches need to be dropped
because they were integrated upstream or just need to be refreshed.

6) quilt pop -a -- this cleans up the .pc/ directory and the sources and
makes diffs far more legible.

7) Build and test

I assume the process for MariaDB will be largely identical.

Of course, sponsored updates will require more work to capture the
changes made to the packaging. Normally we ask for a "debdiff" between the
old and the new package, which is efficient for reviewing and applying
when the changes are small. This process doesn't work well for wholesale
updates of huge software suites -- no one wants to read a diff of a
compressed tarball -- so the process is slightly different.

You'll go through these same steps, but we'll need a patch that we can
apply to the unpacked sources to update the fuzz in the patches we keep
and drop the patches we no longer need. We can download the new tarball
ourselves but please include the sha256sum of the tarball you used to
ensure we're working from the same page. (Best would be to convince the
MariaDB developers to sign their packages.)

Probably using cp -a to make a complete copy of the unpacked source tree
would be the best way to make a patch for the debian/ directory changes.
It would be worthwhile to review this patch by hand to ensure it is
minimal and correct; we'll check it for .pc files, editor detritus, etc.,
but the fewer issues we find the faster we can get updates to our users.

Thanks again Otto, please don't hesitate to ask questions.

[Otto Kekäläinen (otto)]

I now used the process outlined by Seth above to produce yet another Ubuntu security backport of 5.5.37. Instead of attaching the 21 MB debdiff file, I have now attached a diff that only has the debian/* contents.

Steps for you to apply this patch:
- apt-get source mariadb-server - on Trusty will download and unpack 5.5.36-1
- download ftp://ftp.osuosl.org/pub/mariadb/mariadb-5.5.37/source/mariadb-5.5.37.tar.gz, rename it to .orig.tar.gz and check that the sha256sum matches a0faf492b3595d938684ed701812a4bd5aaab395b8402efe3322338a80fb3c9c
- unpack mariadb-5.5_5.5.37.orig.tar.gz as a new upstream directory
- unpack mariadb-5.5_5.5.36-1.debian.tar.xz and use contents to replace the new upstream debian/*

At this point you should have the equivalent of a pure orig.tar.gz upgrade. Then continue with
- review attached patch mariadb-5.5_5.5.36-1_5.5.37-0ubuntu0.14.04.1-debian-dirs.diff
- use attached patch to patch debian/*
- apply patches from debian/patches/* with 'quilt push -a'
- build and ship

Please notify me where you build the final packages and where the build log are viewable, so that I can check them just to make sure everything went OK.

If you want to test the trusty amd64 binaries directly, add these lines to your sources.list:
deb http://labs.seravo.fi/~otto/mariadb-repo/ 5.5.37-0ubuntu0.14.04.1/
deb-src http://labs.seravo.fi/~otto/mariadb-repo/ 5.5.37-0ubuntu0.14.04.1/

The complete debdiff and other files are available for download from the file listing at http://labs.seravo.fi/~otto/mariadb-repo/5.5.37-0ubuntu0.14.04.1/

Regarding upstream signatures - I just filed https://mariadb.atlassian.net/browse/MDEV-6205 where I request them to publish .asc files next to their tar.gz source releases.

I hope this fulfills all your requirements so that you can land this security update. Please let me know if you need something more.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "mariadb-5.5_5.5.36-1_5.5.37-0ubuntu0.14.04.1-debian-dirs.diff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Seth Arnold (seth-arnold)]

Otto, thanks for this work. Thanks for filing the bug upstream to ask for signed tarballs and thanks for providing this update in near-perfect form.

Our 'umt check' sanity checking tool complained about some missing patch tags:

Patch tagging:
 44_scripts__mysql_config__libs.diff:
   FAIL: neither 'Description' or 'Subject' tagged in patch
   FAIL: Neither 'Origin', 'Author', or 'From' tagged in patch
   WARNING: found old-style '# ' prefix. For 'quilt', don't use '#'.
   (see http://dep.debian.net/deps/dep3/ for details)
 99_remove_rename_mariadb-server_files_in.diff:
   FAIL: neither 'Description' or 'Subject' tagged in patch
   FAIL: Neither 'Origin', 'Author', or 'From' tagged in patch
   WARNING: found old-style '# ' prefix. For 'quilt', don't use '#'.
   (see http://dep.debian.net/deps/dep3/ for details)

Of course this update didn't itself introduce these problems but it would be nice to have them fixed in the future to reduce the number of warnings. See http://dep.debian.net/deps/dep3/ for some information on the DEP-3 patch tagging guidelines.

The locally-built package with your update finished building successfully, and it has even passed many of the tests in our mysql test script that I over-zealously ran sed -i -e 's/mysql/maria/g' on -- the original is here, in case you're curious: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-mysql.py (I had to revert many of the changes and I don't think I've gotten the script quite right yet.) We don't need this script fully functional to release this update but it would be nice to have external smoketests to ensure future updates aren't completely broken.

If the rest of the sanity checks look fine when they finish (waiting on the 'old' package to build locally) then we'll be ready to release this update to users on Monday.

Thanks again.

[Otto Kekäläinen (otto)]

Added additional patch that makes the same change as in https://github.com/ottok/mariadb-5.5/commit/d0ba739a0 to reformat diff headers as requested.

[Launchpad Janitor (janitor)]

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

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

  * SECURITY UPDATE: Update to 5.5.37 to fix security issues (LP: #1313187)
    - http://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html
    - CVE-2014-0001
    - CVE-2014-0384
    - CVE-2014-2419
    - CVE-2014-2430
    - CVE-2014-2431
    - CVE-2014-2432
    - CVE-2014-2436
    - CVE-2014-2438
    - CVE-2014-2440
 -- Otto Kekaelaeinen <email address hidden> Mon, 28 Apr 2014 09:55:22 +0300

[Seth Arnold (seth-arnold)]

Thanks Otto -- I'm sorry I didn't make clear that I didn't need the patch header fixes for this update. Thanks for fixing them for the future, though, it'll be one fewer automated nag to ignore.

Thanks!