Ubuntu has issued an advisory on April 25: http://www.ubuntu.com/usn/usn-1807-2/ The other CVEs were here: http://lwn.net/Vulnerabilities/548167/ Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA2TOO
Whiteboard: MGA2TOO => MGA3TOO, MGA2TOO
Fixed for Cauldron in mariadb-5.5.31-1.mga4.
Version: Cauldron => 3Whiteboard: MGA3TOO, MGA2TOO => MGA2TOO
*** Bug 10820 has been marked as a duplicate of this bug. ***
CC: (none) => oe
Mandriva has issued an advisory for this today (July 23): http://www.mandriva.com/en/support/security/advisories/mes5/MDVSA-2013:197/ They listed three additional CVEs: http://lwn.net/Vulnerabilities/560391/
Ubuntu has issued an advisory on July 25: http://www.ubuntu.com/usn/usn-1909-1/ This updates to MySQL 5.5.32, fixing some new CVEs, which are here: http://lwn.net/Vulnerabilities/561009/
Summary: mariadb new possible security issues fixed in mysql 5.5.31 => mariadb new possible security issues fixed in mysql 5.5.31 and 5.5.32
SuSE has issued an advisory today (August 30): http://lists.opensuse.org/opensuse-security-announce/2013-08/msg00022.html This updates to MySQL 5.5.32 and adds yet some more CVEs: http://lwn.net/Vulnerabilities/565373/
SuSE has issued an advisory on October 7: http://lists.opensuse.org/opensuse-security-announce/2013-10/msg00001.html This updates to MySQL 5.5.33 and adds yet some more CVEs. No LWN link yet.
Summary: mariadb new possible security issues fixed in mysql 5.5.31 and 5.5.32 => mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, and 5.5.33
Mandriva has issued an advisory today (October 17): http://www.mandriva.com/en/support/security/advisories/mes5/MDVSA-2013:250/ This adds a couple more CVEs: http://lwn.net/Vulnerabilities/570678/
Ubuntu has issued an advisory on October 24: http://www.ubuntu.com/usn/usn-2006-1/ This adds a couple more CVEs: http://lwn.net/Vulnerabilities/571747/ Also, as they're listed by Ubuntu as Medium severity (as opposed to Low), we really should try to fix these, as we've done before.
Summary: mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, and 5.5.33 => mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, 5.5.33, and 5.5.34
maybe i should just update mga2 to 5.5.34, like i did with mga3... when is the deadline?
Summary: mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, 5.5.33, and 5.5.34 => mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, 5.5.33
We haven't done anything with Mageia 3 yet, so yes, updating them (as well as Cauldron) to 5.5.34 would be good. We have a few weeks left for Mageia 2 updates.
Summary: mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, 5.5.33 => mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, 5.5.33, and 5.5.34
yes, we did..., i distinctly remember testing that out...
I'm afraid you're mistaken. We have not issue any updates for mariadb for Mageia 3. There's a 5.5.33a in updates_testing that Oden built IIRC, but was never sent to QA.
oops, i guess i forgot to file a bug for that one
(In reply to AL13N from comment #10) > maybe i should just update mga2 to 5.5.34, like i did with mga3... > > when is the deadline? From http://www.mageia.org/en/support/ ... Mageia 2 will be supported until November 22nd, 2013. Note that it has to be assigned to qa in time to be tested before pushing.
CC: (none) => davidwhodgins
Depends on: (none) => 11543
mariadb 5.5.34 upstream is officially released: https://blog.mariadb.org/mariadb-5-5-34-now-available/
*** Bug 11543 has been marked as a duplicate of this bug. ***
Depends on: 11543 => (none)CC: (none) => alien
Removing Mageia 2 from the whiteboard due to EOL. http://blog.mageia.org/en/2013/11/21/farewell-mageia-2/
Whiteboard: MGA2TOO => (none)
Mandriva has updated MBS to mariadb 5.5.34: http://www.mandriva.com/en/support/security/advisories/mbs1/MDVA-2014:001/
More security issues which look to impact 5.5.34 as well: http://lwn.net/Vulnerabilities/581305/ http://www.debian.org/security/2014/dsa-2845
(In reply to David Walser from comment #20) > More security issues which look to impact 5.5.34 as well: > http://lwn.net/Vulnerabilities/581305/ > http://www.debian.org/security/2014/dsa-2845 The issues are fixed in MySQL 5.5.35, so I assume there will be a MariaDB 5.5.35 following it to fix these as well. We'll need to update this for Mageia 4 as well.
Summary: mariadb new possible security issues fixed in mysql 5.5.31, 5.5.32, 5.5.33, and 5.5.34 => mariadb new possible security issues fixed in mysql 5.5.31 through 5.5.35
Ubuntu has issued an advisory for this today (January 21): http://www.ubuntu.com/usn/usn-2086-1/ This adds a couple more CVEs: http://lwn.net/Vulnerabilities/581565/
*** Bug 12500 has been marked as a duplicate of this bug. ***
mariadb-5.5.35-1.mga3 + mariadb-5.5.35-1.mga4 has been submitted. Fixes CVE-2014-0001 and according to oracle CVE-2014-0412, CVE-2014-0437, CVE-2013-5908, CVE-2014-0420, CVE-2014-0393, CVE-2013-5891, CVE-2014-0386, CVE-2014-0401, CVE-2014-0402 as of: http://www.oracle.com/technetwork/topics/security/cpujan2014-1972949.html
Thanks Oden! Since we're so many releases behind on Mageia 3, I think trying to find all of the CVEs is a lost cause, so I'll just go with a generic advisory on this one. Will admins have to run mysql_upgrade after installing this, as was the case with a version jump update we did in the past (possibly mysql on Mageia 1)? If so, we should add a note about that to the advisory. Well, I guess I'll assume so an add it. If this is incorrect, please let me know. Advisory: ======================== Updated mariadb packages fix security vulnerabilities: MariaDB has been updated to the latest release in the 5.5 series, 5.5.35, which fixes several security vulnerabilities and other bugs. See the Release Notes for more details. Note: if upgrading the main mariadb package, you should run the "mysql_upgrade" command (as root) after installing the updated package. References: https://mariadb.com/kb/en/release-notes-mariadb-55-series/ ======================== Updated packages in core/updates_testing: ======================== mariadb-5.5.35-1.mga3 mysql-MariaDB-5.5.35-1.mga3 mariadb-feedback-5.5.35-1.mga3 mariadb-extra-5.5.35-1.mga3 mariadb-obsolete-5.5.35-1.mga3 mariadb-core-5.5.35-1.mga3 mariadb-common-core-5.5.35-1.mga3 mariadb-common-5.5.35-1.mga3 mariadb-client-5.5.35-1.mga3 mariadb-bench-5.5.35-1.mga3 libmariadb18-5.5.35-1.mga3 libmariadb-devel-5.5.35-1.mga3 libmariadb-embedded18-5.5.35-1.mga3 libmariadb-embedded-devel-5.5.35-1.mga3 mariadb-5.5.35-1.mga4 mysql-MariaDB-5.5.35-1.mga4 mariadb-feedback-5.5.35-1.mga4 mariadb-extra-5.5.35-1.mga4 mariadb-obsolete-5.5.35-1.mga4 mariadb-core-5.5.35-1.mga4 mariadb-common-core-5.5.35-1.mga4 mariadb-common-5.5.35-1.mga4 mariadb-client-5.5.35-1.mga4 mariadb-bench-5.5.35-1.mga4 libmariadb18-5.5.35-1.mga4 libmariadb-devel-5.5.35-1.mga4 libmariadb-embedded18-5.5.35-1.mga4 libmariadb-embedded-devel-5.5.35-1.mga4 from SRPMS: mariadb-5.5.35-1.mga3.src.rpm mariadb-5.5.35-1.mga4.src.rpm
Version: 3 => 4Assignee: alien => qa-bugsWhiteboard: (none) => MGA3TOO
(In reply to David Walser from comment #25) > Will admins have to run mysql_upgrade after installing this, as was the case > with a version jump update we did in the past (possibly mysql on Mageia 1)? > If so, we should add a note about that to the advisory. Well, I guess I'll > assume so an add it. If this is incorrect, please let me know. If it's the case, a README.update.urpmi too, so that it is shown to the admin who performs a CLI update of his system.
CC: (none) => stormi
There was one broken test that will be fixed with 5.5.36. Here's the fix: http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/4062 so, just do this for the broken test: export LANG=C export LC_ALL=C export LANGUAGE=C pushd /usr/share/mysql/mysql-test wget "http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/4062" patch -p1 < 4062 perl ./mysql-test-run.pl \ --mtr-build-thread="$((${RANDOM} % 100))" \ --retry=0 \ --ssl \ --big-test \ --force \ --max-test-fail=0 \ --testcase-timeout=60 \ --suite-timeout=1200 rpl.rpl_ddl popd Thanks to elenst in the #mariadb channel at freenode for the help.
I've upgraded my MGA4-64 laptop which runs a farily complex mariadb setup (using custom UDFs and Geolocation stuff). Did general testing which exercised those parts and couldn't find any obvious regressions. I also upgraded my server at home which is on MGA3-64. It also uses mariadb in various web apps but not quite as stressful on db features as above. Did more general testing and again, all seems well.
CC: (none) => mageiaWhiteboard: MGA3TOO => MGA3TOO mga3-64-ok mga4-64-ok
Thanks Colin. There's a testsuite too that can be used in addition to manual testing. cd /usr/share/mysql/mysql-test && ./mysql-test-run.pl
Thanks! That test suite doesn't run without a bit of a manual fixup here: [root@jimmy mysql-test]# mkdir /usr/sql [root@jimmy mysql-test]# ln -s ../bin/mysql_tzinfo_to_sql /usr/sql Even then it seems somewhat flakey and doesn't run too well for me.
it's not flakey at all... look at the --with test section... every release i build "--with test" to check if all is working... for me, these tests take about 10h... and if they fail, i check with upstream. they are resource-intensive though, often if they fail, it's a timeout due to swapping on my end...
Created attachment 4992 [details] Test output. (In reply to AL13N from comment #31) > it's not flakey at all... ... > they are resource-intensive though, often if they fail, it's a timeout due > to swapping on my end... "if they fail" and "timeout": this is what I meant by "flakey". For me running the script above failed initially due to not finding /usr/sql/mysql_txinfo_to_sql (so some hard-coded (incorrect) path somewhere). After doing a hacky fix for that, when running the actual test I got a timeout after about 30s waiting for a process to start. Because I had the initial error with the path, I didn't look into it too much as this was a fairly fundamental problem that prevented running the tests and I didn't trust myself that my hacky symlink was enough to create a "working test environment" that it expects. Perhaps something else on my system (my my.cnf?) is messing with the tests. Who knows but this very much feels more of a problem with the test suite than a problem with the software! If you can offer any guidance, it would be appreciated, but my ACK still stands on the update generally - this feels like a different problem to me.
i don't get this timezone issue on my mga3 system, did you execute the .pl file from the /usr/share/mysql/mysql-test directory? (or the /usr dir?) and did you use the language "C" environment variables?
also, if there are some that fail, it's like 2 or 3 tests and after retesting they are fine... you just need enough resources...
coling found a bug (only mga4), so i'm submitting mariadb-5.5.35-2.mga4.
Whiteboard: MGA3TOO mga3-64-ok mga4-64-ok => MGA3TOO mga3-64-ok
(In reply to AL13N from comment #35) > coling found a bug (only mga4), so i'm submitting mariadb-5.5.35-2.mga4. Is it anything you'd like to add a note about to the advisory?
no, the advisory can stay, in theory, it only affects new users... it seems that if you removed your datadir or had a new one, there were issues due to the prepare-dir not being started as root, but as mysql user.
(In reply to Samuel VERSCHELDE from comment #26) > (In reply to David Walser from comment #25) > > Will admins have to run mysql_upgrade after installing this, as was the case > > with a version jump update we did in the past (possibly mysql on Mageia 1)? > > If so, we should add a note about that to the advisory. Well, I guess I'll > > assume so an add it. If this is incorrect, please let me know. > > If it's the case, a README.update.urpmi too, so that it is shown to the > admin who performs a CLI update of his system. This is important to know/do so setting feedback marker until it's known.
Whiteboard: MGA3TOO mga3-64-ok => MGA3TOO feedback mga3-64-ok
Actually it's already documented in README.urpmi, just as it was for mysql in Mageia 1. We went through an upgrade with that package that was just like this.
Whiteboard: MGA3TOO feedback mga3-64-ok => MGA3TOO mga3-64-ok
just a heads up... looks like 5.5.36 might be out very soon (tomorrow)
Do you want to wait for it AL13N?
well, at this point, only one of 4 tests is ok... if i was overloaded QA, i'd probably consider this lower priority if someone tells me there's a high chance that a new (security) release is coming tomorrow... but ultimately, QA decides imho... (it's pretty odd though that a new security fix is coming so soon though...)
No idea what the next update is for AL13N. You're the maintainer. If you intend to package it then we'll wait but if you if you don't we wont.
@Alien It seems to be a maintenance release (unless they are hiding some security issue): 5.5.36 has the following hhanges so far: https://mariadb.com/kb/en/mariadb-5536-changelog/ as for waiting for new versions all the time... by that logic you could wait for the next Oracle cpus 15 April 2014 15 July 2014 14 October 2014 and after that we dont need to relases anything for mga3 either.... or if we just wait for the next cpu, we can release it at the 1-year anniversary since the initial report was opened :/
CC: (none) => tmb
I don't get it. What are you waiting for?
Since some of the CVEs have at least moderate severity (as I mentioned before), we really should get this update out.
Severity: normal => major
well, if it's a security bugfix release or a security bugfix release... it matters a little, but not much... couple that with Oracle which has no disclosure, they could very well be hiding some security bugs in there... I'm planning on packaging it... this should give us a bit time before the next update...
(In reply to David Walser from comment #39) > Actually it's already documented in README.urpmi, just as it was for mysql > in Mageia 1. We went through an upgrade with that package that was just > like this. Regarding to need to manually run mysql_upgrade after installing the update. This is not shown when installing the update. (mga3 64)
Adding 'feedback' for now.
This bug was opened 2013-04-26 for mga2 and is still *not fixed*. The mga2 product reached end of life and never got fixed(!). The bug was then transferred to the mga3 product that has not received a single security update(!). Hello?, is it only me who find this a little bit disturbing?
Indeed, we really need to do better with this. Hopefully we will in the future. As for the feedback marker, as I said, we didn't hold up the mysql update for this reason, the documentation is there, the README.urpmi file is there. I don't know why it's not being displayed.
Oden, I hope that rhetoric is not aimed at me. As you can see QA has had very little time with this. If you're looking for somebody to 'rubber stamp' it then I'll pass and allow somebody else to do so.
(In reply to David Walser from comment #51) > the README.urpmi file is there. > I don't know why it's not being displayed. Aren't README.urpmi for installs only and README.update(s?).urpmi for updates?
(In reply to claire robinson from comment #52) > Oden, I hope that rhetoric is not aimed at me. As you can see QA has had > very little time with this. If you're looking for somebody to 'rubber stamp' > it then I'll pass and allow somebody else to do so. Not aimed at anyone particular. I just summarized the facts. Who to blame? I don't care.
mariadb-5.5.36-1.mga3 and mariadb-5.5.36-1.mga4 has been submitted.
mariadb-5.5.36-1.mga3 didn't build. Anyway, we'll need fresh testing on that once it is built, and of course change 5.5.35 to 5.5.36 in the advisory. As far as Oden's comment, I don't believe he was aiming it at the QA team either. For this update to happen, first it has to get packaged, and AL13N, the maintainer, has not packaged an update for this, except for one time to fix a bug in one of the updates Oden built. It'd really help if the burden for packaging security updates didn't have to fall on the two-person security team for every single package, including ones that have active maintainers. As for QA's role here, yes we know the QA team hasn't had much time with this update yet, so no problem there. We just don't want to see the update held with the feedback tag when we've (as packagers) already responded to it. We all saw the note about the documentation, and I agree that we shouldn't release it if the mysql_upgrade issue isn't documented. However, it is documented, and neither AL13N or Oden have decided to take any further action on that, so I hope we can move forward from there. I'm guessing Oden's concerned about how these delayed updates (for whatever reason) looks in the security community (hint: it's not a good look for us). Fortunately, from tracking updates for several distros for a couple years now, I can definitively say that on average, we do as well as anyone (and have as good, or better QA, than anyone). Unfortunately, we always have a few updates that are horrendously delayed, for one reason or another, and it's usually inactive and/or non-responsive maintainers. I'm not sure what can be done about it though.
Whiteboard: MGA3TOO mga3-64-ok => MGA3TOO
Forgot Sergei also fixed MDEV-5580 (hence why the patch didn't apply for mga3)
5.5.36 build uploaded for Mageia 3 and Mageia 4. Thanks Oden. Advisory: ======================== Updated mariadb packages fix security vulnerabilities: MariaDB has been updated to the latest release in the 5.5 series, 5.5.36, which fixes several security vulnerabilities and other bugs. See the Release Notes for more details. Note: if upgrading the main mariadb package, you should run the "mysql_upgrade" command (as root) after installing the updated package. References: https://mariadb.com/kb/en/release-notes-mariadb-55-series/ ======================== Updated packages in core/updates_testing: ======================== mariadb-5.5.36-1.mga3 mysql-MariaDB-5.5.36-1.mga3 mariadb-feedback-5.5.36-1.mga3 mariadb-extra-5.5.36-1.mga3 mariadb-obsolete-5.5.36-1.mga3 mariadb-core-5.5.36-1.mga3 mariadb-common-core-5.5.36-1.mga3 mariadb-common-5.5.36-1.mga3 mariadb-client-5.5.36-1.mga3 mariadb-bench-5.5.36-1.mga3 libmariadb18-5.5.36-1.mga3 libmariadb-devel-5.5.36-1.mga3 libmariadb-embedded18-5.5.36-1.mga3 libmariadb-embedded-devel-5.5.36-1.mga3 mariadb-5.5.36-1.mga4 mysql-MariaDB-5.5.36-1.mga4 mariadb-feedback-5.5.36-1.mga4 mariadb-extra-5.5.36-1.mga4 mariadb-obsolete-5.5.36-1.mga4 mariadb-core-5.5.36-1.mga4 mariadb-common-core-5.5.36-1.mga4 mariadb-common-5.5.36-1.mga4 mariadb-client-5.5.36-1.mga4 mariadb-bench-5.5.36-1.mga4 libmariadb18-5.5.36-1.mga4 libmariadb-devel-5.5.36-1.mga4 libmariadb-embedded18-5.5.36-1.mga4 libmariadb-embedded-devel-5.5.36-1.mga4 from SRPMS: mariadb-5.5.36-1.mga3.src.rpm mariadb-5.5.36-1.mga4.src.rpm
(In reply to Samuel VERSCHELDE from comment #53) > (In reply to David Walser from comment #51) > > the README.urpmi file is there. > > I don't know why it's not being displayed. > > Aren't README.urpmi for installs only and README.update(s?).urpmi for > updates? No, README.urpmi is supposed to always be displayed, and the README.xxx.urpmi ones are special cases. See: https://wiki.mageia.org/en/Packagers_RPM_tutorial#Interaction_with_urpmi_and_rpmdrake
i'm getting confused... why do people think that mysql_upgrade is needed? normally, this isn't really required, (in some cases, it could be), though it's harmless to do so... otoh, what's keeping us from running mysql_upgrade after the update, automatically? or running it pre-start or something?
On new installs one could do: mysqld --version | awk '{ print $3}' > /var/lib/mysql/mysql_upgrade_info cat /var/lib/mysql/mysql_upgrade_info 5.5.35-MariaDB Or run mysql_upgrade which will add the /var/lib/mysql/mysql_upgrade_info file if not there. echo 5.5.34-MariaDB > /var/lib/mysql/mysql_upgrade_info mysql_upgrade [...] mysql_upgrade This installation of MySQL is already upgraded to 5.5.35-MariaDB, use --force if you still need to run mysql_upgrade Years ago I added this in the mariadb-5.5-initscript.patch for reasons I cannot remember, sorry.
My vague recollection is that mysql_upgrade is sometimes needed when updating MySQL versions, but can't be automated by the package because sometimes it needs a password to be given interactively.
Upgraded a mga3 and a brand new mga4 server that hosts wordpress, moodle and joomla databases and everything is still working as it should
Whiteboard: MGA3TOO => MGA3TOO mga3-64-ok mga4-64-ok
(In reply to David Walser from comment #62) > My vague recollection is that mysql_upgrade is sometimes needed when > updating MySQL versions, but can't be automated by the package because > sometimes it needs a password to be given interactively. "because sometimes it needs a password" ?? any sane db admin always lock root account with atleast a password (and also lock it to localhost or a specific management station)
(In reply to Thomas Backlund from comment #64) > (In reply to David Walser from comment #62) > > My vague recollection is that mysql_upgrade is sometimes needed when > > updating MySQL versions, but can't be automated by the package because > > sometimes it needs a password to be given interactively. > > > "because sometimes it needs a password" ?? > > any sane db admin always lock root account with atleast a password > (and also lock it to localhost or a specific management station) Well, if it's not listening on a network port and there's no interactive users on the machine, it's not so important to lock it with a password, but at least you've confirmed the reason we don't run mysql_upgrade automatically :o)
actually, we could autoconfigure the auth_pam module (like postgres does) and do mysql_upgrade on bootup without any issue...
(In reply to AL13N from comment #66) > actually, we could autoconfigure the auth_pam module (like postgres does) > and do mysql_upgrade on bootup without any issue... I hope you mean package upgrade and not bootup.
Packages installed and working fine on my production wiki (mediawiki) server at work (Mageia 3 i586).
errr, i meant application start , like in the execpre systemd unit
(In reply to AL13N from comment #69) > errr, i meant application start , like in the execpre systemd unit Well, as long as it ran on the "restart" that's triggered when the package is updated, that's fine. Running it on every single service start is overkill.
if there's nothing to do, it doesn't actually take that long... but sure, we can detect if version is changed and only run it then, if you like... but perhaps this shouldn't be for mga4 or older, but for cauldron...
Adding mga3 32 ok from David's testing.
Whiteboard: MGA3TOO mga3-64-ok mga4-64-ok => MGA3TOO mga3-32-ok mga3-64-ok mga4-64-ok
(In reply to AL13N from comment #71) > if there's nothing to do, it doesn't actually take that long... Yeah, even installing this update on mga3 it didn't take long to run it. > but perhaps this shouldn't be for mga4 or older, but for cauldron... At least initially, absolutely.
Tested upgrades of MariaDB, Drupal and MediaWiki from MGA 4 32-bit core/updates to core/updates_testing. The upgrade went smoothly enough and the web apps (and the sample database) continued to work. Marking as mga4-32-ok . Regards, -- Shlomif
CC: (none) => shlomifWhiteboard: MGA3TOO mga3-32-ok mga3-64-ok mga4-64-ok => MGA3TOO mga3-32-ok mga3-64-ok mga4-64-ok mga4-32-ok
Advisory uploaded. Validating. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO mga3-32-ok mga3-64-ok mga4-64-ok mga4-32-ok => MGA3TOO advisory mga3-32-ok mga3-64-ok mga4-64-ok mga4-32-okCC: (none) => sysadmin-bugs
Update finally pushed: http://advisories.mageia.org/MGASA-2014-0108.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
LWN reference for our update: http://lwn.net/Vulnerabilities/589094/