Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

SSLParameters.java 649 applicationProtocols = protocols.clone(); You should clone the parameters before checking if they are valid. Move this to line 642, and check the validity of the cloned array. Also, use a temporary variable for the clone, so as not to pollute the

Re: Code Review Request, 8136442 Don't tie Certificate signature algorithms to ciphersuites

On 11/30/2015 11:13 AM, Xuelei Fan wrote: You should change the comment above the calls to setupPrivateKeyAndChain >as it still reflects the previous behavior. Oops, forgot the update the comment. Updated: http://cr.openjdk.java.net/~xuelei/8136442/webrev.01/ Looks good. >Also,

S4U2Self and OpenJDK 8

All, I'm trying to get Java's OpenJDK 8 support for s4u2self and s4u2proxy working. The client is openjdk 1.8.0_65 on both OSX El Capitan and CentOS 7. The server is RedHat's FreeIPA 4.1 using MIT kerberos krb5-server-1.12.2-14.el7.x86_64. I'm using the example from

Re: Code Review Request, 8136442 Don't tie Certificate signature algorithms to ciphersuites

On 11/30/2015 8:45 PM, Sean Mullan wrote: > You should change the comment above the calls to setupPrivateKeyAndChain > as it still reflects the previous behavior. Oops, forgot the update the comment. Updated: http://cr.openjdk.java.net/~xuelei/8136442/webrev.01/ > Also, should this change

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

On 11/29/2015 4:08 PM, Vincent Ryan wrote: > Following on from Brad’s recent email, here is the full webrev of the > API and the implementation classes for ALPN: > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ > > In adds the implementation classes (sun/security/ssl) to the public API >

Re: S4U2Self and OpenJDK 8

Thank Max. On OSX with the latest 1.9 I get the following: >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 83; type: 18 >>> KeyTabInputStream, readName(): RHELENT.LAN >>>

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

Thanks for your review. Comments in-line. > On 30 Nov 2015, at 06:30, Xuelei Fan wrote: > > Looks fine to me. Just a few minor comments. > > ServerHandshaker.java > = > There is a typo of the first line. > - /* Copyright (c) 1996, 2015, ... > + /* >

RFR 8144294: jdk/security/jarsigner/Function.java failed to clean up files after test on Windows

Please review the fix at http://cr.openjdk.java.net/~weijun/8144294/webrev.00/ A file was not closed. Thanks Max

Re: RFR 8144294: jdk/security/jarsigner/Function.java failed to clean up files after test on Windows

Looks fine to me. Xuelei On 12/1/2015 2:17 PM, Weijun Wang wrote: > Please review the fix at > >http://cr.openjdk.java.net/~weijun/8144294/webrev.00/ > > A file was not closed. > > Thanks > Max

RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ I have one question: What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" & working with <= JDK8) configured by

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

On 30/11/2015 11:13, Sibabrata Sahoo wrote: Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ I have one question: What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" &

Re: Handling SNI alerts in OpenJDK

Can I get the full exception stacks? Thanks, Xuelei On 11/17/2015 2:24 AM, Omair Majid wrote: > Hi, > > There's an issue with using SNI (Server Name Indication) with OpenJDK. > It will abort SSL/TLS connections to a server, when the server gives a > "unrecognized name" alert in the ssl

Re: Code Review Request, 8136442 Don't tie Certificate signature algorithms to ciphersuites

You should change the comment above the calls to setupPrivateKeyAndChain as it still reflects the previous behavior. Also, should this change only be applicable to TLS 1.2? --Sean On 11/29/2015 08:55 AM, Xuelei Fan wrote: Hi, Please review the fix for JDK-8136442:

Re: RFR 8144107: jdk/security tests not included

Looks good. --Sean On 11/26/2015 02:12 AM, Wang Weijun wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8144107/webrev.00/ The recent JarSigner API changeset includes some tests in jdk/security but the directory is not included in any test group. This fix adds it into

RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back? Thanks, Siba -Original Message- From: Alan Bateman Sent: Monday,