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
