[debian-mysql] Fwd: osmalchemy is marked for autoremoval from testing

[Norvald H. Ryeng]

On Fri, 13 Jan 2017 12:11:20 +0100
Kristian Nielsen <knielsen at knielsen-hq.org> wrote:

> "Norvald H. Ryeng" <norvald.ryeng at oracle.com> writes:
> 
> > On Thu, 12 Jan 2017 22:38:19 +0100
> > Kristian Nielsen <knielsen at knielsen-hq.org> wrote:  
> 
> >> That's ridiculous. MySQL upstream has for years been deliberately
> >> forging the git repo, removing information about security fixes.
> >> The  
> 
> > That has not been brought up as a reason for kicking MySQL out of
> > stretch. The only reason given by the security team is that there is
> > no public mapping between CVE IDs and patches/commits. All other
> > requirements have been met.  
> 
> Seems the same thing to me, deliberately removing security fix
> information from publicly available sources?

Test cases for security bug fixes have been discussed to death with the
security team before. They know very well that they aren't there, and
they don't like it. Upstream knows and understands this, but it has
been impossible to find a solution that both parties agree on. This
discussion is finished, and the parties agree to disagree.

Still, not liking something is not a reason to remove a package. Having
test cases for all security bug fixes is not part of the security
team's requirements. If it were, a lot more packages in Debian would be
out of policy.

> > The security team claims this is a requirement for all software in
> > Debian. It's not hard to find other examples of software in Debian
> > that doesn't fulfill this requirement. However, MySQL is the only
> > package removed because of it.
> >
> > Other software where I can't find a public mapping between CVE IDs
> > and patches/commits include projects such as Firefox and MariaDB.  
> 
> Ehm, what? Firefox was removed for years from Debian in favour of
> Iceweasel.

It was renamed Iceweasel because of rights issues, and that point is
both solved now (https://lwn.net/Articles/676799/) and completely
irrelevant to this discussion. This is about having a public mapping
between CVE IDs and patches. AFAICT, they don't have it, and Firefox is
still in Debian.

> And patches are explicitly mapped to MariaDB CVE's on a
> security@ mailinglist where distros get advanced notice - except for
> those secret CVEs that are inherited from MySQL (and even those are
> reverse-engineered by MariaDB engineers, when possible).

Is that list publicly archived? A closed mailing list is not what I
would call a "Public mapping between CVE IDs and patches (or commit IDs
to a public VCS)", which is the requirement the security team claimed
applied to all packages.

If a closed mailing list is enough, that changes the possibilities of
MySQL fulfilling the security team's requirements.

> Do you really not see the problem? This is how things look to someone
> following the discussion from the side: You were basically saying to
> Debian/the release team: "Hi, we noticed that a few projects are
> screwing you over. We would like to screw you over at least as badly,
> can you please advice us on how best to do that?". That really is not
> a good way to approach Open Source participation, neither in Debian
> nor elsewhere.

If that impression you have, I suggest you read up on what really
happened on the publicly archived pkg-mysql-maint mailing list.

The short story: The security and release teams kept telling the
pkg-mysql-maint team to pick only one DBMS for stretch. After a long
discussion where the pkg-mysql-maint team repeatedly said it wanted to
package both DBMSs, the release team backed out of that demand. Then,
the security team wanted to remove MySQL packages from stretch. After
many requests from the pkg-mysql-maint team, the security team finally
produced a reason: a list of requirements where MySQL failed on one
point, which they claimed applied to all software in Debian. However,
even if there is other software in Debian that don't follow those
requirements, only MySQL is removed from stretch.

I hope you can now see why the MySQL maintainer team feels it's
been treated unfairly.

> If you dissagree with the removal of MySQL, then what is your
> recommendation for the release and security team to better ensure
> availability of proper information about security holes and fixes?

To treat MySQL as all other software in Debian. Not having a public
mapping between CVE IDs and patches is not unique to MySQL.

For other projects, e.g., Firefox and MariaDB, it seems to be enough to
publish a mapping between CVE IDs and software versions. Oracle does
the same for MySQL, so why is it good enough for other software, but
not for MySQL?

Regards,

Norvald H. Ryeng