Thanks!
Valerie
On 7/7/2020 9:00 AM, Weijun Wang wrote:
I see. No more comment.
--Max
On Jul 7, 2020, at 11:53 PM, Valerie Peng wrote:
Hi Max,
Thanks for your review.
Algorithm is also there, so both work technically. With existing APIs, the only
way to check for service registration is
I see. No more comment.
--Max
> On Jul 7, 2020, at 11:53 PM, Valerie Peng wrote:
>
> Hi Max,
>
> Thanks for your review.
>
> Algorithm is also there, so both work technically. With existing APIs, the
> only way to check for service registration is to call getService(...) and
> check for ==.
Hi Max,
Thanks for your review.
Algorithm is also there, so both work technically. With existing APIs,
the only way to check for service registration is to call
getService(...) and check for ==. If there were another way to check
service registration, then it makes sense to store Service obje
> On Jul 7, 2020, at 12:33 AM, Valerie Peng wrote:
>
> Hi Max,
>
> The suggested fix is not much different than the suggested webrev.
I understand they are mostly the same.
>
> The essential change is to call getService(...) for the returned service in
> Provider.getDefaultSecureRandomSer
Updated the webrev to webrev.01
http://cr.openjdk.java.net/~valeriep/8248505/webrev.01/
No changes to source, just test cleanup.
Thanks,
Valerie
On 7/6/2020 12:51 PM, Valerie Peng wrote:
Thanks for taking a look, Sean.
Agree that we need to get to the root cause for the NSAE which
John@Entru
Thanks for taking a look, Sean.
Agree that we need to get to the root cause for the NSAE which
John@Entrust also observed. One possibility is to file another bug for
Entrust NSAE and deliver more fix later if this current fix for BCFIPS
provider does not resolve Entrust's NSAE.
Valerie
On 7
Your patch looks ok to me Valerie. I note that John mentions an anomaly
with your patch - I'm thinking that may need further investigation.
regards,
Sean.
On 06/07/2020 17:33, Valerie Peng wrote:
Hi Max,
The suggested fix is not much different than the suggested webrev.
The essential change
Hi Max,
The suggested fix is not much different than the suggested webrev.
The essential change is to call getService(...) for the returned service
in Provider.getDefaultSecureRandomService(). The only difference here is
using the hardcoded type "SecureRandom" vs the one returned by getType()
Hi Valerie,
How about the suggested fix from the bug reporter?
Thanks,
Max
> On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote:
>
> Hi Max and Sean,
>
> Can you help reviewing this fix for JDK-8248505? This is the followup fix for
> JDK-8246613 "Choose the default SecureRandom algo based on reg
Hi Max and Sean,
Can you help reviewing this fix for JDK-8248505? This is the followup
fix for JDK-8246613 "Choose the default SecureRandom algo based on
registration ordering" which you reviewed earlier. Based on the
feedback, BCFIPS provider overrides putService/getService() calls which
doe
10 matches
Mail list logo