Thanks for taking a look, Sean.
Agree that we need to get to the root cause for the NSAE which
John@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.p...@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
