[16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider

Valerie Peng valerie.peng at oracle.com
Wed Aug 19 17:46:13 UTC 2020


I don't feel it's the right fix, but rather just a workaround...

A better workaround would be to switch to "JCAUtil.getSecureRandom()" 
instead of JceSecurity.RANDOM. ;)

Valerie

On 8/19/2020 5:47 AM, Sean Mullan wrote:
> In the bug report, the following fix was suggested:
>
> "The fix to the issue should be simple, just move the initialization 
> of the verificationResults Map BEFORE the SecureRandom initialization 
> in JceSecurity.java"
>
> Does that not work for some reason?
>
> --Sean
>
> On 8/19/20 1:13 AM, Xuelei Fan wrote:
>> On 8/18/2020 2:43 PM, Valerie Peng wrote:
>>>
>>> Using a shared instance is surely faster. However, the API specified 
>>> that the most preferred SecureRandom impl will be used. To ensure 
>>> this for all scenarios, creating default SecureRandom obj will 
>>> provide correct result but shared instance may not.
>> I understand your point.  It might not break the spec if a shared 
>> instance is used.  It depends on the understanding of "most preferred 
>> SecureRandom impl" in the context.
>>
>>
>>> Apps can call other init functions which takes SecureRandom objects 
>>> to avoid this default SecureRandom obj creation if needed.
>>>
>> Yes, it's an alternative solution.  If an application used the 
>> default SecureRandom, it would be nice if there is no performance 
>> regression.
>>
>> The SecureRandom initialization may be not cheap in some 
>> circumstances. As this bug did not complain about the use of shared 
>> instance, it may be fine if we want to avoid the performance impact 
>> if the impact exists.
>>
>> Just for your consideration.
>>
>> Xuelei
>>
>>> Valerie
>>>
>>> On 8/18/2020 2:10 PM, Xuelei Fan wrote:
>>>> Is there any performance impact?
>>>>
>>>> Xuelei
>>>>
>>>> On 8/18/2020 12:51 PM, Valerie Peng wrote:
>>>>>
>>>>> Anyone has cycles to review this somewhat trivial changes? 
>>>>> JceSecurity has this shared SecureRandom instance which may lead 
>>>>> to NPE when certain 3rd party JCE provider is set as most 
>>>>> preferred. Removing this shared instance and change to create 
>>>>> default SecureRandom obj when needed.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Valerie



More information about the security-dev mailing list