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

[Langer, Christoph]

Hi,

Just FWIW: JDK-8234245 fixed an issue where a wrong checksum was used in the test update that came with JDK-8232019. So, both can probably marked fixed with one change (e.g. adding both bugs to the submit message...)

Cheers
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Severin Gehwolf
> Sent: Donnerstag, 19. Dezember 2019 21:14
> To: Andrew John Hughes <gnu.andrew at redhat.com>; jdk8u-dev <jdk8u-
> dev at openjdk.java.net>
> Cc: security-dev <security-dev at openjdk.java.net>
> Subject: Re: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
> existing root program
> 
> 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
> Balao.
> 
> 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-
> 8225392?).
> 
> Thanks,
> Severin