[debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

Mon Jan 25 23:00:29 UTC 2016

Robie, thank you for taking the time to summarize so thoroughly. I have a
conflict, so I probably won't make the meeting, but I'm confident things
are in good hands.

Excerpts from Robie Basak's message of 2016-01-25 14:14:01 -0800:
> In this summary I make no new arguments. I only summarise what has
> already been said and provide references to back up what has already
> been said. References are in the form [YYYY-MM-DD] or [YYYY-MM-DD-X]
> where disambiguation is needed. URLs are at the bottom.
> 
> Where I have not used quotes, I am paraphrasing for brevity. Where I
> state "no response", rather than lack of any response on any topic from
> the team mentioned, I mean that there has not been a reply to the
> particular point I am summarising.
> 
> I will send a separate email about what I propose we do next. In this
> email, I'm sticking to the historical record of facts already raised so
> that we can all refer to it.
> 
> Since there are many different hats involved in the discussion and they
> are all quite wordy to disambiguate, I use the following abbreviations:
> 
> MySQL: MySQL(TM), Oracle's product
> MariaDB: MariaDB(TM), MariaDB Corporation's product that is derived from
>     MySQL
> R: Debian (R)elease team
> S: Debian (S)ecurity team
> M: Debian MySQL (M)aintainers team, when speaking unanimously for both
>     MySQL and MariaDB packaging (both are packaged within the same
>     team)
> M[MySQL]: Debian MySQL (M)aintainers team, the subset backing MySQL
> M[MariaDB]: Debian MySQL (M)aintainers team, the subset backing MariaDB
> U[MySQL]: (U)pstream for MySQL
> 
> As you know, some of the same people wear more than one of the hats
> above. In this summary I attribute the hat, not the person.
> 
> 
> * Background
> 
> M want to maintain both MySQL and MariaDB in testing and to release in
> stretch. R and S expected M to remove one or the other, but every time
> it came up [2014-10-01-A][2015-07-23-A], M immediately confirmed that it
> intends to continue maintaining both
> [2014-10-01-B][2015-07-23-B][2015-07-23-C]. Since the default position
> is for all packages in unstable to migrate to testing, M assumed that
> the status quo would remain unless R sought to change it. R has known
> about the situation since [2014-10-01-B] but took no action.
> 
> However M eventually felt that the threat of removal was blocking
> progress [2015-07-23-A][2015-09-08], so M asked R for a clear decision
> on whether stretch will ship both MySQL and MariaDB or just one, and if
> the latter then to decide on which one [2015-09-14].
> 
> These are the points of contention that have been identified by R and S,
> which leads them to favour dropping MySQL:
> 
> 1. "mysql isn't maintained in jessie"
> 2. "no disclosure of security issues w/ patches"
> 3. "we have two forks of the same codebase"
> 4. "point releases can contain anything"
> 
> When pushed by M[MySQL] [2015-12-16], neither R nor S have been able to
> identify any other issues apart from the ones on this list. Nor have R
> or S identified any new issues since that meeting having had time to
> reflect.
> 
> In my opinion, there is a common theme here. Since the second IRC
> meeting [2015-09-23], R and S repeatedly refuse to expand on some of
> these problems so that M[MySQL] might fix them. Instead they
> continuously tell us that this has been discussed before and that they
> won't enter into it again [2015-12-16][2016-01-11-A][2016-01-14]. But
> M[MySQL] are unaware of R or S ever having expanded on these issues.
> Every time R and S claim reference to previous discussions, M[MySQL]
> asks for references so that they can read up on these claimed previous
> discussions, but neither R nor S have never been able to provide any.
> Despite M[MySQL] pointing this out [2016-01-15-A], R and S still refuse
> to expand on these problems [2016-01-14].
> 
> Next I'll summarise discussion separately on each of these four points
> of contention.
> 
> * 1. "mysql isn't maintained in jessie"
> 
> R: [2015-09-23] Please maintain MySQL better in jessie and squeeze.
> M[MySQL]: OK.
> R: [2015-12-16] "mysql isn't maintained in jessie"
> M[MySQL]: [2016-01-07] Yes it is; we have been diligent since you asked
>     us in [2015-09-23] [evidence provided].
> R: [no response since 2016-01-07]
> S: No it's not; we did it because you didn't copy in the bug.
> M[MySQL]: [2016-01-11-B] But there has only been one update since you
>     first brought this up. In that update we did notify the bug
>     [evidence provided], but you missed that and uploaded anyway. So
>     we are being diligent, even if you did trump us.
> S: [no response since 2016-01-11]
> 
> Following this exchange, I think S and M[MySQL] are working well
> together in the handling of the subsequent security announcements (5.5
> and 5.6) [2016-01-18-A][2016-01-18-B].
> 
> Thus I consider this issue resolved, unless R or S say otherwise and
> can explain why.
> 
> * 2. "no disclosure of security issues w/ patches"
> 
> R: [2015-09-16-A] States that a significant reason to ship only one
>     variant comes from S.
> M[MySQL] and U[MySQL]: [2015-09-16-B] Asks for S' reasoning.
> [2015-09-23] (IRC meeting)
> R (speaking for S): "the security team have doubts about
>     mysql upstream security processes; maria is less of a problem";
>     "the security team's complain is that they're doing all the work
>     for security releases when they are required".
> M[MySQL]: We can take that on, and can talk to the security team about
>     required disclosures.
> R: [2015-09-23] [takes action to coordinate with the security team, but
>     never does so]
> U[MySQL]: [2015-12-23] Please explain exactly what you need and I'll
>     start a discussion internally to fix it.
> M[MySQL]: [2016-01-07] Please explain exactly what is missing.
> S: [2016-01-14] "Information about specific security issues and their
>     mapping to fixes...need to be publicly available". "This is EOD
>     from my side. This has all been discussed to death and I won't
>     spend further time on this."
> U[MySQL]: [2016-01-15-B] We want to examine whether we can fulfil
>     Debian's needs under our existing disclosure policies, or get
>     our disclosure policy changed to meet Debian's needs. To do this
>     we need to understand exactly what you need. Please tell us. "If
>     a public announcement linking CVEs and patches is an absolute
>     requirement, is this the only requirement? ... 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."
> R/S: [no response]
> 
> On [2015-12-28], M[MariaDB] asked U[MySQL] for information on some CVEs
> affecting MySQL that might also affect MariaDB. U[MySQL] did not know
> [2016-01-11-C]. S claimed that this is a reason to drop MySQL from
> Debian [2016-01-11-D]. In [2016-01-11-E], M[MySQL] responded that it is
> not reasonable for U[MySQL] to answer questions about MySQL derivatives:
> that it is only reasonable for U[MySQL] to be expected to answer
> questions framed in terms of its own product. M[MySQL] requested that S
> explain exactly what information is required from U[MySQL], framed in
> terms of MySQL. M[MySQL] also pointed out that missing information about
> MySQL means that there is missing information about MariaDB in this
> case, and so there is no technical reason here to reject one variant
> over the other. No response from S since 2016-01-15.
> 
> So far the only input that U[MySQL] have received on this matter is "no
> disclosure of security issues w/ patches" and "Information about
> specific security issues and their mapping to fixes...need to be
> publicly available". This is the full extent of the detail of the
> problem that has been provided by R or S.
> 
> I consider this issue still open. It is blocked on S to tell U[MySQL]
> details on exactly what U[MySQL] need to provide (eg. what they mean by
> "information") so that U[MySQL] can check if they can disclose it under
> their existing policies or understand what exception to seek internally
> so that they can disclose it. It is not reasonable for S to expect
> U[MySQL] to change their policy in order to meet a goal if S refuse to
> tell U[MySQL] how success against that goal will be measured.
> 
> * 3. "we have two forks of the same codebase"
> 
> M[MySQL]: [2016-01-07] not actionable by its nature. But why wasn't this
>     issue raised when MariaDB was accepted into Debian? Why is MySQL
>     vs. MariaDB an exception [examples of other seemingly acceptable
>     forks]?
> R: [no response since 2016-01-07]
> 
> I consider this issue closed. It isn't really an issue that anyone can
> address; more of a statement of fact that doesn't swing the balance
> between MySQL and MariaDB in any particular direction.
> 
> * 4. "point releases can contain anything"
> 
> M[MySQL]: [2016-01-07] Postgres and MariaDB do this at least as much as
>     MySQL [evidence provided]. Why is this a problem with MySQL and
>     not the others?
> R: [no response since 2016-01-07]
> U[MySQL]: [2016-01-07] When we consider whether to commit a proposed fix
>     to a point release branch, we consider how this will affect
>     Linux distros. We are more than happy to discuss what changes
>     are and are not acceptable.
> R: [no response since 2016-01-07]
> 
> I consider this issue closed. MySQL is doing the same as other upstreams
> that Debian accepts, including MariaDB, so there is no reason that this
> swings the balance between MySQL and MariaDB in any particular
> direction. Moreover, U[MySQL] have said that they're willing to discuss
> R's needs to influence what they put in a point release
> [2015-09-23][2016-01-07]. It's just up to R to raise any changes if
> required. Thus, rather than "anything", what goes into a point release
> is currently "what R wants", if only they would tell us.
> 
> 
> * Summary of options and selection status
> 
> My original request for a decision proposed one of the following
> options, which I think we all agree are the only options available:
> 
> 1) We carry and ship both, which I believe is the preference of the
> Debian MySQL Maintainers team by default since we do not agree to any
> other option. We have representatives from both sides who are working
> together and putting in the work to make this work technically.
> 
> 2a) We carry both in unstable, but only MySQL in testing.
> 
> 2b) We carry both in unstable, but only MariaDB in testing.
> 
> 3a) We drop MariaDB completely, keeping only MySQL in unstable and
> testing.
> 
> 3b) We drop MySQL completely, keeping only MariaDB in unstable and
> testing.
> 
> M wants 1. R and S appear to have proposed 2b on the basis of the four
> points of contention summarised above. Following discussion I think all
> of these points have become moot, for the following reasons (again, I'm
> just summarising the arguments that have already been made):
> 
> 1. "mysql isn't maintained in jessie": M[MySQL] have reacted to R's and
> S' concerns and it is now maintained. There is no longer any reason to
> reject MySQL in favour of MariaDB on this basis.
> 
> 2. "no disclosure of security issues w/ patches": this applies equally
> to MySQL and MariaDB as the [2015-12-28] thread shows. U[MySQL] are
> additionally blocked on S to consider making any change to U[MySQL]
> disclosure policy. Whether we drop MySQL or MariaDB from testing, the
> security situation for the remaining variant in Debian remains the same.
> So there is no reason to reject MySQL over MariaDB on this basis.
> 
> 3. "we have two forks of the same codebase": doesn't help pick one over
> the other. So there is no reason to reject MySQL in favour of MariaDB on
> this basis.
> 
> 4. "point releases can contain anything": applies equally to MySQL and
> MariaDB [2016-01-07]. So there is no reason to reject MySQL in favour of
> MariaDB on this basis.
> 
> 
> One final point, made in [2016-01-11-E]: if S would actually engage
> U[MySQL] productively, as U[MySQL] have offered, then we could fix the
> security situation in Debian for both MySQL and MariaDB at once.
> 
> 
> * References
> 
> [2014-10-01-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-October/007114.html
> [2014-10-01-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-October/007115.html
> [2015-07-23-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-July/008020.html
> [2015-07-23-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-July/008021.html
> [2015-07-23-C] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-July/008026.html
> [2015-09-08] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008151.html
> [2015-09-14] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008162.html
> [2015-09-16-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008183.html
> [2015-09-16-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008196.html
> [2015-09-23] http://meetbot.debian.net/debian-release/2015/debian-release.2015-09-23-17.59.log.html
> [2015-12-16] http://meetbot.debian.net/debian-release/2015/debian-release.2015-12-16-19.22.log.html
> [2015-12-28] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-December/008499.html
> [2016-01-07] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008522.html
> [2016-01-11-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008536.html
> [2016-01-11-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008540.html
> [2016-01-11-C] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008533.html
> [2016-01-11-D] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008536.html
> [2016-01-11-E] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008539.html
> [2016-01-14] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008549.html
> [2016-01-15-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008555.html
> [2016-01-15-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008557.html
> [2016-01-18-A] Thread starting at http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008569.html
> [2016-01-18-B] Thread starting at http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008571.html