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

Andrew John Hughes gnu.andrew at redhat.com
Fri Dec 20 07:42:12 UTC 2019



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191220/cd2d6e41/signature.asc>


More information about the security-dev mailing list