Yes, thanks for the suggested fix. It's a good starting point. :)
Regards,
Valerie
On 8/20/2020 6:18 AM, John Gray wrote:
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 <[email protected]> On Behalf Of Valerie
Peng
Sent: Wednesday, August 19, 2020 1:46 PM
To: Sean Mullan <[email protected]>; Xuelei Fan <[email protected]>; OpenJDK
Dev list <[email protected]>
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
