Robie Basak: > Hi Niels, > > Thank you for your considered response. > > On Tue, Jan 26, 2016 at 11:50:08PM +0000, Niels Thykier wrote: >> I do not feel the listed options accurately reflect the issues / >> concerns in play. As *I see it*, these are the options: >> >> 1) Default to MySQL with MariaDB also available /!\ >> >> 2) Default to MariaDB with MySQL also available >> >> 3) Only MySQL available, MariaDB removed from testing /!\ >> >> 4) Only MariaDB available, MySQL removed from testing. >> >> 5) Further discussion / delayed decision > > I'm fine with a decision that chooses from one of these instead. One > question though. What does "default" mean? Right now there is no > default. If you ask for mysql-server you get that, and likewise for > mariadb-server. Maintainers of dependent packages choose which one they > prefer (something like Depends: mysql-server-5.6 | > virtual-mysql-server). So if the release team were to decide to change > the "default", what would that mean technically, and what requirements > would be placed on dependent package maintainers? > * No package may (unconditionally) require the presence of the non-default option * No package may pull the "non-default" choice in the absence of an active choice from the user to install the non-default choice. Anyway, this is possibly "too short", but it should give the general direction. >> The options marked with /!\ are de facto *no-go* for me if/given the >> security team is unwilling to provide security support for MySQL[2]. > > I agree, but I'm focusing on the "if/given" part of your statement here. > I appreciate that you pointed it out explicitly. I see a couple of > issues here: > > 1) I was pleased to hear from the Debian security team that we may be > able to make some progress on the security disclosure issue soon. If > this happens and the matter gets resolved, then presumably your /!\ > options will no longer be a no-go? > If the security team was to publish it, Oracle was to implement and the security was to accept Oracle's implementation in due time... However, I personally find this very unlikely given: * The security team has (in my eyes) basically veto'ed on security support on MySQL. * Oracle has a very unfortunate track record in this area. * There will be a phase after the Oracle implemented their revised policy, where the security team will want to evaluate it. - In practise, it will probably take a couple of iterations to get right. > 2) My understanding of the situation, given Otto's recent enquiries > about CVEs, is that the underlying problem will not go away for Debian > if MySQL is removed from testing, since MariaDB will still be affected. > So the security team would presumably have to publish the same caveat > for MariaDB in the release notes. Therefore by your logic MariaDB would > have to be *no-go* as well. Clearly we can't drop both, so I think we > will better serve Debian by taking the opportunity we have to resolve > the situation by getting Oracle to give Debian what it needs, for the > sake of both MySQL and MariaDB. > It is unfortunate that Oracle's policy will cause issues for security patches for MariaDB as well. However: * I do *not* see a "veto" against security support on MariaDB. * I *do* see one against MySQL, which made for my *no-go* mark. > So I ask that you stick with the status quo for now. If however the > security disclosure is not resolved after giving Oracle a reasonable > opportunity, then I will have no reason to object further. > Unfortunately, we have tried this for several months now and basically we have not progressed on this issue. While 5) *is* an option, I am not convinced the situation will change for the better. >> * This is a transition I want early rather than rushed earlier. >> - It can trivially end up taking 6 months of calender time before it >> is complete. This is uncomfortably close to the transition >> deadline > > I fully appreciate the difficulty in timing we have here. From the dates > in my summary I hope you can understand why I feel that this matter has > been blocked on you, and not the maintainers, for quite a few months > now. So it doesn't seem right that MySQL gets dropped or disadvantaged > because of this. > > Thanks, > > Robie > I appreciate that the release team failed on action item several months back and have not been very proactive in the communication. And I am sorry that it has (and probably will) inconvenience you and MySQL upstream. Thanks, ~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature