[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-security-dev
Subject:    Re: [EXTERNAL]Re: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult wh
From:       Valerie Peng <valerie.peng () oracle ! com>
Date:       2020-08-20 17:05:56
Message-ID: b15ad414-bfdf-ca69-dab5-9573b2996644 () oracle ! com
[Download RAW message or body]

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 <security-dev-retn@openjdk.java.net> On Behalf Of Valerie Peng
> Sent: Wednesday, August 19, 2020 1:46 PM
> To: Sean Mullan <sean.mullan@oracle.com>; Xuelei Fan <xuelei.fan@oracle.com>; \
>                 OpenJDK Dev list <security-dev@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


[prev in list] [next in list] [prev in thread] [next in thread]