Mystery meat OpenJDK builds strike again

[Gil Tene]

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.

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.

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.