Mystery meat OpenJDK builds strike again
Andrew John Hughes
gnu.andrew at redhat.com
Wed May 15 21:39:46 UTC 2019
On 15/05/2019 19:49, Gil Tene wrote:
> 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.
> 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.
> Right now, anyone using the *Official* Docker images for OpenJDK 8 and 11
> (https://hub.docker.com/_/openjdk) is probably thinking that they are running
> 8u212 or 11.0.3, when what they are actually running is an interim "work in
> progress build", with several bugs unaddressed, several updates missing,
> and (critically) CVE vulnerabilities that were fixed in the actual
> 8u212 and 11.0.3 un-addressed.
> The mechanics of how this situation came about seem to be:
> The docker file for openjdk:8 (https://github.com/docker-library/openjdk/blob/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce/8/jdk/Dockerfile ) was updated on March 27, 2019, 3 weeks before the actual release of
> OpenJDK 8u212 (see changes in https://github.com/docker-library/openjdk/commit/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce#diff-fef076ee1e5f270f2c5a93d075150919), and is set to use a specific
> Debian stretch build version (8u212-b01-1~deb9u1) that was available
> at that time, pulled via apt-get from debian stretch repos.
> Similarly, the docker file for openjdk:11 (https://github.com/docker-library/openjdk/blob/178c542fbb93a8f8a42e331b73a1214c9d8ba81d/11/jdk/Dockerfile)
> was updated on April 3, 2019, two weeks before the actual release
> of OpenJDK 11.0.3 (see changes in https://github.com/docker-library/openjdk/commit/178c542fbb93a8f8a42e331b73a1214c9d8ba81d#diff-c338262eaf0fd203322a06702be174e0), and set to use a specific
> Debian stretch build version (11.0.3+1-1~bpo9+1) also pulled via apt-get
> from debian stretch repos.
> 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.).
> Making sure OpenJDK version string only show non-EA contents in actual
> release builds (which is the practice we had recently moved to for both 8u
> and 11u) will not necessarily prevent such unfortunate decision chains from
> getting interim builds to unsuspecting end users, but will at least (assuming
> no malice is involved and no manual removal of EA labels happens) make
> it clear to the end user that what they got is not an actual released version.
> — Gil.
Wouldn't this be better raised on the Debian mailing lists than here?
The above is not the default output, so they are already overriding any
defaults we might set. At least it does say it is 11.0.3+1, which can be
compared to the official released version 
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
More information about the jdk-updates-dev