RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider
Valerie Peng
valerie.peng at oracle.com
Mon Jul 6 23:49:30 UTC 2020
Updated the webrev to webrev.01
http://cr.openjdk.java.net/~valeriep/8248505/webrev.01/
No changes to source, just test cleanup.
Thanks,
Valerie
On 7/6/2020 12:51 PM, Valerie Peng wrote:
> Thanks for taking a look, Sean.
>
> Agree that we need to get to the root cause for the NSAE which
> John at Entrust also observed. One possibility is to file another bug for
> Entrust NSAE and deliver more fix later if this current fix for BCFIPS
> provider does not resolve Entrust's NSAE.
>
> Valerie
>
> On 7/6/2020 12:20 PM, Seán Coffey wrote:
>> Your patch looks ok to me Valerie. I note that John mentions an
>> anomaly with your patch - I'm thinking that may need further
>> investigation.
>>
>> regards,
>> Sean.
>>
>> On 06/07/2020 17:33, Valerie Peng wrote:
>>> Hi Max,
>>>
>>> The suggested fix is not much different than the suggested webrev.
>>>
>>> The essential change is to call getService(...) for the returned
>>> service in Provider.getDefaultSecureRandomService(). The only
>>> difference here is using the hardcoded type "SecureRandom" vs the
>>> one returned by getType() call. Is this what you are referring to?
>>>
>>> I re-write the rest to store String instead of Service as it may
>>> seem strange why the stored Service is not used but re-queried
>>> through getService(...). Also, looks cleaner to me this way.
>>>
>>> Thanks,
>>> Valerie
>>> On 7/2/2020 9:05 PM, Weijun Wang wrote:
>>>> Hi Valerie,
>>>>
>>>> How about the suggested fix from the bug reporter?
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>> On Jul 3, 2020, at 4:52 AM, Valerie Peng <valerie.peng at oracle.com>
>>>>> wrote:
>>>>>
>>>>> Hi Max and Sean,
>>>>>
>>>>> Can you help reviewing this fix for JDK-8248505? This is the
>>>>> followup fix for JDK-8246613 "Choose the default SecureRandom algo
>>>>> based on registration ordering" which you reviewed earlier. Based
>>>>> on the feedback, BCFIPS provider overrides putService/getService()
>>>>> calls which does not work well with the fix for JDK-8246613. Thus,
>>>>> I adapted to store the SecureRandom algorithm names internally and
>>>>> then return the result from getService(...) when
>>>>> Provider.getDefaultSecureRandomService() is called. Updated the
>>>>> regression test to include a custom provider which simulates the
>>>>> BCFIPS provider behavior.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Valerie
>>>>>
>>>>>
More information about the security-dev
mailing list