Re: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider

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

Re: [EXTERNAL]Re: SecureRandom regression with certain security providers

Hi John, Unfortunately this cannot wait til July 13th if this issue needs to be fixed for jdk 15. Maybe you can try the webrev out or share more details on how Entrust provider does its registration and what Provider APIs it overrides. I need more info to help identifying the trigger for

Re: [EXTERNAL]Re: SecureRandom regression with certain security providers

Hmm, there must be something else which Entrust provider does besides the usual sequence of put(String, String) calls? The regression test DefaultAlgo.java covers both the cases of pure legacy, i.e. put(String, String) calls, and pure service providers, i.e. putService(...) calls. Is there

RE: [EXTERNAL]Re: SecureRandom regression with certain security providers

Thanks for the quick reply! We don't override the putService() or getService() calls in our Entrust provider. Our provider has been around for a very long time (since JDK 1.2 days). We use the key value mapping via put(): For example, your newer code must pick it up by looking at this

RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider

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

Re: [EXTERNAL]Re: SecureRandom regression with certain security providers

Hi John, Thanks for the feedback, it certainly helps to know which providers are affected to help us give this the right priority and the right fix. So, does Entrust provider also override Provider.putService()/getService() calls like BCFIPS provider does? I am about to send out the webrev

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

On 6/24/20 2:56 PM, Daniel Fuchs wrote: The JNDI/LDAP part looks mostly good. You will need someone from the security libs to review the security lib part of the changes. I have previously reviewed it but I would like to give it another once over. Max should also review the final version as

RE: [EXTERNAL]Re: SecureRandom regression with certain security providers

Hi Valerie, I noticed this looked related to the Secure Random issue (https://bugs.openjdk.java.net/browse/JDK-8246383) and I noticed you had ported back the work-around you mentioned to me a few weeks ago. So I thought I would give it a try with the 11.08 pre-release since you had listed it

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

Hi Sean, I think the changes look good including the proposed tweaks to the message suggested by Alan. Best Lance > On Jul 2, 2020, at 4:10 AM, Seán Coffey wrote: > > Thanks for the review Alan. I'm in contact with Max already about possible > follow up enhancements in this area. It would

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

Thanks for the review Alan. I'm in contact with Max already about possible follow up enhancements in this area. It would be worked via a follow on JBS record. Regarding the error message, I'm fine with your suggestion. We can go with this then: "POSIX file permission attributes detected.

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

On 30/06/2020 14:51, Seán Coffey wrote: : During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected). Yes, signing should be additive so the

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

Thanks for the review Max. All edits made bar the "Event.clearReportListener(Event.ReporterCategory.POSIXPERMS);" suggested edit. That's already in a finally block. latest webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v5/webrev/ I plan to push once I have a clean test run.