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. 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. 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, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew
signature.asc
Description: OpenPGP digital signature
