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-boun...@openjdk.java.net> On Behalf Of > Severin Gehwolf > Sent: Donnerstag, 19. Dezember 2019 21:14 > To: Andrew John Hughes <gnu.and...@redhat.com>; jdk8u-dev <jdk8u- > d...@openjdk.java.net> > Cc: security-dev <security-dev@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
