[8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program

Severin Gehwolf sgehwolf at redhat.com
Thu Dec 19 20:13:45 UTC 2019

Hi Andrew,

On Thu, 2019-12-19 at 19:29 +0000, Andrew John Hughes wrote:
> On 17/12/2019 19:30, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get a review of this OpenJDK 8u backport of 8232019. The
> > JDK 11 patch did not apply cleanly for a couple of reasons:
> > 
> >    1. 8u still has the binary blob for cacerts (JDK-8193255 not
> >       backported, yet). Instead, I've updated to the revision in jdk11u,
> >       performed a build and copied the cacerts binary to 8u.
> >    2. JDK-8225392 not present in 8u, which added the checksum to
> >       VerifyCACerts.java. Thus, the 8u backport does not include this
> >       hunk. @bug annotation modified manually for the same reason.
> > 
> > Everything else is the same.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8232019
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/
> > 
> > Testing: sun/security/lib/cacerts/VerifyCACerts.java and
> >          security/infra/java/security/cert/CertPathValidator/certification
> >          Pass, except for ActalisCA.java which is problem-listed and still
> >          broken in HEAD (JDK-8224768)
> > 
> > Thoughts?
> > 
> > If reviewed, I'll try to get this in 8u242 via the critical fix request
> > label workflow.
> > 
> > Thanks,
> > Severin
> > 
> Going on this & the similar Amazon fix, I'd say we should backport
> JDK-8193255 & JDK-8225392 first. The previous updates which alter a
> binary file have been pretty much unreviewable and, if there's a better
> solution to that, I'd rather we had it sooner rather than later.

I agree with you that we should backport JDK-8193255. Question is when
would be a good time to do this. Given that there would be some benefit
for these to go into 8u242 if possible I'm not sure we should do JDK-
8193255 right now. After all, we've accepted this situation of having
the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 -
which brought this in - was integrated in 8u222.

The risk of a backport of JDK-8193255 seems higher (the build system in
8u is different, there is a bug tail) than accepting these backports
with the binary blob updates. Note that the backports as-is have been
reviewed by Christoph Langer, Volker Simonis and internally by Martin

So, it looks like there are the following options:
   1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is.
   2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK-
      8233223 to 8u242.
   3. Defer backports of 2) to 8u252 with the caveat that we won't have
      certain certificates as compared to Oracle JDK.

I'm leaning towards option 1) or 3). Slight preference for 1)

> Likewise, judging by the comment on JDK-8234245, I'd say that needs to
> be applied between the LuxTrust & Amazon ones:
> "This fixes an issue after JDK-8232019, so it needs to be included.
> Patch applies cleanly."

Not sure what caused JDK-8234245. It might be that it was caused by the
list of certs in the keystore not being ordered at first (fixed by JDK-


More information about the security-dev mailing list