[13] RFR JDK-8220016 "Clean up redundant RSA services in the SunJSSE provider"
Sean Mullan
sean.mullan at oracle.com
Wed Mar 13 15:00:47 UTC 2019
There should also be a release note issue filed for this change.
--Sean
On 3/12/19 11:18 PM, Xuelei Fan wrote:
> On 3/12/2019 7:57 PM, Valerie Peng wrote:
>> Please review the CSR at:
>> https://bugs.openjdk.java.net/browse/JDK-8220549
>>
> I added myself as reviewer.
>
>> Webrev updated in place for this new approach:
>> http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>
> It looks fine to me.
>
> Xuelei
>
>> I changed the synopsis to clarify that we are now removing these
>> duplicated RSA support.
>>
>> Thanks,
>>
>> Valerie
>>
>>
>> On 3/11/2019 3:59 PM, Valerie Peng wrote:
>>> Thanks for the info, I'd prefer to completely remove the SunRsaSign
>>> entries from SunJSSE provider as well.
>>>
>>> I will update the webrev and file a CSR then.
>>>
>>> Thanks,
>>>
>>> Valerie
>>>
>>>
>>> On 3/7/2019 7:30 PM, Xuelei Fan wrote:
>>>> On 3/7/2019 6:15 PM, Valerie Peng wrote:
>>>>> Do you mean removing the part about SunRsaSignEntries completely?
>>>>> Or only remove the MD2/MD5withRSA signature algorithms?
>>>>>
>>>> I meant to remove the SunRsaSignEntries completely from the SunJSSE
>>>> provider.
>>>>
>>>>> Do you know the history of including them in the first place? Since
>>>>> SunRsaSign provider has been in early JDK releases, I wonder why
>>>>> SunJSSE provider duplicated these RSA algorithms in the first place?
>>>> The JSSE provider was originally provided as an standalone library,
>>>> and using the com.sun.net.ssl packet. I think it was in JDK 1.4,
>>>> the package became part of JDK, and start to using the javax.net.ssl
>>>> package and the standard JCE providers. However, for compatibility,
>>>> the old supported signature algorithms are still linked in the
>>>> SunJSSE provider.
>>>>
>>>> In the JDK 9, a noted was added in the SunJSSE provider documentation:
>>>> The SunJSSE provider is for backwards compatibility with
>>>> older releases, and should no longer be used for Signature.
>>>>
>>>> The compatibility is mainly about coding with explicitly SunJSSE
>>>> provider name. For example,
>>>> Signature.getInstance("SHA1withRSA",
>>>> "com.sun.net.ssl.internal.ssl.Provider");
>>>>
>>>> The use may not be common in practice. And the JDK JCE providers
>>>> support these algorithms, I was wondering the risk of removing them
>>>> from the SunJSSE provider may be low now.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>> I can file a CSR, knowing the history/reason would help.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Valerie
>>>>>
>>>>>
>>>>> On 3/7/2019 5:45 PM, Xuelei Fan wrote:
>>>>>> Hi Valerie,
>>>>>>
>>>>>> As you are already there, I may suggest to remove the old RSA
>>>>>> crypto algorithms in the SunJSSE providers as well. As may
>>>>>> simplify the code a little bit, though a CSR is needed for the
>>>>>> SunJSSE behavior change.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 3/7/2019 4:56 PM, Valerie Peng wrote:
>>>>>>> Hi Brad,
>>>>>>>
>>>>>>> Do you have time to help review the changes for JDK-8220016?
>>>>>>> Current changes are to register the same list of RSA-related
>>>>>>> services as these prior to the fix for JDK-7092821. I am not sure
>>>>>>> what are the old RSA impls for pre-JDK1.4 implementations.
>>>>>>> Otherwise, I can remove them as well. Please let me know.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Valerie
More information about the security-dev
mailing list