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