[14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic"

Valerie Peng valerie.peng at oracle.com
Tue Aug 13 01:02:19 UTC 2019


Webrev updated to use a static constant in SunEntries:

http://cr.openjdk.java.net/~valeriep/8228613/webrev.01/

Thanks~
Valerie
On 8/12/2019 4:22 PM, Valerie Peng wrote:
>
> Sure, I considered the internal approach as well, but feel an alias of 
> DEFAULT seems cleaner than a static constant in SunEntries class. I 
> can go the other way if you prefer.
>
> The spec didn't spell clearly as to how the default random number 
> algorithm is determined and I think it can be provider-specific. This 
> is a regression and we need to backport this. Hope that a new 
> concept/CSR won't shut the door for backport?
>
> Valerie
>
>
> On 8/10/2019 7:32 PM, Weijun Wang wrote:
>> The spec for SecureRandom has:
>>
>> /**
>>   * Constructs a secure random number generator (RNG) implementing the
>>   * default random number algorithm.
>>   *
>>   * ....
>>   */
>> public SecureRandom() {
>>
>> What does "the default random number algorithm" mean?
>>
>> I suggest we invent some new concepts in a CSR first.
>>
>> Or, if we simply want to keep the expected behavior, I feel a little 
>> uncomfortable to make the "DEFAULT" alias visible to the public. Can 
>> we make all these logic internal? Maybe like this?
>>
>> +            if (p.getName().equals("SUN")) {
>> +                return SunEntries.DEFAULT; // and assign DEFAULT 
>> somewhere in SunEntries
>> +            }
>>
>>
>> --Max
>>
>>> On Aug 7, 2019, at 8:59 AM, Valerie Peng <valerie.peng at oracle.com> 
>>> wrote:
>>>
>>>
>>> Anyone can help review this fix? SUN provider supports multiple 
>>> impls of SecureRandom and rely on the ordering of the set returned 
>>> by Provider.getServices() to choose the most preferred RNG algo for 
>>> new SecureRandom() calls. Instead of maintaining the ordering, I 
>>> think it's faster and more robust to use an alias "DEFAULT" to 
>>> indicate the most preferred RNG algo for SUN provider.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228613
>>>
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/
>>>
>>> Thanks,
>>> Valerie



More information about the security-dev mailing list