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
