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

[Michael Banck]

Hi,

jumping in here, cause I think this one is really uncalled for:

On Wed, Jan 27, 2016 at 08:30:09PM +, Steven Chamberlain wrote:
> And apart from sponsoring Debian packaging work, Oracle seems
> conspicuously missing from:
> http://debconf16.debconf.org/sponsors.html

So is about everybody else like Google, HP, Canonical - the fundraising
for DebConf16 is ongoing.

> http://debconf15.debconf.org/

Oracle sponsored DebConf15 (as MySQL) at the silver level:

http://debconf15.debconf.org/sponsors.xhtml
http://debconf15.debconf.org/images/sponsors/silver/mysql.png

> https://www.debian.org/mirror/sponsors
> https://www.freexian.com/en/services/debian-lts.html

I hope you see the irony in MariaDB being completely absent from all of
the above.


Michael

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

[Steven Chamberlain]

Norvald H. Ryeng wrote:
> >Norvald H. Ryeng wrote:
> >>Tell us exactly what you want, in detail. If you don't then I don't
> >>think your position is reasonable.
> 
> I don't recognize those words, and it's not in the style I usually express
> myself. Are you paraphrasing?

Sorry, that was Robie Basak being quoted.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

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

[Norvald H. Ryeng]

On Wed, 27 Jan 2016 21:30:09 +0100, Steven Chamberlain  
 wrote:



And apart from sponsoring Debian packaging work, Oracle seems
conspicuously missing from:
http://debconf16.debconf.org/sponsors.html
http://debconf15.debconf.org/
https://www.debian.org/mirror/sponsors
https://www.freexian.com/en/services/debian-lts.html


I don't want to link discussions of financial sponsorship with the fact  
that MySQL is in Debian or with the activities in the Debian MySQL  
maintainer team. Let us please keep those separate. If you want to discuss  
sponsorship, please let's do so in a completely different thread and on  
its own merits.


That said, I want to correct a small factual error:

MySQL was a silver sponsor of DebConf15 and is listed as such. I attended  
the conference and had a great time. In fact, I was the only member of the  
Debian MySQL maintainer team to attend.



Clint Byrum wrote:

[...] if it were written down somewhere as an actual policy. [...]


Norvald H. Ryeng wrote:

Tell us exactly what you want, in detail. If you don't then I don't
think your position is reasonable.


I don't recognize those words, and it's not in the style I usually express  
myself. Are you paraphrasing?



Robie Basak wrote:

So please: the security team needs to engage directly with Oracle by
responding to Norvald's email and enumerating exactly what is wrong.


I don't see that Debian has to do that, at all.  Other upstream projects
seem to 'just get it', so Oracle management is really expecting special
treatment.  IMHO I respond to bad dealings with a company by shopping
elsewhere, not helping them improve their business practices.


I'm not management, but no, we're not expecting special treatment. We're  
asking to know what the requirements that apply to all packages in the  
archive are. Changing security policies/practices is not done easily, and  
our users expect stability and predictability in this area. If Debian  
wants our policies/practice to change, presenting the requirements is the  
first step.


My job is to gather those requirements and present the complete story to  
management so that they can make a decision. If I have to go back to  
management again and again and ask for change because I uncover new  
requirements, I haven't done my job.


But we got some great news yesterday: the security team is working on at  
set of guidelines. I'm glad they do, and I look forward to a chance at  
finally resolving this. I'm optimistic.


Regards,

Norvald H. Ryeng

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

[Clint Byrum]

Excerpts from Steven Chamberlain's message of 2016-01-27 12:30:09 -0800:
> I'll try to make this my last intervention in this thread.  Because
> it's not my decision, or area of responsibility, and I likely won't be
> one of the people having to do the work when a decision is made, but...
> 

I appreciate your words very much Steven.

> Clint Byrum wrote:
> > most of these CVE's would remain fully undisclosed and unfixed in both
> > MySQL and MariaDB if the MySQL engineering team or customers had not
> > found them.
> 
> Sorry, this is not compelling.  As long as Oracle sells MySQL to
> enterprise, it *must* do these things, and release source code to
> satisfy legal obligations of what is a GPL codebase.  It is really only
> doing the bare minimum in that regard.  It was also a condition of
> Oracle's acquisition of MySQL AB:
> 
> "As part of the negotiations with the European Commission, Oracle
> committed that MySQL server will continue until at least 2015 to use the
> dual-licensing strategy long used by MySQL AB, with proprietary and GPL
> versions available"
> according to 
> https://en.wikipedia.org/wiki/MySQL#Legal_disputes_and_acquisitions
> 
> Oracle may still drop MySQL support like a hat due to market conditions,
> regardless of whether Debian has already shipped it by then.
> 

The code dump is definitely a condition, but it turns out that's also
prevented an actual fork of their work from forming. MariaDB does pull
things in, but it's forked so far now that there's still enough compelling
reason to run Oracle's code-dumped version that people choose to do it
every day.

> And apart from sponsoring Debian packaging work, Oracle seems
> conspicuously missing from:
> http://debconf16.debconf.org/sponsors.html
> http://debconf15.debconf.org/
> https://www.debian.org/mirror/sponsors
> https://www.freexian.com/en/services/debian-lts.html
> 

I think this unfairly characterizes them as free riders when the point
we've been trying to make is that they're not free riding, but just
choosing to contribute with engineering time.

> Clint Byrum wrote:
> > [...] if it were written down somewhere as an actual policy. [...]
> 
> Norvald H. Ryeng wrote:
> > Tell us exactly what you want, in detail. If you don't then I don't
> > think your position is reasonable.
> 
> Robie Basak wrote:
> > So please: the security team needs to engage directly with Oracle by
> > responding to Norvald's email and enumerating exactly what is wrong.
> 
> I don't see that Debian has to do that, at all.  Other upstream projects
> seem to 'just get it', so Oracle management is really expecting special
> treatment.  IMHO I respond to bad dealings with a company by shopping
> elsewhere, not helping them improve their business practices.
> 

Of course Debian doesn't have to do it. However, here you have a
corporate citizen who _wants_ to contribute, and they're being told to
buzz off. When asking why, they're getting derisive "if you have to ask
you'll never know" type of treatment.

Just because we don't like them, doesn't mean we can kick them out of
our club.

> This is perhaps more significant than a mere decision over what goes
> into the next release.  I see a really fantastic, rare opportunity for
> Debian to take a moral stand against Oracle for shameful mistreatment
> of free software to date.  rock on \m/
> 

So basically "they're bad people by my own conjecture, so let's stick
it to them". I am sorry, but I thought Debian would welcome those who
follow our rules.

> Niels Thykier wrote:
> > 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.
> 
> I do have personal sympathy for Debian contributors who became entwined,
> by their career choices, with the business preferences of Oracle and
> Canonical.  And the team of MySQL developers who must work under
> Oracle's non-disclosure policies.  But I don't think it should get in
> the way of doing whatever seems right for Debian's users and by its
> own principles.
> 

This is a very broad statement, and I suggest you add _specifics_ to
any accusations that somehow having MySQL in the archive is bad for
Debian's principles. Which principles are not being upheld? The users
are getting well maintained Free software. The fact that it's being
done a way that we all think is silly (and make no mistake, I think it
is one of the silliest things I've ever seen in open source software)
isn't a valid reason to reject it. It just feels good to say.

If you want to kick them out, by all means, do it. But have an actual
reason please.

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

[Robie Basak]

Hi Niels,

Thank you for your considered response.

On Tue, Jan 26, 2016 at 11:50:08PM +, 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?

> 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?

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.

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.

>  * 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


signature.asc
Description: Digital signature

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

[Robie Basak]

Hi Otto,

I agree entirely with the principles you presented, and thank you for
making them.

You also made some technical arguments (and I appreciate that they are
technical and thus valuable and actionable), which I would like to
rebut.

On Wed, Jan 27, 2016 at 12:45:59AM +0200, Otto Kekäläinen wrote:
> - Quality: mysql-5.6 has 135 open bugs despite never being part of a
> Debian release and thus having exposure to the big Debian user masses.
> Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
> which of 5 were filed by myself as TODO items with priority wishlist,
> and it actually ships in Jessie for big audience.

Many bugs were mass transferred from src:mysql-5.5, predate any recent
work, and haven't had any recent activity. On the other hand, MariaDB
being a relatively new package would be expected to have far fewer of
this class of bugs. I have prioritised fixing bigger issues first, over
going through the ancient bugs.

So I think this is an accurate reflection of how well MySQL was
maintained in the past, but not how it is maintained now.

> - Quality: mysql-5.6 ships the same version number
> libmysqlclient.so.18 as 5.5 but the ABI is different and according to
> investigations by Robie Basak going back September 2014 [1] the
> upgrade might break something, and while it is now partially remedied,
> the ABI bump has never been done, the symbols file to track this all
> is missing from the packaging, and there is a Lintian override to keep
> Lintian quiet about the lack of a symbols file [2]

I think this is an excellent example of how well MySQL is maintained and
how well upstream are working with us to sort things out. I was diligent
in finding the problem and then upstream got involved. Upstream did all
the investigatory work to figure out how this impacts Debian, worked
with Debian on deciding what we should do about it, and have now fixed
this and the symbols exported in 5.7 properly. If MySQL gets to stay, I
expect to have 5.7 in Debian soon. The lintian override is ancient,
inherited and I'm happy to remove it.

I tend to focus my efforts on the future, doing the extra thing now to
solve the problem forever. This does mean that it appears poorer in the
short term. I think this should translate to "diligently
well-maintained", not "badly maintained".

> - Quality: mysql-5.6 only runs ~600 tests as part of their Debian
> build, while MariaDB has 4000+ tests, making MySQL test coverage much
> smaller than the MariaDB one, thus catching less issues on many of the
> Debian platforms as Oracle MySQL probalby don't test those at all
> in-house.

This was a deliberate decision to speed up maintenance velocity. I
worked with Oracle to figure out which tests were likely to be useful
from a package maintenance perpsective, and which weren't. We documented
this in debian/README.maintainer. The number of tests run doesn't really
help quantify usefulness. If the release team disagrees with this
principle, I'd be happy to reverse it.

>  - Activity: Since the beginning of 2015 mysql-5.6 packaging master
> branch in Debian unstable has had 118 commits by 12 authors, while the
> mariadb-10.0 master branch in Debian has had in the same time 231
> commits by 14 authors (authors don't include patch submissions and
> translators). I would claim MariaDB is more actively maintained. Note
> that uploads are done by Robie and me for mysql-5.6 and mariadb-10.0,
> who both are DMs. The team does not have any really active DDs at the
> moment, which is a problem for both packages.

I've been working on what I feel are the big issues first, which take
considerable thought and care but don't result in many commits of lines
of code changed. Right now my focus is on 5.7 and also the "flags issue"
that also affects MariaDB. So I don't think it's fair to use a commit
number statistic to determine maintenance activity.

Robie


signature.asc
Description: Digital signature

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

[Niels Thykier]

Robie Basak:
> Hi Niels,
> 
> Thank you for your considered response.
> 
> On Tue, Jan 26, 2016 at 11:50:08PM +, 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





signature.asc
Description: OpenPGP digital signature

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

[Clint Byrum]

Excerpts from Holger Levsen's message of 2016-01-26 02:45:32 -0800:
> Hi,
> 
> On Dienstag, 26. Januar 2016, Clint Byrum wrote:
> > However, I have confidence that our friends in the MySQL engineering
> > team can frame the loss of the last foothold for MySQL in Linux distros
> > as a direct path toward _less_ money for Oracle.
> 
> why do you think so? I mean, doesn't less Mysql mean more OracleDB, thus 
> *more* money for Oracle? ;)
> 
> (I'm not saying that's the case either, I was merely explaining why I'm 
> surprised abour your confidence.)
> 

I'm not so confident it will be _enough_ money to change the security
policy. However, I am confident that a decision has already been made
to support Debian and Ubuntu continuing to ship MySQL. There is direct
evidence of it in the form of Oracle engineers directly contributing to
the packaging effort.

I won't speculate too much on why they believe this, but I imagine one
reason is simple: If Ubuntu and Debian don't have them, it will make
them harder to find, and might push people to select PostgreSQL, or
"anything else that isn't in the distro" when making choices.

> > So if we can just be
> > patient with them, and actually facilitate their participation in this
> > grand community of Debian, it's possible that a compromise can be found.
> 
> Oracle bought Sun in 2010, so personally I don't see how we should be more 
> patient, especially because… the following aint anything new nor special…
>  

Have you ever seen how slowly things change in large corporations?

I know it's hard to believe this, but even _Debian_ moves slowly
sometimes.

https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013196.html

That is the first we talked about removing MySQL for these problems.
Oracle responded directly and has remained engaged since then. That they
haven't changed everything is largely a function of us not being
extremely focused in what we're asking for.

> > Meanwhile, I'd like to challenge someone to point to the exact requirement
> > from any official source affiliated with Debian as to what constitutes
> > an acceptable level of disclosure for a package to remain in the archive.
> 
> sigh.
> 
> go to https://security-tracker.debian.org/tracker/source-package/mysql-5.5 
> and 
> count occurances of the string "Unspecified vulnerability", if you do this 
> with iceweasel it will not even tell you the exact number of matches, just 
> "over 100".
> 
> Now go to 
> https://security-tracker.debian.org/tracker/source-package/mysql-5.6 
> and do the same. The count is at 66 here, but the counter only started 2015.
> 
> So, once again: the exact requirement to be considered is: publish specific 
> information about specific vulnerabilities. Provide meaningful patches for 
> each specific issue.
> 
> Don't release updates with 23 or 42 fixes bundled together with basically no 
> explainations whatsoever.
> 
> And/but this is nothing new and it's very very tiring having to explain this, 
> again and again and still in 2016. It's not like we havent discussed this in 
> 2014, 2013, 2012 and probably also 2011 and 2010.
> 

Holger, I very much value your opinions, and I _hope_ for the same things
from any open source software project. However, you wouldn't have to
explain it if it were written down somewhere as an actual policy. If it
is, please point us to that, so we can point Oracle to it, and provide
them with an ultimatum.

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

[Steven Chamberlain]

I'll try to make this my last intervention in this thread.  Because
it's not my decision, or area of responsibility, and I likely won't be
one of the people having to do the work when a decision is made, but...

Clint Byrum wrote:
> most of these CVE's would remain fully undisclosed and unfixed in both
> MySQL and MariaDB if the MySQL engineering team or customers had not
> found them.

Sorry, this is not compelling.  As long as Oracle sells MySQL to
enterprise, it *must* do these things, and release source code to
satisfy legal obligations of what is a GPL codebase.  It is really only
doing the bare minimum in that regard.  It was also a condition of
Oracle's acquisition of MySQL AB:

"As part of the negotiations with the European Commission, Oracle
committed that MySQL server will continue until at least 2015 to use the
dual-licensing strategy long used by MySQL AB, with proprietary and GPL
versions available"
according to https://en.wikipedia.org/wiki/MySQL#Legal_disputes_and_acquisitions

Oracle may still drop MySQL support like a hat due to market conditions,
regardless of whether Debian has already shipped it by then.

And apart from sponsoring Debian packaging work, Oracle seems
conspicuously missing from:
http://debconf16.debconf.org/sponsors.html
http://debconf15.debconf.org/
https://www.debian.org/mirror/sponsors
https://www.freexian.com/en/services/debian-lts.html

Clint Byrum wrote:
> [...] if it were written down somewhere as an actual policy. [...]

Norvald H. Ryeng wrote:
> Tell us exactly what you want, in detail. If you don't then I don't
> think your position is reasonable.

Robie Basak wrote:
> So please: the security team needs to engage directly with Oracle by
> responding to Norvald's email and enumerating exactly what is wrong.

I don't see that Debian has to do that, at all.  Other upstream projects
seem to 'just get it', so Oracle management is really expecting special
treatment.  IMHO I respond to bad dealings with a company by shopping
elsewhere, not helping them improve their business practices.

This is perhaps more significant than a mere decision over what goes
into the next release.  I see a really fantastic, rare opportunity for
Debian to take a moral stand against Oracle for shameful mistreatment
of free software to date.  rock on \m/

Niels Thykier wrote:
> 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.

I do have personal sympathy for Debian contributors who became entwined,
by their career choices, with the business preferences of Oracle and
Canonical.  And the team of MySQL developers who must work under
Oracle's non-disclosure policies.  But I don't think it should get in
the way of doing whatever seems right for Debian's users and by its
own principles.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

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

[Norvald H. Ryeng]

On Tue, 26 Jan 2016 23:45:59 +0100, Otto Kekäläinen  wrote:


Examples of technical arguments I'd prefer to use instead of general
disgust of Oracle arguments:

- Quality: mysql-5.6 has 135 open bugs despite never being part of a
Debian release and thus having exposure to the big Debian user masses.
Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
which of 5 were filed by myself as TODO items with priority wishlist,
and it actually ships in Jessie for big audience.


I see 113 bugs in src:mysql-5.6 [1], but, OK, it's the same ballpark. Most  
of those are bugs filed against older MySQL versions. If you instead look  
at mysql-server-5.6 [2], you'll get a more accurate number: 12. Could the  
list be cleaned of old, irrelevant bug reports from MySQL 4.1, 5.0 and 5.1  
packaging? Yes, absolutely. But they're not really bothering us in the  
daily work, so other tasks have been prioritized.



- Quality: mysql-5.6 ships the same version number
libmysqlclient.so.18 as 5.5 but the ABI is different and according to
investigations by Robie Basak going back September 2014 [1] the
upgrade might break something, and while it is now partially remedied,
the ABI bump has never been done,


The major version is the same because they were supposed to be compatible.  
However, a small bug squeezed through in a little used feature, and that  
is why they're not fully compatible, and that's what stopped us from  
upgrading to 5.6 in jessie. It was analyzed thoroughly by upstream, and  
the risk of breaking anything is very small. Still, we erred on the safe  
side and didn't upgrade to 5.6 in jessie.


The major number 19 has been reserved for fixing this (which is why MySQL  
5.7 bumps to libmysqlclient.so.20), but it was decided that the downside  
of bumping the version number is greater than the benefits. Basically,  
you'll have to recompile all applications instead of a few that break  
(none of which are in Debian). It's been coordinated with upstream, and  
Debian is free to bump the version number to 19 if wanted.



the symbols file to track this all
is missing from the packaging, and there is a Lintian override to keep
Lintian quiet about the lack of a symbols file [2]


The problem with adding a symbol file is that the library exports more  
symbols than it should, so there's a lot of noise that looks like ABI  
incompatibility, while it isn't if you're looking at the symbols that are  
actually used by clients. The list of exported symbols can be restricted  
in 5.6, but that is definitely something that calls for a major number  
bump, which is why it hasn't been done.


Libmysqlclient in MariaDB has the same problem. There are build options  
that will restrict the list of exported symbols. If you use those, you'll  
get a library that exports a much smaller list of symbols, but without  
bumping the major version of the library, so again you're stuck with  
compatibility issues.


MySQL upstream did a library cleanup in 5.7 which fixed this, so in 5.7  
packaging we can add a symbols file. If we bump the 5.6 library to version  
19, we can do it in 5.6 too.



- Quality: mysql-5.6 only runs ~600 tests as part of their Debian
build, while MariaDB has 4000+ tests, making MySQL test coverage much
smaller than the MariaDB one, thus catching less issues on many of the
Debian platforms as Oracle MySQL probalby don't test those at all
in-house.


It was decided at the packaging sprint in London in December 2014 that the  
test runs should be reduced in order to reduce build time in Debian. Also,  
some timing sensitive tests are skipped to avoid spurious failures on VMs.  
This was done after consulting the upstream QA team, and the selected set  
of tests is believed to be enough to uncover bugs that may be introduced  
in packaging. A larger set of tests can be run by setting  
DEB_BUILD_OPTIONS to "fulltest", which will run more or less the same  
tests that are run per push upstream (still not the entire test suite).


Upstream would of course not mind if the full test suite with thousands of  
test was run after each build, but it would take many, many hours.


Regards,

Norvald H. Ryeng

[1]  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mysql-5.6;ordering=normal;archive=0;repeatmerged=0#_0_6_0

[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mysql-server-5.6

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

[Holger Levsen]

Hi,

On Dienstag, 26. Januar 2016, Clint Byrum wrote:
> However, I have confidence that our friends in the MySQL engineering
> team can frame the loss of the last foothold for MySQL in Linux distros
> as a direct path toward _less_ money for Oracle.

why do you think so? I mean, doesn't less Mysql mean more OracleDB, thus 
*more* money for Oracle? ;)

(I'm not saying that's the case either, I was merely explaining why I'm 
surprised abour your confidence.)

> So if we can just be
> patient with them, and actually facilitate their participation in this
> grand community of Debian, it's possible that a compromise can be found.

Oracle bought Sun in 2010, so personally I don't see how we should be more 
patient, especially because… the following aint anything new nor special…
 
> Meanwhile, I'd like to challenge someone to point to the exact requirement
> from any official source affiliated with Debian as to what constitutes
> an acceptable level of disclosure for a package to remain in the archive.

sigh.

go to https://security-tracker.debian.org/tracker/source-package/mysql-5.5 and 
count occurances of the string "Unspecified vulnerability", if you do this 
with iceweasel it will not even tell you the exact number of matches, just 
"over 100".

Now go to https://security-tracker.debian.org/tracker/source-package/mysql-5.6 
and do the same. The count is at 66 here, but the counter only started 2015.

So, once again: the exact requirement to be considered is: publish specific 
information about specific vulnerabilities. Provide meaningful patches for 
each specific issue.

Don't release updates with 23 or 42 fixes bundled together with basically no 
explainations whatsoever.

And/but this is nothing new and it's very very tiring having to explain this, 
again and again and still in 2016. It's not like we havent discussed this in 
2014, 2013, 2012 and probably also 2011 and 2010.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

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

[Pedretti Fabio]

> * 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.

Another possible alternative (no idea how feasible it is, however) is
1) + having mariadb as a default provider for mysql-server.

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

[Lars Tangvald]

- Original Message -
From: spam...@debian.org
To: ste...@pyro.eu.org
Cc: robie.ba...@ubuntu.com, t...@security.debian.org, 
debian-release@lists.debian.org, pkg-mysql-ma...@lists.alioth.debian.org
Sent: Tuesday, January 26, 2016 8:15:26 AM GMT +01:00 Amsterdam / Berlin / Bern 
/ Rome / Stockholm / Vienna
Subject: Re: [debian-mysql] [Summary] Request for release team decision on 
MySQL and MariaDB
...
>> I was wondering why after the 2016-01-19 announcement, there is still no
>> patched mysql-5.5 in jessie or wheezy;  and also why mariadb was only
>> just patched today.  Debian is typically much faster than this at
>> getting out patches.  Is it to do with complexity, available manpower,
>> or other things?

...
>Regarding the speed of patching: MySQL is massive. It takes several
>hours to build and fully test on a good quality machine. Because the
>patched version came out before the CVE's and CPU's attached to it, some
>of this was already done. But a final set of binaries must be prepared,
>tested, and uploaded. I think it is understandable that this might take
>more than 5 days. But it should be completed soon.

Hi,

I only have a comment on this specific question, as I only work on the 
technical side:
One of the criticisms by the security team has been that Oracle hasn't done 
anything to prepare the security updates. We've agreed that it makes sense for 
us to do this, and for the 2016-01-19 we've been working on preparing the 
patch, but it's been slow going because of unfamiliarity with the security 
patching process. We can definitely do this significantly faster, it's just the 
handover process for this update that's taking time.

--
Lars

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

[Otto Kekäläinen]

Hello!

As the principal maintainer of MariaDB server packaging in Debian I
should probably also chip in here.

First of all I'd like to thank Robie for the summary. Robie is correct
in pointing out that the release and security team's arguments are
somewhat based on disgust for Oracle and less on technical merits of
MySQL packages in Debian.

It is not very nice of Oracle to keep the CVE details hidden even to
the extent that they don't give out the details on a pkg-mysql-maint
mailing list when asked, not even when the questions were regarding
several months old CVEs that Oracle has had fixed in their releases
for some time, and disclosure could not generate much harm anymore.
Not nice indeed, but however not against the Debian policy, as
commenters in this thread rightfully point out. Has any other project
ever been kicked out from Debian due to too much security by
obscurity?

Oracle also has other things freedom and openness loving debianists
don't like, for example non-public bug tracker, non-public source code
development repository, no external committers, all development
discussions are done in in-house meetings and outside participation
via mailing lists or irc is practically impossible, online
documentation is no longer available on a free license, even man pages
have been removed from project source code etc. MariaDB is a much
nicer choice in this regard. Oracle MySQL basically does code dumping
instead of real free and open source software. But so does many other
companies too and their software is included in Debian. DFSG does not
forbid the code dumping style as long as the code dump is actually
released using a real free/open license.

Also the comparisons to OpenOffice vs LibreOffice, Hudson vs Jenkins
etc are not fair. For Oracle the MySQL project has a special role and
they keep developing it, so it is not a good argument to bluntly
punish Oracle MySQL for mismanagement in other projects.

The release and security teams should present, as Robie points out,
concrete and actionable lists on things that are wrong, and the
"wrongness" should preferably be based on Debian policy or something
else predictable and not on newly invented rules.

Presenting ethical arguments is OK if they are based on Debian core
documents. I am of course not against using ethics in the decision
making process, but the people who put a lot of time and effort in
MySQL packaging in Debian need fair treatment, and more objective
technical arguments are therefore preferred.

Presenting technical arguments should be based on a comparison of e.g.
https://tracker.debian.org/pkg/mysql-5.5
https://tracker.debian.org/pkg/mysql-5.6
https://tracker.debian.org/pkg/mariadb-5.5
https://tracker.debian.org/pkg/mariadb-10.0

Examples of technical arguments I'd prefer to use instead of general
disgust of Oracle arguments:

- Quality: mysql-5.6 has 135 open bugs despite never being part of a
Debian release and thus having exposure to the big Debian user masses.
Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
which of 5 were filed by myself as TODO items with priority wishlist,
and it actually ships in Jessie for big audience.

- Quality: mysql-5.6 ships the same version number
libmysqlclient.so.18 as 5.5 but the ABI is different and according to
investigations by Robie Basak going back September 2014 [1] the
upgrade might break something, and while it is now partially remedied,
the ABI bump has never been done, the symbols file to track this all
is missing from the packaging, and there is a Lintian override to keep
Lintian quiet about the lack of a symbols file [2]

- Quality: mysql-5.6 only runs ~600 tests as part of their Debian
build, while MariaDB has 4000+ tests, making MySQL test coverage much
smaller than the MariaDB one, thus catching less issues on many of the
Debian platforms as Oracle MySQL probalby don't test those at all
in-house.

 - Activity: Since the beginning of 2015 mysql-5.6 packaging master
branch in Debian unstable has had 118 commits by 12 authors, while the
mariadb-10.0 master branch in Debian has had in the same time 231
commits by 14 authors (authors don't include patch submissions and
translators). I would claim MariaDB is more actively maintained. Note
that uploads are done by Robie and me for mysql-5.6 and mariadb-10.0,
who both are DMs. The team does not have any really active DDs at the
moment, which is a problem for both packages.

[1] 
http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812812
[3] git log --since='2015-01-01' --oneline | wc -l
[4] git log --since='2015-01-01' | grep Author | sort -u | cut -c -20
| sort -u | wc -l


Then a few words about the decision:

2016-01-26 0:14 GMT+02:00 Robie Basak :
> 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 

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

[Otto Kekäläinen]

Hello!

2016-01-26 2:48 GMT+02:00 Steven Chamberlain :
> I was wondering why after the 2016-01-19 announcement, there is still no
> patched mysql-5.5 in jessie or wheezy;  and also why mariadb was only
> just patched today.  Debian is typically much faster than this at
> getting out patches.  Is it to do with complexity, available manpower,
> or other things?

Technically I could have uploaded MariaDB 10.0.23 earlier, but I
cannot convince the stable release team or security team to upload it
to Jessie before it has officially been announced as a security update
with CVE identifiers and all.

I Ubuntu there is the Micro Release Exception, so in could have got
5.5.47 uploaded to Ubuntu 14.04 even without explicit security update
motivation. In fact I did prepare the upload and file
https://bugs.launchpad.net/ubuntu/+source/mariadb-5.5/+bug/1524704 on
December 10th, but as it as not a known security update at that time
nobody got interested enough to upload it.. Maybe tomorrow somebody
will as Ubuntu announced the MySQL security notice today, and Ubuntu
people usually accept my security updates in 1-2 days.

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

[Otto Kekäläinen]

2016-01-26 10:49 GMT+02:00 Stephan Seitz :
> On Tue, Jan 26, 2016 at 12:48:23AM +, Steven Chamberlain wrote:
>>
>> Assuming MariaDB is affected by the same issues, I may not be in a
>> technically better situation if I switched to using that.  (Although, it
>
>
> But as far as I understand it there is no guarantee that MySQL and MariaDB
> will stay compatible in the future.
>
> So what are you doing if MySQL is removed and other programs (e.g. cacti)
> are not working with MariaDB anymore?

Oracle people can fill in if I have the wrong info, but I think that
it is mostly Oracle MySQL that does not track MariaDB changes, while
the other way happens and at least MariaDB will be compatible with
MySQL for the forseeable future and migrating from MySQL to MariaDB
will work.

Also, I've read that Oracle has dropped some of the older code
(probably mostly a well justified clean-up) and therefore for example
5.6 and 5.7 are not fully backwards compatible, and some apps might
need to change to accomodate for changes. So Oracle MySQL is in this
sense not always "compatible" with itself either.

This compatiblity discussion is not very practical, its just corner
cases. For example for all Cacti or WordPress users any version fo
MySQL and MariaDB will most likely work just fine in the foreseeable
future.

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

[Niels Thykier]

Pedretti Fabio:
>> * Summary of options and selection status
>>

Hi Robie,

I appreciate your intention.  However, I felt it was way too long for a
summary and at this point it still TL;DR for me and I fear I won't have
time to read and digest it all.

However, I can certainly understand that you wanted to include all of
that.  Personally, I can see several points for improvements on the
Debian release team's side.

>> My original request for a decision proposed one of the following
>> options, which I think we all agree are the only options available:
>>
> [...]
> 

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

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].

In summary (again, *from my PoV*):

 * None of the currently available "reasonable options" include status
   quo (excl. 5).
   - Ergo, I see it as a transition of the default.

 * 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

 * For me, 1, 3 and 5 seems too unreliable / too unlikely that I am
   convinced we should accept the risks involved in it.
   - While I consider 2 unlikely, it has lower "risk" for me.  Notably
 going from "2" to "4" (and vice versa) is vastly easier than from
 "1" to "2".

Beyond this, I can certainly appreciate your desire to resolve the
situation between the security team and MySQL upstream on CVE
disclosures etc.

Thanks,
~Niels

PS: Re: 3)+4) I think it is largely irrelevant for the release team and
the security team whether the removal *also* includes unstable. At the
very least, it is a secondary concern, so I have decided to omit this
distinction.

[1]
https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#limited-security-support

[2] Rationale: Missing security support would certainly have to go in
the Stretch variant of [1]. That makes for a very bad release to have a
default implementation being *without* official security support.
Whether the MySQL team can deliver something comparable is a separate
debate.





signature.asc
Description: OpenPGP digital signature

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

[Niels Thykier]

Otto Kekäläinen:
> Hello!
> 
> As the principal maintainer of MariaDB server packaging in Debian I
> should probably also chip in here.
> 

Hi,

Thanks for your input.

 * Re: Meeting time - I have noted 19:00 UTC tomorrow in my calender.
 * I will cut this very short as I am out of time.

> [... Suggestions / Information / etc. ...]

Don't claim to have read and fully digested all of it.  But certainly
appreciate the different angles and technical merits of MariaDB and MySQL.

> 
> If you want to see an increased shift towards MariaDB we could mass
> file bugs against packages that have "Depends: mysql-server |
> virtual-mysql-server" to switch to "Depends: mariadb-server |
> virtual-mysql-server" so that the "Debian default" would be MariaDB

From my PoV, this would be very helpful if the default was changed.

> [...]

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

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

[Colin Charles]

Hi!

First off, I thank Robie for the excellent summary, and think this is a healthy 
discussion to have, so kudos to all participants

I feel I can’t make any comments on this thread as I’m employed to work on 
MariaDB Server, but will just make one point as below

> On 27 Jan 2016, at 06:45, Otto Kekäläinen  wrote:
> 
> commenters in this thread rightfully point out. Has any other project
> ever been kicked out from Debian due to too much security by
> obscurity?

I think elasticsearch might fit the bill:
https://lists.debian.org/debian-security-announce/2015/msg00290.html

cheers,
-colin

--
Colin Charles, http://bytebot.net/blog/
twitter: @bytebot | skype: colincharles
"First they ignore you, then they laugh at you, then they fight you, then you 
win." -- Mohandas Gandhi



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Clint Byrum]

Excerpts from Holger Levsen's message of 2016-01-25 17:04:57 -0800:
> Hi,
> 
> On Dienstag, 26. Januar 2016, Steven Chamberlain wrote:
> [...other valid points not quoted here…]
> > Assuming MariaDB is affected by the same issues, I may not be in a
> > technically better situation if I switched to using that.  (Although, it
> > seems one of the recent CVEs did not affect MariaDB?).  But I look at
> > their public bug dashboard as a model of how open I want development to
> > happen, and it makes me _feel_ more comfortable and optimistic in that
> > project already.
> 
> Steven, thanks for wording this (all of it, also the non quoted parts) much 
> better than I care to do. As I said on IRC on #debian-release:
> 
> * | h01ger is tempted to reply "tl;dr; - mysql is the db with the NDA from 
> oracle, mariadb is the free fork shipped everywhere - without NDAs and 
> without 
> a history of screwing free software, so let's EOT here" to the recent mail in 
> that thread…
> 
> - I know this is somewhat too simplefied, eg I do acknowledge and hope that 
> Oracle can do better than "screwing free software", but… *they* need to show 
> this *by themselves*. 
> Yet when I read this in Robie's mail: "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." I have little 
> hope + motivation to explain this better - CVE is a public database.
> 
> So, another summary: there's a software from a company with NDAs (which have 
> been applied to the question at hand, no less) and "a history of screwing 
> free 
> software" and there's a project to reuse the same codebase (and then build on 
> it) to not do that.
> 
> Also, I wonder why https://en.wikipedia.org/wiki/MariaDB#Prominent_users … ;-)
> 

Holger, I understand this frustration entirely. But let's be completely
honest here. Nobody has told Oracle exactly what Debian wants. I know,
it seems like it should be obvious, but for Oracle, they speak money
_first_, and then software. I know, also, that this is anathema to many
users, and this alone is enough to drive some to want to have nothing
to do with MySQL. _I get that_. MariaDB is right over here, and I invite
those of you who feel this way to switch to that fine fork of MySQL.

However, I have confidence that our friends in the MySQL engineering
team can frame the loss of the last foothold for MySQL in Linux distros
as a direct path toward _less_ money for Oracle. So if we can just be
patient with them, and actually facilitate their participation in this
grand community of Debian, it's possible that a compromise can be found.

Meanwhile, I'd like to challenge someone to point to the exact requirement
from any official source affiliated with Debian as to what constitutes
an acceptable level of disclosure for a package to remain in the archive.

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

[Clint Byrum]

Excerpts from Steven Chamberlain's message of 2016-01-25 16:48:23 -0800:
> Hi,
> 
> As a mere user (systems administrator), I'll share some questions /
> criticisms from my perspective that might help shed some light on the
> underlying issues.
> 
> I was wondering why after the 2016-01-19 announcement, there is still no
> patched mysql-5.5 in jessie or wheezy;  and also why mariadb was only
> just patched today.  Debian is typically much faster than this at
> getting out patches.  Is it to do with complexity, available manpower,
> or other things?
> 
> Another concern I have is that when I check Debian's Security Tracker, I
> although I can see which CVEs apply to my (still unpatched) systems, the
> only descriptions I have are for example:
> "[...] allows remote authenticated users to affect integrity via unknown
> vectors related to encryption"
> 
> That is definitely not okay in a free, open-source software project.  I
> want to be able to evaluate how/whether my specific configuration is
> vulnerable and assess the risk for myself, while I wait for patches to
> come, and decide if I even want to apply them at all.
> 
> Why is it that way?  It reflects badly on Oracle that they don't or
> can't do better, and it reduces my personal trust in them.
> (It's in the Debian Social Contract, "we will not hide problems").
> 
> In contrast, for something as complex as the Linux kernel, I'm usually
> pointed to a specific Git commit showing how and where the bug was
> fixed, and there's often public discussion of the vulnerability in Red
> Hat's bug tracker or other sources.
> 
> Assuming MariaDB is affected by the same issues, I may not be in a
> technically better situation if I switched to using that.  (Although, it
> seems one of the recent CVEs did not affect MariaDB?).  But I look at
> their public bug dashboard as a model of how open I want development to
> happen, and it makes me _feel_ more comfortable and optimistic in that
> project already.
> 

Hi Steven. Thanks very much for your participation in this discussion.

One of the nuances that gets missed in these undisclosed, vague
vulnerability messages, is that most of these CVE's would remain fully
undisclosed and unfixed in both MySQL and MariaDB if the MySQL engineering
team or customers had not found them.

Does this excuse Oracle for their misguided policy of non-disclosure?
Absolutely not. But I want to make it clear that we wouldn't even know
about these vulnerabilities were it not for them. So which is worse:
knowing that you might be broken, or not knowing at all.

Regarding the speed of patching: MySQL is massive. It takes several
hours to build and fully test on a good quality machine. Because the
patched version came out before the CVE's and CPU's attached to it, some
of this was already done. But a final set of binaries must be prepared,
tested, and uploaded. I think it is understandable that this might take
more than 5 days. But it should be completed soon.