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

[John Gray]

Thanks for looking at this issue.  

I had suggested the simple fix as a way to remove the NPE during initialization, but if you think there are other places where this circular logic could crop up again (or could be easily introduced in the future) then I would agree an alternate fix could be better.   Just as long as it isn't too complicated and doesn't break anything else...  😊

Cheers,

John Gray
Entrust Datacard 

-----Original Message-----
From: security-dev <security-dev-retn at openjdk.java.net> On Behalf Of Valerie Peng
Sent: Wednesday, August 19, 2020 1:46 PM
To: Sean Mullan <sean.mullan at oracle.com>; Xuelei Fan <xuelei.fan at oracle.com>; OpenJDK Dev list <security-dev at openjdk.java.net>
Subject: [EXTERNAL]Re: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

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