[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