The changelog for 5.0.88 (http://dev.mysql.com/doc/refman/5.0/en/news-5-0-88.html) does not mention the fix, but in the bugreports, it says:
"[4 Nov 10:16] Bugs System
Pushed into 5.0.88 (revid:firstname.lastname@example.org) (version source
revid:email@example.com) (merge vers: 5.0.88) (pib:13)"
Also, quoted from http://secunia.com/advisories/37372/:
1) An error exists within the "vio_verify_callback()" function in MySQL clients that are linked against OpenSSL libraries. This can potentially be exploited to conduct MitM (Man-in-the-Middle) attacks e.g. via a MySQL server using a certificate with a depth of zero.
2) An error is caused due to missing error handling for "SELECT" statements containing sub-queries in the "WHERE" clause, which can be exploited to cause a server to crash.
3) The "GeomFromWKB()" function fails to preserve an argument's null-value flag when handling geometry values as the first argument. This can be exploited to cause a server to crash.
mysqld in MySQL 5.0.x before 5.0.88 and 5.1.x before 5.1.41 does not
(1) properly handle errors during execution of certain SELECT
statements with subqueries, and does not (2) preserve certain
null_value flags during execution of statements that use the
GeomFromWKB function, which allows remote authenticated users to
cause a denial of service (daemon crash) via a crafted statement.
The vio_verify_callback function in viosslfactories.c in MySQL 5.0.x
before 5.0.88 and 5.1.x before 5.1.41, when OpenSSL is used, accepts
a value of zero for the depth of X.509 certificates, which allows
man-in-the-middle attackers to spoof arbitrary SSL-based MySQL
servers via a crafted certificate, as demonstrated by a certificate
presented by a server linked against the yaSSL library.
sql/sql_table.cc in MySQL 5.0.x through 5.0.88, 5.1.x through 5.1.41,
and 6.0 before 6.0.9-alpha, when the data home directory contains a
symlink to a different filesystem, allows remote authenticated users
to bypass intended access restrictions by calling CREATE TABLE with a
(1) DATA DIRECTORY or (2) INDEX DIRECTORY argument referring to a
subdirectory that requires following this symlink.
Fixed 5.1 and 5.0 ebuilds in the tree now.
(In reply to comment #4)
> Fixed 5.1 and 5.0 ebuilds in the tree now.
I assume 5.0.90-r1 is the target for stabilization?
.90 or .90-r1, hoping to see if any users report issues with it first.
The testsuite passes, but that hasn't be the only thing before.
stabilization is happening on bug 303747
All security-supported arches have done the stabilization from bug #303747, should we make the decision about GLSA?
GLSA together with the other mysql stuff.
This issue was resolved and addressed in
GLSA 201201-02 at http://security.gentoo.org/glsa/glsa-201201-02.xml
by GLSA coordinator Tim Sammut (underling).