Mystery meat OpenJDK builds strike again

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.