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

[Severin Gehwolf]

On Fri, 2019-12-20 at 07:42 +0000, Andrew John Hughes wrote:
> 
> On 19/12/2019 20:13, Severin Gehwolf wrote:
> 
> snip...
> 
> > > 
> > > 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
> > 
> 
> There's an option #4:
> 
> 4. Propose these backports for 8u242 and do the correct backports, with
> JDK-8193255 and friends, in 8u252.

OK.

> 8193255 is sensitive to the status of cacerts at the time it is applied.
> It needs to be backported with cacerts containing the same certificates
> as it did when applied in later versions, so that the textual
> replacements match. By applying these backports in 8u252, we'd
> complicate the 8193255 backport further by having to effectively include
> backports of the Amazon & LuxTrust updates in it.
> 
> So what I'd suggest is:
> 
> 1. Do the full backport series in 8u252 from 8193255 on.
> 2. Create a separate bug for 8u242 to add the new certificates and apply
> for jdk8u-critical-request for that.

Can you clarify why a separate bug for 8u242 would be needed? Why can't
we just use 8232019 and 8233223? I'd include mentioning 8232019 and
8233223 for the backport of 8193255 for it to be clear that it has been
taken care of those additional cert updates. The 8193255 backport would
only start once 8u242 backports got merged back into jdk8u-dev. At no
point we'd miss inclusion of those. Saves creation of extra bugs.

Thanks,
Severin

> When the two are merged together, the webrev changes in 8u242 should be
> the same as those in 8u252, and the changed cacerts binary can just be
> deleted.
> 
> Thanks,