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

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: S4U2Self and OpenJDK 8

It is my understanding that if the S4U2self ticket is not forwardable then it cannot be used in a S4U2proxy request. That's we just threw an exception. Am I wrong? Or you don't intend to use it this way? --Max

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 >>> Key

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

Looks fine to me. Thanks for the update. Xuelei On 12/1/2015 7:08 AM, Vincent Ryan wrote: > 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 >> = >> The

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

Hi Marc Looks like the problem is below: >> KrbKdcRep.check: at #1. request for true, received false We've already fixed this in jdk9 at https://bugs.openjdk.java.net/browse/JDK-8022582 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ae6449bc523f you can see the check now starts at #2. Can yo

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

Thanks for the review. I’ve incorporated your comments and Xuelei’s comments in a revised webrev: http://cr.openjdk.java.net/~vinnie/8144093/webrev.01/ > On 30 Nov 2015, at 21:10, Sean Mullan wrote: > > SSLParameters.java > > 649

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, ... > + /* > + * Copyright (c) 1996,

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 applicationProt

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, should

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 only

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 https://github.com/ymartin59

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, N

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: 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: http://cr.openjdk.java

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/*" & wor

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 "java.securi

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 handshake