RFR 8189131: Open-source the Oracle JDK Root Certificates

[Magnus Ihse Bursie]

On 2017-12-05 10:25, Volker Simonis wrote:
> On Tue, Dec 5, 2017 at 10:08 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2017-12-05 09:44, Volker Simonis wrote:
>>> On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>> On 2017-12-01 18:16, Volker Simonis wrote:
>>>>> Hi Rajan,
>>>>>
>>>>> great to see this finally happen!
>>>>>
>>>>> I have just a quick question related to the tests. As far as I can
>>>>> see, the tests will only succeed if the OpenJDK will be build with the
>>>>> new open sourced, Oracle root certificates. But what if somebody is
>>>>> building the OpenJDK with his own set of root certificates (by using
>>>>> the --with-cacerts-file option)? Do you see any possibility of
>>>>> restricting these tests only to builds which used the original,
>>>>> checked in cacerts file?
>>>>
>>>> My question is if the --with-cacerts-file option is still relevant after
>>>> this? I see a good chance of simplifying some build logic here. :-)
>>>>
>>> I think the folks from the AdoptOpenJDK project are using this option
>>> (CC-ed adoption-discuss). I'm not sure if they want to drop their root
>>> certificates in favor of the new ones.
>> Maybe they can upstream their root certs as well, if it seems prudent?
>>> It general I think it would be useful to have something like
>>> "--add-cacerts-file" which will merge in additional certificates
>>> although this will most certainly complicate the build logic :)
>> I see your point, but if the idea is that distributors should be able to
>> supply their own set of root certs (which kind of makes sense, after all) we
>> should probably keep the current functionality. Otherwise there's no way to
>> remove a root cert, which is also something you might want to do (if a CA
>> goes rouge, or whatever).
>>
>> But then again, I think this borders just on the line were it's reasonable
>> for configure to provide an option to replace the file. If a distributor is
>> not satisfied with the contents of a file in OpenJDK, they are always free
>> to replace it. The normal way to do this is to use patches that are applied
>> on top of the OpenJDK source distribution. If you want to have your own ca
>> root store, you would just need a patch with your own file. Voilà! The only
> I think the most common case would be that distributors want to add
> their certificates to the existing ones? And that's not easily
> achievable with a patch because the cacerts file is a binary file. So
> you need to call keytool for importing additional certificates. It
> would be of course convenient if this could happen as part of the
> build process.
If you say.

Let's see if that *really* becomes an issue. In the meantime, I'm always 
open for patches from distributors. :)

/Magnus
>
>> reason this was made an option is that the OpenJDK distribution didn't
>> include a root store at all by default, so *all* users needed to provide one
>> for it to be usable. Now that this changes, the need to have build support
>> to replace it diminishes greatly.
>>
>> /Magnus
>>
>>
>>> Regards,
>>> Volker
>>>
>>>> /Magnus
>>>>
>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade <rajan.halade at oracle.com>
>>>>> wrote:
>>>>>> May I request for your review of this fix to open source the root
>>>>>> certificates in Oracle's Java SE Root CA program. The fix is to
>>>>>> populate
>>>>>> cacerts keystore with root certificates and add corresponding tests for
>>>>>> it
>>>>>> as per the test plan outlined at JDK-8191711. interoperability tests
>>>>>> are
>>>>>> added against CAs with available test certificates.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/
>>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486
>>>>>>
>>>>>> Thanks,
>>>>>> Rajan
>>>>>>