On Fri, Apr 13, 2012 at 12:12, AL13N <al...@rmail.be> wrote:
> 1. find all the responsible patches and add them manually
> ==> this is my preferred option, but seems not doable, and apparently
> no-one steps in and mysql isn't maintained (officially)

Not possible as most of the unfixed CVE on MySQL only say things like:

  Unspecified vulnerability in the MySQL Server component in Oracle MySQL
  5.5.x allows remote authenticated users to affect confidentiality and
  integrity via unknown vectors.

So there is no way to know what was fixed and when.

> 2. do like other distros and fix to higher mysql 5.5.22 which fixes this
> issue
> ==> this is totally not preferred for me;
>  A) a big change between mysql 5.5.10 and mysql 5.5.22, which means huge QA 
> load

This will happen anyway. Testing will be the same whatever the amount
of changes is.

>  B) this also means that the mga1 -> mga2 upgrade will have to be
> extensively retested

At least there will be no package name change etc, so nothing really
new regarding upgrade

> 3. go to the cauldron version that fixes these issues which is mariadb-5.5.23
> ==> this is less preferred for me:
>  A) a big change between mysql 5.5.10 and mysql 5.5.22, which means huge
> QA load

And even more, as it implies testing that all packages from mga1 using
mysql need to be tested (as more recent ones were tested in cauldron)

>  B) however the mga1 -> mga2 upgrade has been tested already, so the
> chance of serious issues arising for this is alot less than normallY.

But it will need to be tested completely again as now mga1 state would
be very different from what it was

>  C) since mariadb-5.5.23 is based on mysql-5.5.23, the changes are quite
> less than would normally be.
>
> 4. don't fix this security issue
> ==> this is also less preferred for me, for obvious reasons.
>
> 5. someone has a better idea?

Reply via email to