hg: jdk8/tl/jdk: 8016579: (process) IOException thrown by ProcessBuilder.start() method is incorrectly encoded
Changeset: e6aeeec33e53 Author:uta Date: 2013-07-19 12:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6aeeec33e53 8016579: (process) IOException thrown by ProcessBuilder.start() method is incorrectly encoded Reviewed-by: martin, dxu ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/lang/ProcessImpl_md.c
Re: [7u] 8020940: Valid OCSP responses are rejected for backdated enquiries
Looks good. --Sean On 07/19/2013 12:39 PM, Vincent Ryan wrote: Please review the following change to correct the handling of backdated OCSP requests: Bug: http://bugs.sun.com/view_bug.do?bug_id=8020940 [not yet visible] Webrev: http://cr.openjdk.java.net/~vinnie/8020940/webrev.00 It modifies the OCSP client to verify the validity interval for an OCSP response relative to the current time. Previously it was relative to the requested time. Thanks.
hg: jdk8/tl/jdk: 8020948: Fix doclint issues in misc package-info.java files
Changeset: e013b32118af Author:darcy Date: 2013-07-19 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e013b32118af 8020948: Fix doclint issues in misc package-info.java files Reviewed-by: dholmes, chegar ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/util/function/package-info.java
hg: jdk8/tl/langtools: 8017216: javac doesn't fill in end position for some errors of type not found; ...
Changeset: 0a9f5cbe37d9 Author:ksrini Date: 2013-07-19 07:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0a9f5cbe37d9 8017216: javac doesn't fill in end position for some errors of type not found 8019421: Javac doesn't fill in end position for some annotation related errors 8019422: Javac doesn't fill in end position for uninitialized variable errors Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/EndPosTable.java + test/tools/javac/diags/examples/VarNotIntializedInDefaultConstructor.java + test/tools/javac/positions/TreeEndPosTest.java
[7u] 8020940: Valid OCSP responses are rejected for backdated enquiries
Please review the following change to correct the handling of backdated OCSP requests: Bug: http://bugs.sun.com/view_bug.do?bug_id=8020940 [not yet visible] Webrev: http://cr.openjdk.java.net/~vinnie/8020940/webrev.00 It modifies the OCSP client to verify the validity interval for an OCSP response relative to the current time. Previously it was relative to the requested time. Thanks.
Re: code review request: 8012971 PKCS11Test hiding exception failures
It was necessary, but I found the unused variable that was triggering the compile error without it. Tony On 07/18/2013 03:40 PM, Valerie (Yu-Ching) Peng wrote: Just noticed that the newly-added import statement on line 32 seems redundant? Webrev seems the same? Thanks, Valerie On 07/18/13 15:17, Anthony Scarpino wrote: On 07/18/2013 02:49 PM, Valerie (Yu-Ching) Peng wrote: Please find comments inline. On 07/17/13 13:51, Anthony Scarpino wrote: I have broken these into two webrev. The first: JDK-8012971 PKCS11Test hiding exception failures http://cr.openjdk.java.net/~ascarpino/8012971/webrev.01/ handles the minimum changes needed for PKCS11Test to function and the Problemlist updated to reflect the failures that would show up. Looks fine in general, I only have some nit comments, and questions since I have not touched NSS much. PKCS11Test.java 1) line 88, change "this finally block" to "any finally block" yep 2) line 192, add space before and after the "+" for consistency with the rest of the source, e.g. line 213. yep 3) The comments from line 58-60 say the default value is "nss3" but the default value set on line 61 is "softokn3". Seems conflicting? yep. it nss3 use to be the default, must have forgot the change the comment 4) Is "nss3" only used for Secmod? It seems that everywhere else you use the "softokn3" value. If yes, perhaps using "setSecmod()" would be clearer than "useNSS()". Secmod is the only one currently, but I would rather leave it as NSS because I named it for the library it's looking for. If another test comes around that is not a Secmod test, then setSecmod() doesn't seem logical. webrev is updated in place. Will look at 8020424 later today. Thanks, Valerie The second, are the test changes that fix the problems uncovered by the above change: JDK-8020424 The NSS version should be detected before running crypto tests http://cr.openjdk.java.net/~ascarpino/8020424/webrev.00/ Tony
Re: [8] Code Review Request: 8010748: Add PKIXRevocationChecker NO_FALLBACK option and improve SOFT_FAIL option
Your changes look good. Thanks. On 16 Jul 2013, at 20:11, Sean Mullan wrote: > Please review my JDK 8 fix for 8010748: > > http://bugs.sun.com/view_bug.do?bug_id=8010748 > > This add a few useful API additions to JEP 124 (Enhance the Certificate > Revocation-Checking API) from experience with using the API. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8010748/webrev.00/ > > Thanks, > Sean >
Re: code review request: 8012971 PKCS11Test hiding exception failures
Oh, another thing, I noticed that for ProblemList.txt, line 261 is a duplicate of line 289. Otherwise, looks fine. BTW, I didn't get to finish reviewing your second fix today, may take a few more days to get that done... Thanks, Valerie On 07/19/13 11:19, Anthony Scarpino wrote: It was necessary, but I found the unused variable that was triggering the compile error without it. Tony On 07/18/2013 03:40 PM, Valerie (Yu-Ching) Peng wrote: Just noticed that the newly-added import statement on line 32 seems redundant? Webrev seems the same? Thanks, Valerie On 07/18/13 15:17, Anthony Scarpino wrote: On 07/18/2013 02:49 PM, Valerie (Yu-Ching) Peng wrote: Please find comments inline. On 07/17/13 13:51, Anthony Scarpino wrote: I have broken these into two webrev. The first: JDK-8012971 PKCS11Test hiding exception failures http://cr.openjdk.java.net/~ascarpino/8012971/webrev.01/ handles the minimum changes needed for PKCS11Test to function and the Problemlist updated to reflect the failures that would show up. Looks fine in general, I only have some nit comments, and questions since I have not touched NSS much. PKCS11Test.java 1) line 88, change "this finally block" to "any finally block" yep 2) line 192, add space before and after the "+" for consistency with the rest of the source, e.g. line 213. yep 3) The comments from line 58-60 say the default value is "nss3" but the default value set on line 61 is "softokn3". Seems conflicting? yep. it nss3 use to be the default, must have forgot the change the comment 4) Is "nss3" only used for Secmod? It seems that everywhere else you use the "softokn3" value. If yes, perhaps using "setSecmod()" would be clearer than "useNSS()". Secmod is the only one currently, but I would rather leave it as NSS because I named it for the library it's looking for. If another test comes around that is not a Secmod test, then setSecmod() doesn't seem logical. webrev is updated in place. Will look at 8020424 later today. Thanks, Valerie The second, are the test changes that fix the problems uncovered by the above change: JDK-8020424 The NSS version should be detected before running crypto tests http://cr.openjdk.java.net/~ascarpino/8020424/webrev.00/ Tony
Re: code review request: 8012971 PKCS11Test hiding exception failures
Both of them get removed in the next webrev. Tony On 07/19/2013 04:21 PM, Valerie (Yu-Ching) Peng wrote: Oh, another thing, I noticed that for ProblemList.txt, line 261 is a duplicate of line 289. Otherwise, looks fine. BTW, I didn't get to finish reviewing your second fix today, may take a few more days to get that done... Thanks, Valerie On 07/19/13 11:19, Anthony Scarpino wrote: It was necessary, but I found the unused variable that was triggering the compile error without it. Tony On 07/18/2013 03:40 PM, Valerie (Yu-Ching) Peng wrote: Just noticed that the newly-added import statement on line 32 seems redundant? Webrev seems the same? Thanks, Valerie On 07/18/13 15:17, Anthony Scarpino wrote: On 07/18/2013 02:49 PM, Valerie (Yu-Ching) Peng wrote: Please find comments inline. On 07/17/13 13:51, Anthony Scarpino wrote: I have broken these into two webrev. The first: JDK-8012971 PKCS11Test hiding exception failures http://cr.openjdk.java.net/~ascarpino/8012971/webrev.01/ handles the minimum changes needed for PKCS11Test to function and the Problemlist updated to reflect the failures that would show up. Looks fine in general, I only have some nit comments, and questions since I have not touched NSS much. PKCS11Test.java 1) line 88, change "this finally block" to "any finally block" yep 2) line 192, add space before and after the "+" for consistency with the rest of the source, e.g. line 213. yep 3) The comments from line 58-60 say the default value is "nss3" but the default value set on line 61 is "softokn3". Seems conflicting? yep. it nss3 use to be the default, must have forgot the change the comment 4) Is "nss3" only used for Secmod? It seems that everywhere else you use the "softokn3" value. If yes, perhaps using "setSecmod()" would be clearer than "useNSS()". Secmod is the only one currently, but I would rather leave it as NSS because I named it for the library it's looking for. If another test comes around that is not a Secmod test, then setSecmod() doesn't seem logical. webrev is updated in place. Will look at 8020424 later today. Thanks, Valerie The second, are the test changes that fix the problems uncovered by the above change: JDK-8020424 The NSS version should be detected before running crypto tests http://cr.openjdk.java.net/~ascarpino/8020424/webrev.00/ Tony
Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails
On Sun, Jul 14, 2013 at 10:58 PM, Weijun Wang wrote:
> Without the ability to send a token when there is a failure, a Java program
> has no chance to tell the other side what's happening. This is very
> user-unfriendly. Also, in the case of SPNEGO, a "reject" NegTokenResp token
> will never be able to sent out.
I agree.
> My current proposal is to add a new method getOutputToken() to the
> GSSException class (which will be thrown when an error occurs) to return
> this last token. This means the method calls will be something like
>
> try {
> send(initSecContext(inToken));
> } catch (GSSException e) {
> if (e.getOutputToken() != null) {
> send(e.getOutputToken());
> }
> throw e;
> }
>
> The getOutputToken() method can only return a non-null value when it's
> thrown by an initSecContext or acceptSecContext call. The method won't throw
> another GSSException even if the exception was thrown in other calls.
I support this.
> We can use the new JDK 8 default method feature [1] to add this new method
> to the existing GSSException interface.
Excellent,
Nico
--
Re: TLS and Pre-shared Keys
It is not supported at present. Will consider it in the future. Xuelei On 7/18/2013 3:52 AM, Matthew Hall wrote: > On Wed, Jul 17, 2013 at 03:45:19PM -0400, roger riggs wrote: >> Hi, >> >> Is there support in SSLEngine/TLS to support Pre-Shared Keys? >> I have been looking for relevant doc and have not stumbled upon it. >> >> Thanks, Roger > > No, there isn't any support for PSK Ciphers yet, although some of the > constants for them appear in grep output. > > It would be really nice if it were supported for deploying new cluster nodes > in distributed systems, etc. > > Matthew. >
