Changes in release 4.1.13 (15 Jul 2005) Functionality added or changed: Security improvement: Applied a patch that addresses a zlib data vulnerability that could result in a buffer overflow and code execution. (CAN-2005-2096) (Bug #11844)
Mysql please advise.
mysql-4.1.13-r1.ebuild mysql-5.0.9_beta-r2.ebuild now depend upon >=sys-libs/zlib-1.2.2-r1 (after CVS propagate itself) these two ebuild force mysql to link agains external zlib. ^ this mean all the people that has emerged after "06 Jul 2005" are using a safe zlib (also with version of mysql prior 4.1.13). To be on the safe side I've bumped to force upgrade of zlib. Speaking of 4.0.x from here --------------------------- MySQL Bugs: #11844 [11 Jul 19:37] Jim Winstead This only impacts MySQL 4.1 and later, as 4.0 (and earlier) includes an earlier version of zlib that is reportedly not vulnerable. --------------------------- ^ I suppose this is not valid if the binaryes are linked against system version of zlib. The 4.0.x ebuild don't force linking to external libraryes, so the linkage depend upon configure.in choices. I'm not in the position to check this and not untill monday aftenoon. Please hear robbat2 or find an installed mysql-4.0 and run ldd on it. FYI mysql-4.0.25 has been tested only on systems with "sys-libs/zlib-1.2.2-r1" here so they work for sure with that on. The other side of the coin is that that sources are out only from 15 Jul 2005 . I'm reachable for about one hour.
even mysql-4.0.24-r2 links against the external zlib by default for us (at least on my test box), so I don't see any problem for us. foo ~ # ldd `which mysql` |grep libz libz.so.1 => /lib/libz.so.1 (0xb7f2d000)
(In reply to comment #2) > mysql-4.1.13-r1.ebuild > mysql-5.0.9_beta-r2.ebuild > now depend upon >=sys-libs/zlib-1.2.2-r1 (after CVS propagate itself) > > these two ebuild force mysql to link agains external zlib. Hmm.. assuming that >=sys-libs/zlib-1.2.3 is considered the most safe at the moment, according to http://www.gentoo.org/security/en/glsa/glsa-200507-19.xml - shouldn't mysql-4.1.13 and mysql-5.0.9_beta depend on >=sys-libs/zlib-1.2.3 to be on the safest side?
Might have been a good idea to leave the mysql-5.0.9_beta-r1.emerge, it kind of wrinkles people to find that the package.unmask =dev-db/mysql-5.0.9_beta-r1 has now been downgraded to mysql-4.0.25. Ooh the file corruption.
to comment #4 true, you need sys-libs/zlib-1.2.3 , if you have an older version upgrade now. My bad. You just need to upgrade zlib not mysql btw and glsa cover zlib. This said, I'm keeping time to test mysql on new zlib, to not do a doble mistake. to comment #5 that's not so bad. That force people to look at what's happened. Being this a security update (and 4.1 , 5.0 still package masked) I've chosen to remove the old one. Hope this has not wasted too much user time, it's precious. If so, my apologies to all.
(In reply to comment #3) > even mysql-4.0.24-r2 links against the external zlib by default for us (at > least on my test box), so I don't see any problem for us. > > foo ~ # ldd `which mysql` |grep libz > libz.so.1 => /lib/libz.so.1 (0xb7f2d000) > If mysql ships with its own zlib, it's better to rm -rf it in src_unpack, so it can't even be used by accident. At least that's how I handle such issues to be on the safe side in case some stupid configure script falls back to internal libs.
According to vivo we always link against system zlib -> Closing as INVALID.
