[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