RedHat has issued this advisory on February 13: https://rhn.redhat.com/errata/RHSA-2012-0127.html The CVEs not listed in the bug summary do not affect the 5.5.x series. It is not clear if the ones in the bug summary were fixed by 5.5.10.
Here's another RedHat advisory from February 8 with CVEs that may be relevant: https://rhn.redhat.com/errata/RHSA-2012-0105.html
CC: (none) => alien
The ChangeLog for the newest MySQL 5.5.x makes a vague reference to some security bugs being fixed. Maybe we should just update to it (Mandriva periodically does this). It looks like Ubuntu is preparing to do just that. http://dev.mysql.com/doc/refman/5.5/en/news-5-5-22.html https://bugs.launchpad.net/ubuntu/+source/mysql-5.1/+bug/965523
even though i want stableness, and security fixes... we honestly don't have a mysql maintainer, and the security patching is completely unclear (even mariadb complains about that) otoh, if we update mysql, then the upgrade to mariadb in mageia 2 will not be successfull. if we just update to the newer version (between 5.5.10 and 5.5.22 is alot of functionality change)... that's not good either. otoh, i do plan on backporting mariadb to mga1, but that doesn't solve security issues... and mariadb does have even more features of course...
Despite the changes in functionality, apparently just upgrading to the newest version works. Also, it seems as you say, it's impossible to get clear info from Oracle or find patches, so Mandriva has updated to 5.5.22 for MDV 2011, and RedHat has done the same for F15 and F16. It seems to be the way to go. Probably the easiest thing since there's no maintainer is to basically just sync it with the MDV 2011 update package, modulo any MDV'isms. Hopefully then, whatever needs to be done to make the upgrade to mariadb in mga2 still work can be done. I'd rather not just ignore this for security. WDYT?
well, i cannot be sure that the upgrade to mageia 2 works, if you update with a different version, it's just all untested. and personally, i'd rather drop mysql as obsolete, because both are starting to go separate ways (rather oracle is putting in more and more odd stuff) i for one would say that it's easier to just leave it alone in mageia 1. let's see it from my pov: suppose you have a server running mysql 5.5.10 if the updates are simple patches to security bugs, i would do them, but if they are anything more... there's just too much that can go wrong with your data. as a result, i will not update them. just jumping from 5.5.10 to 5.5.22 is too risky imho. i'd prefer data validity rather than security at this pov. perhaps we could do a release update that give a README.urpmi warning that the security if this is unsuported and that it'd be better to upgrade to a backported mysql or mariadb. so, adding a warning is what i'd want to do in this case... warning the user that it's not maintained anymore or has not all security patches. unless someone can take the time to get every security patch in 5.5.10...
(In reply to comment #5) > well, i cannot be sure that the upgrade to mageia 2 works, if you update with a > different version, it's just all untested. and personally, i'd rather drop > mysql as obsolete, because both are starting to go separate ways (rather oracle > is putting in more and more odd stuff) I wish Oracle wouldn't make so many functionality changes to a stable branch :o( So, what you're saying is MariaDB will only import a MySQL database up to a certain version? So if we update it in Mageia 1, upgrades to Mageia 2 won't work? > i for one would say that it's easier to just leave it alone in mageia 1. :o( > let's see it from my pov: Which is interesting to hear, as you probably know more about it than anyone in Mageia. > suppose you have a server running mysql 5.5.10 > > if the updates are simple patches to security bugs, i would do them, but if > they are anything more... there's just too much that can go wrong with your > data. as a result, i will not update them. It doesn't look like anyone knows what the patches are. > just jumping from 5.5.10 to 5.5.22 is too risky imho. i'd prefer data validity > rather than security at this pov. Well I certainly don't want data problems, as I have a production Moodle server using MySQL running on Mageia 1 at work. However, since Fedora and Mandriva have updated it, I'm not all that worried. > perhaps we could do a release update that give a README.urpmi warning that the > security if this is unsuported and that it'd be better to upgrade to a > backported mysql or mariadb. > > so, adding a warning is what i'd want to do in this case... warning the user > that it's not maintained anymore or has not all security patches. I guess this is a pretty unique problem we're dealing with. We want to update the package for security, but upstream isn't much help. It sounds like you'd be less worried switching people to MariaDB than MySQL 5.5.22. Maybe we could do some more extensive testing of this and just do it?
(In reply to comment #6) > However, since Fedora and Mandriva have updated it, I'm not all that worried. Well, do they have to migrate to MariaDB with their next version? :) > I guess this is a pretty unique problem we're dealing with. We want to update > the package for security, but upstream isn't much help. It sounds like you'd > be less worried switching people to MariaDB than MySQL 5.5.22. Maybe we could > do some more extensive testing of this and just do it? We can't just migrate users on stable release. How serious are those bugs in MySQL? Any that bad security holes that you can attack from remote computer?
CC: (none) => sander.lepik
(In reply to comment #7) > (In reply to comment #6) > > However, since Fedora and Mandriva have updated it, I'm not all that worried. > > Well, do they have to migrate to MariaDB with their next version? :) That's a different concern. > > I guess this is a pretty unique problem we're dealing with. We want to update > > the package for security, but upstream isn't much help. It sounds like you'd > > be less worried switching people to MariaDB than MySQL 5.5.22. Maybe we could > > do some more extensive testing of this and just do it? > > We can't just migrate users on stable release. How serious are those bugs in > MySQL? Any that bad security holes that you can attack from remote computer? Well what's the solution then? As far as how serious, from the two RedHat advisories, there's one that allows remote attackers to affect availability. The rest allow remote authenticated users to affect availability, confidentiality, and integrity.
how many of them require network access? which is in most cases disabled...
(In reply to comment #9) > how many of them require network access? which is in most cases disabled... I don't know.
anyway, i'm not saying it's not supported to migrate from those versions, and mariadb are the original developers, so they analysed the bunch of merges to find the security bugs. (i hate how certain people just migrate a bunch without any clarity whatsoever, just to have more obscurity (which is just lousy security)). but well, when i packaged mariadb, eg, i filed some bugs to mariadb to get fixed, but i didn't bother to send to mysql. so i assume it's possible they don't have those fixes. if you look at it like that: if we want security fixes, and we let people migrate from 5.5.10 to 5.5.22, we might as well migrate them to 5.5.23 on mariadb. this is why it might be better for someone to find the commits for the important security bugs and leave the rest. also, it should be noted and checked for each sec fix if it's actually effective on 5.5.10... it could very well only be valid for later versions. also David: have you ever taken a backup dump and on a new VM imported it and upgraded the database to see if everything still works? that would be interesting. i would say: (but i'm not mysql maintainer) check each CVE to see if it's valid, and if it is, if it's only on networked mysqls or other non-standard behavior, and see how bad it really is.
(In reply to comment #11) > anyway, i'm not saying it's not supported to migrate from those versions, and > mariadb are the original developers, so they analysed the bunch of merges to > find the security bugs. (i hate how certain people just migrate a bunch without > any clarity whatsoever, just to have more obscurity (which is just lousy > security)). Indeed. > but well, when i packaged mariadb, eg, i filed some bugs to mariadb to get > fixed, but i didn't bother to send to mysql. so i assume it's possible they > don't have those fixes. > > if you look at it like that: if we want security fixes, and we let people > migrate from 5.5.10 to 5.5.22, we might as well migrate them to 5.5.23 on > mariadb. Agreed. > this is why it might be better for someone to find the commits for the > important security bugs and leave the rest. also, it should be noted and > checked for each sec fix if it's actually effective on 5.5.10... it could very > well only be valid for later versions. This is probably not possible. > also David: have you ever taken a backup dump and on a new VM imported it and > upgraded the database to see if everything still works? that would be > interesting. I certainly could. Our Moodle server itself is a VM, and we've already done similar testing (cloned the VM to test a Moodle upgrade) recently. > i would say: (but i'm not mysql maintainer) check each CVE to see if it's > valid, and if it is, if it's only on networked mysqls or other non-standard > behavior, and see how bad it really is. I don't think the information needed to do this is out there. CVEs certainly don't have it.
well, the way i see it there are 5 options: 1) do nothing 2) someone spend huge amount of time gathering security commits and testing each and every CVE. 3) ask for update exception and migrate to mysql 5.5.22 (even thought we'll obsolete mysql anyway) 4) ask for update exception and migrate to mariadb 5.5.23 (which is already tested for upgrades) 5) put in a README.urpmi that it's unsecure. NOTE: i was planning on backporting mariadb for mga1 anyway (so if we update to mysql 5.5.22, this might have issues) plus the migration path of mysql 5.5.10 is tested to mariadb 5.5.23 (final release should be on Monday) given that i'm backporting it anyway, my order of preference is: 5 > 4 > 1 > 3 > 2 considering there is no maintainer, and if we can't agree here on what to do (perhaps we need a few more people to agree on an approach), we'll have to put this in a topic on next packagers meeting...
(In reply to comment #13) > well, the way i see it there are 5 options: > > 1) do nothing > 2) someone spend huge amount of time gathering security commits and testing > each and every CVE. > 3) ask for update exception and migrate to mysql 5.5.22 (even thought we'll > obsolete mysql anyway) > 4) ask for update exception and migrate to mariadb 5.5.23 (which is already > tested for upgrades) > 5) put in a README.urpmi that it's unsecure. > > NOTE: i was planning on backporting mariadb for mga1 anyway (so if we update to > mysql 5.5.22, this might have issues) > > plus the migration path of mysql 5.5.10 is tested to mariadb 5.5.23 (final > release should be on Monday) > > given that i'm backporting it anyway, my order of preference is: 5 > 4 > 1 > 3 > > 2 > > considering there is no maintainer, and if we can't agree here on what to do > (perhaps we need a few more people to agree on an approach), we'll have to put > this in a topic on next packagers meeting... Or bring it up on the -dev list, so that more than 4 people will see it :o) My 2 cents is that 5 and 1 are not a solution, and 4 sounds good to me. If we go with 4, doing it after the mga2 release would be fine, and it would increase coverage for testing the migration.
actually, after talking with mariadb people and some others, i'm proposing to have mariadb-5.5.23 in mga1. however, QA should extra-double-test the php-mysql dependency, as mariadb noted that php-mysql seems to have a very strict versioning scheme sometimes and having a new mysql provider without rebuilding php-mysql often fails...
(In reply to comment #15) > actually, after talking with mariadb people and some others, i'm proposing to > have mariadb-5.5.23 in mga1. > > however, QA should extra-double-test the php-mysql dependency, as mariadb noted > that php-mysql seems to have a very strict versioning scheme sometimes and > having a new mysql provider without rebuilding php-mysql often fails... what does the QA think about that ?
CC: (none) => qa-bugs
It's too much work for QA, as tmb already said on dev ml. I don't think it's a good idea. Too many things to test. And we probably can't test them all. As even KDE is using mysql then we have too many affected users to try this on a stable release.
no offense meant, but the mga1 to mga2 upgrade needs testing anyway, which is for mariadb exactly this point. also, if this security fix is to be fixed by going to mysql-5.5.22, that would need extensive testing as well. and that would also give extra load on QA, since the mga1 -> mga2 upgrade will need to be retested.
Is it possible that Debian or Red Hat has patches for those CVEs. I'm quite sure they don't upgrade versions.
i can be wrong, since i didn't doublecheck, but iinm someone on IRC told me that other distros just update to mysql 5.5.22
QA, since a thread was opened on the -dev ml, better go here for discuss.
CC: qa-bugs => (none)
CC: (none) => boklm
This is really a packaging decision. From a QA perspective it makes no difference as long as it works, allows upgrade from mdv2010.2 to mga1 and in a few weeks also mga1 to mga2. Mga1 will be supported for another 9 months so it should be sustainable. Anything which requires rebuilding should be determined and rebuilt as part of the update, that too is a packagers decision though. These are things which should be decided and actioned before involving QA. Leaving mga1 with security holes is not really acceptable, given that it won't be abandoned until mga3 is released.
I agree either a Mysql update or switch to Mariadb is required. Makes very little difference to me, which is chosen. Either will require extensive testing of all affected packages.
CC: (none) => davidwhodgins
mysql-5.5.23-1.mga1 is now available for testing. I will try to check if something else needs rebuild this weekend... I will add the advisory later (as for some testing data: I already have upgraded 2 live LAMP servers running moodle, joomla, mrbs, and some other sql stuff and it seems to work so far)
CC: (none) => tmbAssignee: bugsquad => qa-bugsSource RPM: mysql-5.5.10-8.mga1.src.rpm => mysql-5.5.23-1.mga1
thanks alot, by any chance did you have any time to try out the migration to mga2 yet? since it's the same version and the conflicts are on mysql <= 5.5.10, it likely will not work. should i update the conflict version and bump mariadb?
Nope. no upgrade test yet. The version is technically ok as .mga1 < .mga2, but the conflicts need to updated, so please go ahead and do that.
I installed the test update on an x86_64 mga1, amarok and akonadi work fine so far, no error log for mysql. I have no other program using mysql on this computer.
CC: (none) => r.h.michel+mageia
(In reply to comment #26) > Nope. no upgrade test yet. > > The version is technically ok as .mga1 < .mga2, but the conflicts need to > updated, so please go ahead and do that. it seems funda took care of it, he really is an impatient person...
Installed here on my home machine. All seems well so far. /me loves Funda the updates ninja! :)
for once...
unnecessary comment...
CC: (none) => ennael1
# service mysqld start WARNING: mysql_upgrade should be run (as root). The upgrade from mysql-5.5.10 to mysql-5.5.23 may require it If I run mysql_upgrade, as root, it fails. What is the proper method for upgrading, and can it be automated in the installation of the update?
Found it. # mysql_upgrade -u root -p âsocket=/var/lib/mysql/mysql.sock -v I think the README.urpmi file should specify that the above needs to be run, while the service is running.
(In reply to comment #33) > Found it. > > # mysql_upgrade -u root -p âsocket=/var/lib/mysql/mysql.sock -v > > I think the README.urpmi file should specify that the above needs > to be run, while the service is running. If it is needed for it to continue working, it should do it for you.
(In reply to comment #34) > (In reply to comment #33) > > Found it. > > > > # mysql_upgrade -u root -p âsocket=/var/lib/mysql/mysql.sock -v > > > > I think the README.urpmi file should specify that the above needs > > to be run, while the service is running. > > If it is needed for it to continue working, it should do it for you. I don't think it can, since the password must be entered.
hmm, i think you might be correct...
(In reply to comment #33) > Found it. > > # mysql_upgrade -u root -p âsocket=/var/lib/mysql/mysql.sock -v > Sorry for not mentioning it, but it's enough to do: mysql_upgrade -p (as it README.urpmi already states it must be run as root)
x86_64 After mysql_upgrade -p (and remembering the password) it started Ok. Tested with various webapps, no issues. Also.. # mysqlshow -p # mysqladmin -p version status proc Also installed mysql-bench # cd /usr/share/mysql/sql-bench/ # perl run-all-tests --server=mysql --user=root --password=pass --small-test Running without --small-test takes a looong time to complete. Everything tests Ok.
This is ready to validate, could somebody provide an advisory please. Thanks.
I don't know that a detailed advisory can be written for this one, as Oracle doesn't release much information and other distros don't seem to have any details either. Thomas Backlund said he'd write the advisory, and he pushes the updates, so you might as well just validate it and he can handle it then. I'll provide a suggested advisory that he can use as a basis. Suggested Advisory: ======================== Updated mysql packages fix security vulnerabilities: Several security vulnerabilities which can affect confidentiality, integrity, and availability were fixed. One of these vulnerabilities is remotely exploitable without authentication (CVE-2011-2262). The others are not (CVE-2012-0113, CVE-2012-0116, CVE-2012-0118, CVE-2012-0496, CVE-2012-0115, CVE-2012-0119, CVE-2012-0120, CVE-2012-0484, CVE-2012-0485, CVE-2012-0486, CVE-2012-0487, CVE-2012-0488, CVE-2012-0489, CVE-2012-0490, CVE-2012-0491, CVE-2012-0495, CVE-2012-0112, CVE-2012-0117, CVE-2012-0114, CVE-2012-0492, CVE-2012-0493, CVE-2012-0075, CVE-2012-0494). Several other bugs were fixed as well. References (security): http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2262 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0113 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0116 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0118 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0496 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0115 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0119 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0120 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0484 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0485 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0486 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0487 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0488 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0489 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0490 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0491 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0495 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0112 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0117 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0114 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0492 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0493 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0075 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0494 http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-23.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-22.html References (other bugs): http://dev.mysql.com/doc/refman/5.5/en/news-5-5-21.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-20.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-19.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-18.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-17.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-16.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-15.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-14.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-13.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-12.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-11.html ======================== Updated packages in core/updates_testing: ======================== libmysql-devel-5.5.23-1.mga1 libmysql18-5.5.23-1.mga1 libmysqld-devel-5.5.23-1.mga1 libmysqld0-5.5.23-1.mga1 libmysqlservices-5.5.23-1.mga1 mysql-5.5.23-1.mga1 mysql-bench-5.5.23-1.mga1 mysql-client-5.5.23-1.mga1 mysql-common-5.5.23-1.mga1 mysql-common-core-5.5.23-1.mga1 mysql-core-5.5.23-1.mga1 from mysql-5.5.23-1.mga1.src.rpm
Whoops, found some more CVEs. Updating the advisory...
Suggested Advisory: ======================== Updated mysql packages fix security vulnerabilities: Several security vulnerabilities which can affect confidentiality, integrity, and availability were fixed. One of these vulnerabilities is remotely exploitable without authentication (CVE-2011-2262). The others are not (CVE-2012-0113, CVE-2012-0116, CVE-2012-0118, CVE-2012-0496, CVE-2012-0115, CVE-2012-0119, CVE-2012-0120, CVE-2012-0484, CVE-2012-0485, CVE-2012-0486, CVE-2012-0487, CVE-2012-0488, CVE-2012-0489, CVE-2012-0490, CVE-2012-0491, CVE-2012-0495, CVE-2012-0112, CVE-2012-0117, CVE-2012-0114, CVE-2012-0492, CVE-2012-0493, CVE-2012-0075, CVE-2012-0494, CVE-2012-1703, CVE-2012-0583, CVE-2012-1697, CVE-2012-1688, CVE-2012-1696, CVE-2012-1690). Several other bugs were fixed as well. References (security): http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2262 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0113 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0116 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0118 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0496 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0115 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0119 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0120 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0484 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0485 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0486 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0487 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0488 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0489 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0490 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0491 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0495 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0112 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0117 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0114 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0492 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0493 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0075 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0494 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1703 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0583 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1697 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1688 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1696 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1690 http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html http://www.oracle.com/technetwork/topics/security/cpuapr2012-366314.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-23.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-22.html References (other bugs): http://dev.mysql.com/doc/refman/5.5/en/news-5-5-21.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-20.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-19.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-18.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-17.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-16.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-15.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-14.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-13.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-12.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-11.html ======================== Updated packages in core/updates_testing: ======================== libmysql-devel-5.5.23-1.mga1 libmysql18-5.5.23-1.mga1 libmysqld-devel-5.5.23-1.mga1 libmysqld0-5.5.23-1.mga1 libmysqlservices-5.5.23-1.mga1 mysql-5.5.23-1.mga1 mysql-bench-5.5.23-1.mga1 mysql-client-5.5.23-1.mga1 mysql-common-5.5.23-1.mga1 mysql-common-core-5.5.23-1.mga1 mysql-core-5.5.23-1.mga1 from mysql-5.5.23-1.mga1.src.rpm
Thanks David. Validating. Suggested advisory & srpm in comment 42 Could sysadmin please push from core/updates_testing to core/updates Thanks!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Hardware: i586 => All
Update pushed. Thanks for the advisory David.
Status: NEW => RESOLVEDResolution: (none) => FIXED
CC: boklm => (none)