[debian-mysql] Request for release team decision on MySQL and MariaDB [was: Re: Bug#793316: Bug#793316: transition: mysql-5.6]

[Norvald H. Ryeng]

On Thu, 14 Jan 2016 22:11:22 +0100, Moritz Mühlenhoff <jmm at inutil.org>  
wrote:

> On Mon, Jan 11, 2016 at 08:14:06PM +0000, Robie Basak wrote:
>> On Mon, Jan 11, 2016 at 07:27:30PM +0100, Moritz Mühlenhoff wrote:
>> > *Sigh*. And that is exactly the problem (and we've already pointed  
>> this
>> > out at DebConf half a year ago)
>> >
>> > We should really go ahead and move forward, the freeze isn't terribly  
>> far away.
>>
>> I don't think it's reasonable to use a security question raised by
>> MariaDB as an excuse to kick out MySQL. Because whether you do so or
>> not, your situation with getting information about CVEs in relation to
>> MariaDB will not change.
>>
>> Let's treat the situation with each on their own merits and be
>> constructive about this.
>
> This policy equally hurts us for mysql alone. Debian LTS had go through
> a messy 5.1-5.5 transition because of Oracle's policies.
>
>> That *is* something that might be able to be addressed directly by
>> Oracle, and if it does get addressed then MariaDB's situation could
>> improve too, and Debian wins.
>
> We've already raised this at DebConf with Norvald from Oracle half a year
> ago and nothing happened. Several other parties didn't get these infos
> from Oracle in the past (not even Red Hat). The VirtualBox developers
> were equally shut down by Oracle (after being cooperative for a while).

As a MySQL developer, I don't know anything about the VirtualBox
situation, so let's focus on MySQL.

Yes, there was a meeting at DebConf. I discovered the session in the
schedule and showed up wanting to meet the security team and talk
about some specific MySQL security issues. Apparently, it was planned
to be an internal security team meeting without other attendants, so
it was kind of an awkward start when I and a couple of other random
attendants showed up, but we used the opportunity to talk about a few
specific security issues that required larger code changes than the
usual security bugfix and if Debian would accept those changes in a
stable release.

I don't remember if it was me or the security team who raised the
issue of not being able to identify patches for CVEs, but if anything,
please take the fact that we sought out and showed up at the security
team meeting as a sign that we really want to resolve issues with our
security bug handling.

IIRC, when I asked at the meeting, I was told that identifying
individual patches is less important since MySQL is patched by
upgrading to the latest point release (and we document which CVEs are
fixed in which point release) instead of backporting security
bugfixes, and that the reason for wanting more details was primarily
to be able to test if MariaDB had the same vulnerabilities.

 From that discussion, I got the understanding that the security team,
although not very happy about the situation, accepted that they're not
able to identify patches, and that taking point releases was an
acceptable alternative.

What you're saying now, is that publicly announcing which point
release fixes which CVE is not enough, and that a public announcement
of which CVE is which patch is a strict requirement to be in
Debian. Is that correct? In that case, this is the first time I'm made
aware of it. Is all software in Debian held to this standard?

If a public announcement linking CVEs and patches is an absolute
requirement, is this the only requirement? If so, please give me some
time to check if that is acceptable within policy or if a policy
exception can be granted. But I can't go back and ask for more if a
new requirement suddenly pops up, so I'll need the complete list of
requirements first. The Debian MySQL team has asked for a list, in
writing, several times now, but that list has not been produced.

Regards,

Norvald