[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mystery meat OpenJDK builds strike again




> On May 26, 2019, at 3:25 PM, Matthias Klose <doko@ubuntu.com> wrote:
> 
> I am disappointed to see such trolling, bashing and telling fake news on a
> technical mailing list.  Is this Azul's business model to promote their own
> binary builds?
> 
> Such behavior propagates e.g. via twitter
> https://twitter.com/jroper/status/1130678379403857920
> 
> I'm starting the discussion about version numbers and release information in a
> new thread.
> 
> I am neither involved with any Docker image nor with any Debian backport.
> 
> Debian provides security support for its stable release (stretch, 9.x).
> openjdk-11 isn't part of any released Debian version.
> 
> Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is
> committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until
> the EOL of Ubuntu 16.04 LTS (around April 2021).
> 
> Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update
> to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the
> security pocket).
> 
> There is no mystery meat, just security supported uploads for both Debian and
> Ubuntu.

With such an emphatic attack on the motives associated with the original posting on
this thread, I tried to figure out what might lead someone to take that path. I can attribute
one of few possible logic paths that may lead you to making the above argument:

a) You never bothered to check any of the actual facts posted, and just assumed the
original posting was fake news.

b) You did check the facts, but read the output wrong (like most people in the world
would have, since the scary details behind the specific 8u212 and
11.0.3 builds involved need some digging to figure out), and somehow assumed that the
thing reporting e.g. 'openjdk version "1.8.0_212"' was a good (non-Mystery-Meat) build
of the released version being reported.

c) You know the facts, but want others to think someone else is wrong for pointing them
out, and go about doing that by trying to associate as many negative motives as you can
muster ("trolling", "bashing", "fake news", "marketing", "business model", "advertising",
"promotion", all of which you had literally used in this one e-mail) to the factual posting
at the top of this tread.

d) You think the facts posted, even when true, do not amount to the associated builds
deserving to be called Mystery Meat.

So let's quickly dispense the first two possibilities: If the benefit of the doubt for not actually
realizing the truth of the situation, and the accuracy of the contents of the original e-mail is
deserved, and you wrongly called this stuff "fake news", go ahead and check on the facts
and come back to us with a correction.

But somehow (see below), I doubt that (a) or (b) explain your misrepresentation of facts in
this e-mail.

I doubt that the original e-mail in this thread could have been much more clear or specific
in documenting the actual Mystery Meat situation in the wild on the date it was posted.
Thankfully, the Official Docker openjdk images has since fixed their official builds to no
longer present docker users with images containing faulty, Mystery Meat 8u212 and
11.0.3 OpenJDK versions.

However, there seem to be plenty of people (you included, clearly, per this very e-mail)
who are trying to argue that the builds themselves are not a problem, that it is the lack of
education or understanding of the end-user that is responsible, etc. Many of these
arguments have taken a deflection approach of e.g. focusing on OpenJDK 11, combined
with something like "the good, stable, meant-for-actual-use, security-supported version of
Debian (debian stretrch, 9.x per the above) does not provide openjdk-11, and some
irresponsible middle-person act of taking mislabeled builds from other repos (e.g. backports,
unstable, etc.) is to blame.

Fine, let's go with that for just a minute. Ignore the fact that the original posting was about
the end-result (and specifically stated "Why Debian populated their repos with these builds
is their business") and ignore the impact on OpenJDK 11. Just for a  minute. Let's focus on
the OpenJDK 8 part, and let's test the facts, *today*, and limit our testing to the stable,
"security supported uploads" in Debian stretch:

We still end up staring at this very inconvenient truth: OpenJDK 8, Debian (stable, stretch, 9),
and the current situation (two weeks into being alerted to it) show the following right now:

root@020dc36b9046:/#
root@020dc36b9046:/# date
Sun May 26 23:55:45 UTC 2019
root@020dc36b9046:/#
root@020dc36b9046:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";
root@020dc36b9046:/#
root@020dc36b9046:/# apt-get update
Ign:2 http://cdn-fastly.deb.debian.org/debian stable InRelease
Hit:1 http://security-cdn.debian.org/debian-security stable/updates InRelease
Hit:3 http://cdn-fastly.deb.debian.org/debian stable-updates InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stable Release
Reading package lists... Done
root@020dc36b9046:/#
root@020dc36b9046:/# apt-get install openjdk-8-jdk
...
root@020dc36b9046:/#
root@020dc36b9046:/# java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01)
OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)
root@020dc36b9046:/#

To be clear on what ״build 1.8.0_212-8u212-b01-1~deb9u1-b01" in the above tracks to,
we can track it in https://tracker.debian.org/pkg/openjdk-8 , which has this convenient log
for when the build was created (March 29, 2019, 3 weeks prior to the actual release of
8u212 by the OpenJDK 8u project):

	• [2019-04-06] openjdk-8 REMOVED from testing (Debian testing watch)
	• [2019-03-30] Removed 8u212-b01-1 from unstable (Debian FTP Masters)
	• [2019-03-30] Removed 8u144-b01-2 from unstable (Debian FTP Masters)
	• [2019-03-30] Removed 8u141-b15-3 from unstable (Debian FTP Masters)
	• [2019-03-29] openjdk-8 8u212-b01-1 MIGRATED to testing (Debian testing watch)
	• [2019-03-29] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into proposed-updates->stable-new, proposed-updates (Moritz Muehlenhoff) (signed by: Moritz Mühlenhoff)
	• [2019-03-20] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into stable->embargoed, stable(Moritz Muehlenhoff) (signed by: Moritz Mühlenhoff)
	• [2019-03-19] Accepted openjdk-8 8u212-b01-1 (source) into unstable (Matthias Klose)

[The fact that your name is on the actual log items above makes it unlikely that options (a) or (b) above apply. It's pretty clearly (c) and/or (d).]

So what do we have here?

A mislabeled (' openjdk version "1.8.0_212" ', no disqualifiers, early access, or "danger,
this is not really 8u212" labeled anywhere), fell off the truck (actually built from sources
picked up at a random weekly tag point, 3 weeks prior to the actual 8u212 release was
complete, and missing a multitude of bug fixes and security fixes that are in the actual
8u212 release), build of OpenJDK "8u212" is being delivered in the current, stable, debian
release from default repositories. Not the unstable repos, not the backports repos, not
by some other version's repos, not by some middle-men.

You may not think that "Mystery Meat" is a good label for this very situation. But I suspect
that would put you in the tiny minority of people who believe or argue that all meat, from all
sources, is equally untrustworthy. And that labels, cleanliness, use-by-dates, and (most
importantly) reputation for label accuracy and trustworthiness should not affect people's
consumption choices.

That's what is going on right now. Arguing that someone else is to blame doesn't change
it. Arguing that "the media" is against you and has nefarious motives doesn't either. And
arguing that "this is fine, and it is what users of "stable" Debian should expect", well, that
just tells them what to expect, I guess.

> 
> On 15.05.19 20:49, Gil Tene wrote:
>> Umm…
>> 
>> Lumpy.local-43% docker run -it --rm openjdk:8 java -version
>> openjdk version "1.8.0_212"
>> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01)
>> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)
>> Lumpy.local-44% date
>> Wed May 15 11:41:12 PDT 2019
>> 
>> Look at the build number carefully… This was populated no later
>> than March 27, 2019. 3 weeks before the actual 8u212 was released
>> on April 16, 2019.
> 
> The Debian openjdk-8 source package is put together from the jdk8u,
> aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects.  Certainly not
> ideal, however these packages can only be made if all the sources are available,
> or tagged.
> 
> I am happy to see that the aarch64-port tries to keep up with the jdk8u project
> however this is a different story with the aarch32-port project:  The project
> doesn't have *any* prerelease tags, plus the project updates it's release tags
> only months after the jdk8u releases.  So blaming Debian for shipping what they
> are able to ship and Azul holding back source releases yourself?   Ein Schelm
> wer Böses dabei denkt ...
> 
>> Similarly:
>> 
>> Lumpy.local-46% docker run -it --rm openjdk:11 java -version
>> openjdk version "11.0.3" 2019-04-16
>> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91)
>> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing)
>> Lumpy.local-47% date
>> Wed May 15 11:43:12 PDT 2019
>> 
>> This one was populate dno later than April 3, 2 weeks before
>> the actual 11.0.3 was released on April 16, 2019
>> 
>> If anyone was wondering about the importance of having version strings say
>> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any
>> and all OpenJDK builds that are not an actual release build, the above shows
>> you how bad things get when that practice is not followed.
> 
> Don't trust the label, just the content.  I agree that the java community is
> much more label/version driven, however this is not a reason to discredit other
> sane builds.
> 
>> Why Debian populated their repos with these builds is their business, and
>> why docker chose to use those specific debian builds can be speculated
>> about all we want. the details don't matter. The end result of these
>> cumulative "reasonable" (according to some people) choices is that the
>> default openjdk runs done by millions of people on docker right now are
>> using "mystery meat", incomplete, and exposed builds while seeming to
>> report (to the lay person) a Java version that would suggest a real 8u212
>> or 11.0.3 (which one would expect has the security vulnerabilities in the
>> April update addressed, the bug fixes included, etc.).
> 
> Again, I see this as an advertising or promotion email for the Azul binary
> builds.  Fine, do so.  Both please use marketing lists and not the OpenJDK
> technical lists.
> 
> Matthias

Attachment: signature.asc
Description: Message signed with OpenPGP


Reply to: