Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 27, 2016, at 3:27 AM, Bradford Wetmore > wrote: > > > > On 4/25/2016 11:25 PM, Wang Weijun wrote: >> >>> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore >>> wrote: >>> >>> but the runtime "Health Testing" I was talking

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Deleting the cruft that doesn't need further discussion. On 4/24/2016 9:13 PM, Wang Weijun wrote: http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff Thanks for the

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

On 04/26/2016 12:27 PM, Bradford Wetmore wrote: On 4/25/2016 11:25 PM, Wang Weijun wrote: On Apr 26, 2016, at 8:48 AM, Bradford Wetmore wrote: but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3: I

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

On 4/25/2016 11:25 PM, Wang Weijun wrote: On Apr 26, 2016, at 8:48 AM, Bradford Wetmore wrote: but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3: I haven't touched this area yet. If you think

[8u-dev] Request for Review and Approval to backport: 8133070: Hot lock on BulkCipher.isAvailable

Thank you Jianhao Mo for contributing the patch for the backport! I see Alibaba Group Holding Limited on the OCA Signatories List: http://www.oracle.com/technetwork/community/oca-486395.html so looks like we can accept your patch. I'm sending this as a formal request for review, as the patch

Re: RFR(XXS): 8155036: Remove sun.security.action.GetBooleanSecurityPropertyAction

On 04/25/2016 12:47 PM, Claes Redestad wrote: Hi, since JEP-260 encapsulates internal APIs, we could remove unused classes like this one hg rm ./src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java The removal of this class is ok with me. There also doesn't

Re: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them

jdk.tls.handleCertReqAuthoritesOverflow is a little bit long. jdk.tls.server.overFlowAuthorites? May not need to define the "none" property value. Using enum for HAO_NONE, HAO_EMPTY and HAO_TRUNC? line 1920: Overflow should be rare, what about print only when overflow? Xuelei On 4/26/2016

Re: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them

Looks like a fair approach to solving this issue Ivan. A few comments from me : typo : authoririesOverflow --> authoritiesOverflow typo : handleAuthoritesOverflow --> handleAuthoritiesOverflow typo : jdk.tls.handleCertReqAuthoritesOverflow --> jdk.tls.handleCertReqAuthoritiesOverflow +

Re: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them

Here's a modified version of the fix. Instead of a boolean-type property, a string-type property is introduced. It is used to specify the strategy to use, if we encounter the overflow during filling the list of authorities. The default strategy is to throw an exception (just like the

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore > wrote: > > but the runtime "Health Testing" I was talking about is in the diagram of > Section 7, and details in section 11.3: I haven't touched this area yet. If you think it's necessary, I would like to add the