Issues reported by Javier Fernandez-Sanguino Pena and Debian Security Audit Team.
This is CAN-2005-0004 and can be considered semi-public. Robin: please apply fix to 4.0.23 and bump in portage ?
Public now @ http://secunia.com/advisories/13867/
Created attachment 48789 [details, diff] patch for mysql-4.1.8 modified from http://lists.mysql.com/internals/20600 sligtly modified the patch reported in the url given. It should apply cleanly on mysql-4.1.8 tree
Patch for mysql-4.1.8 also applys cleanly to mysql-4.1.9 (bug #78452).
*** Bug 78558 has been marked as a duplicate of this bug. ***
Robin/Jasmin please provide a patch for 4.0.22 or we'll have to mark 4.1 stable to fix this.
The patch here applies cleanly to the 4.0. 4.1 is package.masked still, for several reasons. It _will_ break the tree (needing massive revdep-rebuild, and many packages don't build against it yet).
Robin/Solar if the patch is fine please apply it.
I think there's a slight typo in the attached patch, where we have two $ on the $MYSQL_CNF assignment. Applied to 4.0.23-r1 and 4.1.8-r1.
Thx rac, but please don't close security bugs as we also handle stable marking. Arches please test and mark stable 4.0.23-r1.
stable on x86
I vote for a GLSA since mysqlaccess is an admin tool in PATH.
I vote for a GLSA on this one too.
stable on ppc64
stable on sparc.
STOP! http://bugs.gentoo.org/show_bug.cgi?id=78678
I don't think the patch from 4.0.23 to 4.0.23-r1 broke it, it must be something between 4.0.22 and 4.0.23 itself. Back to ebuild status, uncalling arches and setting 78678 as blocker
crap there is another bug in 4.0.23 as well. http://bugs.mysql.com/bug.php?id=7515 It's broken in 4.0.23 and 4.1.8, so I've put 4.0.23 back as ~arch for all values of arch. I'll see about backporting CAN-2005-0004 to 4.0.22.
Ok, lets try this again. mysql-4.0.22-r2 is in the tree as ~arch, and contains the security fix.
Thx Robin for backporting. Arches please test and mark mysql-4.0.22-r2 stable
stable on ppc64.. once more. .. I should have noticed this ..
4.0.22-r2 stable on sparc.
stable on x86 too... this bug looks pretty bad for our testing... (myself included..). Could we do something to improve our QA on this sort of thing?
4.0.22-r2 stable on alpha.
tester: The libtool glitch didn't show up as I strongly suspect most devs are using the new libtool where it's bypassed.
Created attachment 49070 [details] 4.1.9 ebuild patches ewarn really sorry for the typo signaled in #9 by Robert Coie the patch signaled in #18 From Robin Johnson for mysql 4.0 reside at http://mysql.bkbits.net:8080/mysql-4.0/patch@1.2014 and is shorter than 100 rows the one for mysql 4.1 include fix for MySQL Bugs: #7297: "Date decoding trouble" but I was unable to apply to 4.1.8. It was already applied ??? so the motive to write this message has been dropped, to not trash (hoping not to trash your ;) completely my time I've modified the 4.1.8-r1 ebuild to build 4.1.9. changes are : 1) Added documentation for upgrade, and removed corrispondent TODO, you have already experienced my english so please read and correct errors if there are. Moved wait time out from warning() and modified wait time 2) modified again mysqld_safe patch, IMHO you can valutate to remove this patch, the checks it do always fall into the chosen behaviour, it move often, and is executed at startup only. 3) thrssl patch is not needed anymore, commented it compiled with all useflag on but "debug" and "ruby" included files: # tar -ztf my-stuff-4.1.9.tar.gz mysql-4.1.9.ebuild 4.1.8-r1_4.1.9.patch files/digest-mysql-4.1.9 files/mysql-4.1.9-mysqld-safe-sh.diff and a final note: mysql generally compile with -O3 optimization using -Os should be evaluated at least on amd64 and x86, the executabe is 10% smaller and I bet the cache hit increase more than that 10%, but this is argument for another thread.
4.0.22-r2 stable on ppc.
amd64 done
GLSA 200501-33 ia64/arm/hppa/s390/mips, please mark stable to benefit from GLSA.
mips stable.
MySQL AB today released version 4.1.10 that fix this bug too
Already stable on hppa
