From sgehwolf at redhat.com Fri Mar 1 02:30:28 2013 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 01 Mar 2013 11:30:28 +0100 Subject: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library Message-ID: <1362133828.2303.18.camel@localhost> Hi, The bug for this review request is at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142 In PlatformPCSC.java unversioned native libraries are loaded by default if no system property is specified. This could lead to a JVM crash if the API of the native library changes, but the Java code still relies on old API. The fix is to load versioned shared libraries instead. See also: https://bugzilla.redhat.com/show_bug.cgi?id=910107 The webrev is here: http://jerboaa.fedorapeople.org/bugs/openjdk/9000142/webrev.0/ Thanks, Severin From xuelei.fan at oracle.com Fri Mar 1 02:35:40 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 01 Mar 2013 10:35:40 +0000 Subject: hg: jdk8/tl/jdk: 7030966: Support AEAD CipherSuites Message-ID: <20130301103619.27EE547512@hg.openjdk.java.net> Changeset: def2e05299b7 Author: xuelei Date: 2013-03-01 02:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/def2e05299b7 7030966: Support AEAD CipherSuites Reviewed-by: weijun, wetmore, valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java + src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java From sean.mullan at oracle.com Fri Mar 1 04:52:58 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 01 Mar 2013 07:52:58 -0500 Subject: [8] Code Review Request for 8008908: Access denied when invoking Subject.doAsPrivileged() Message-ID: <5130A4AA.5080007@oracle.com> Please review this simple fix for parsing wildcard principal names in policy files which is a regression caused by 7019834 [1]. bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008908 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8008908/webrev.00/ Thanks, Sean [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7019834 From xuelei.fan at oracle.com Fri Mar 1 05:19:52 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 01 Mar 2013 21:19:52 +0800 Subject: [8] Code Review Request for 8008908: Access denied when invoking Subject.doAsPrivileged() In-Reply-To: <5130A4AA.5080007@oracle.com> References: <5130A4AA.5080007@oracle.com> Message-ID: <5130AAF8.7050905@oracle.com> I did not look back to 7019834. This fix looks fine to me. Xuelei On 3/1/2013 8:52 PM, Sean Mullan wrote: > Please review this simple fix for parsing wildcard principal names in > policy files which is a regression caused by 7019834 [1]. > > bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008908 > > webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8008908/webrev.00/ > > Thanks, > Sean > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7019834 From jonathan.gibbons at oracle.com Fri Mar 1 11:35:15 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Mar 2013 19:35:15 +0000 Subject: hg: jdk8/tl/langtools: 8008949: javadoc stopped copying doc-files Message-ID: <20130301193521.0B3404752A@hg.openjdk.java.net> Changeset: 6f988040a1c8 Author: jjg Date: 2013-03-01 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f988040a1c8 8008949: javadoc stopped copying doc-files Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/com/sun/javadoc/testDocFiles/TestDocFiles.java + test/com/sun/javadoc/testDocFiles/pkg/Test.java + test/com/sun/javadoc/testDocFiles/pkg/doc-files/test.txt From sean.mullan at oracle.com Fri Mar 1 13:26:11 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 01 Mar 2013 21:26:11 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130301212643.176DB477C3@hg.openjdk.java.net> Changeset: 1652ac7b4bfd Author: mullan Date: 2013-03-01 16:12 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1652ac7b4bfd 8008908: Access denied when invoking Subject.doAsPrivileged() Summary: wildcard principal names are not processed correctly Reviewed-by: xuelei ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/WildcardPrincipalName.java + test/sun/security/provider/PolicyFile/wildcard.policy Changeset: 1ca712765acb Author: mullan Date: 2013-03-01 16:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ca712765acb Merge From dan.xu at oracle.com Fri Mar 1 14:30:57 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 01 Mar 2013 22:30:57 +0000 Subject: hg: jdk8/tl/jdk: 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Message-ID: <20130301223119.D494B477C9@hg.openjdk.java.net> Changeset: 30e30ef6077e Author: dxu Date: 2013-03-01 14:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30e30ef6077e 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Summary: Fix test failures and update java doc of Files.move Reviewed-by: alanb, chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/CopyAndMove.java From chris.hegarty at oracle.com Sat Mar 2 00:56:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 02 Mar 2013 08:56:36 +0000 Subject: hg: jdk8/tl/jdk: 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Message-ID: <20130302085658.C3B57477DA@hg.openjdk.java.net> Changeset: f08ad5938709 Author: chegar Date: 2013-03-02 08:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f08ad5938709 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Reviewed-by: chegar Contributed-by: Doug Lea
Greetings:
I posted a new webrev image in response to the most recent round of comments:
http://cr.openjdk.java.net/~jzavgren/8007607/webrev.07/
Thanks!
John
On 02/19/2013 12:16 PM, Chris Hegarty wrote:
Hi John,
Functionally this looks fine. Most my comments are nit picking, and style.
src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
My fault, I think I suggested you return NULL, but since these
methods return jlong they cannot (without generating warnings).
It would be better to:
< 332 return NULL;
---
> 332 return jlong_zero;
1167 return NULL; [same comment, return jlong_zero]
The indentation looks a little too much in a few places, e.g.
331 if ((*env)->ExceptionCheck(env)) {
332 ______return NULL;
333 }
src/share/native/sun/security/jgss/wrapper/NativeUtil.c
620 cOid = malloc(sizeof(struct gss_OID_desc_struct));
621 if_(cOid == NULL) { [add a space after if]
622 ____throwOutOfMemoryError(env,NULL); [I would suggest 2 spaces]
623 return GSS_C_NO_OID;
624 }
625 cOid->length = (*env)->GetArrayLength(env, jbytes) - 2;
626 cOid->elements = malloc(cOid->length);
627 if(cOid->elements == NULL) { [ same as above ]
628 throwOutOfMemoryError(env,NULL);
629 free(cOid);
630 return GSS_C_NO_OID;
631 }
src/share/native/sun/security/smartcardio/pcsc.c
src/solaris/native/sun/security/smartcardio/pcsc_md.c
It is kinda weird to have #ifdef WIN32 for these. It really seems
that these functions should be moved up to the shared pcsc.c
and externed from platform specific code, or an addition of
pcsc.h that declares the definitions.
src/solaris/native/com/sun/security/auth/module/Solaris.c
The comment is strange
34 /*
35 * ** Throws a Java Exception by name
36 * **/
src/solaris/native/com/sun/security/auth/module/Unix.c
Strange comment ( as above ). Also, why is there a need to for
#ifndef __solaris__ ??
-Chris.
On 02/18/2013 04:09 PM, John Zavgren wrote:
Greetings:
I posted a new webrev image.
http://cr.openjdk.java.net/~jzavgren/8007607/webrev.04/
<http://cr.openjdk.java.net/%7Ejzavgren/8007607/webrev.04/>
The code now throws an OOM exception when *alloc() fails, and the
callers of procedures that call procedures that throw it, check for it.
John
On 02/12/2013 11:03 AM, Dmitry Samersoff wrote:
John,
Changing everything for throw OOM is the right goal but it's a huge work
to do - it's meaningless to throw OOM if all callers doesn't check for
exception.
I'm in doubt it could be done all at once and probably this problem
should go to the huge TODO pile.
So I'm speaking about *one particular case*, where returned value could
lead to misinterpretation of security context and lead to security
vulnerability or subtle bug.
We have to throw OOM there and change all callers as well for this case.
-Dmitry
On 2013-02-12 19:51, John Zavgren wrote:
On 02/08/2013 01:34 PM, Dmitry Samersoff wrote:
John,When I change the procedures in the following files:
Ideas?It's a JNI so just throw OOM.
-Dmitry
On 2013-02-08 21:38, John Zavgren wrote:
Although I agree that the name: "GSS_C_NO_CHANNEL_BINDINGS" is
misleading,
I can't identify anything else that seems more appropriate.
The header file:
/jdk8-tl/jdk/src/share/native/sun/security/jgss/wrapper/gssapi.h defines
GSS_C_NO_CHANNEL_BINDINGS as follows:
#define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
The symbol matches the prototype of the function:
*/*
* Utility routine which creates a gss_channel_bindings_t structure
* using the specified org.ietf.jgss.ChannelBinding object.
*/
gss_channel_bindings_t getGSSCB(JNIEnv *env, jobject jcb) {
gss_channel_bindings_t cb;
jobject jinetAddr;
jbyteArray value;
if (jcb == NULL) {
return GSS_C_NO_CHANNEL_BINDINGS;
}
cb = malloc(sizeof(struct gss_channel_bindings_struct));
if(cb == NULL)
return GSS_C_NO_CHANNEL_BINDINGS;*
There doesn't appear to be anything in our set of options that is more
suggestive of a memory allocation failure and the symbol:
GSS_C_NO_CHANNEL_BINDINGS seems to be logically correct.
Ideas?
On 02/06/2013 04:57 AM, Dmitry Samersoff wrote:
John,--
Not sure GSS_C_NO_CHANNEL_BINDINGS; is correct return value for this
case.
I'm second to Valerie - it's better to throw OOM
-Dmitry
On 2013-02-06 03:44, John Zavgren wrote:
Greetings:
I modified the native code to eliminate potential memory loss and
crashes by checking the return values of malloc() and realloc() calls.
The webrev image of these changes is visible at:
http://cr.openjdk.java.net/~jzavgren/8007607/webrev.01/
Thanks!
John Zavgren
John Zavgren
john.zavgren at oracle.com
603-821-0904
US-Burlington-MA
src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
src/share/native/sun/security/jgss/wrapper/NativeUtil.c
src/share/native/sun/security/smartcardio/pcsc.c
src/solaris/native/com/sun/security/auth/module/Solaris.c
src/solaris/native/com/sun/security/auth/module/Unix.c
to fix inappropriate usages of malloc, realloc, etc. (e.g., not checking
the return value and referring to a NULL pointer and crashing) should I
modify every instance so that an OOM (Out Of Memory) exception is thrown
(before returning) whenever memory allocation fails?
The exceptions would be thrown by a line of code that looks like:
throwOutOfMemoryError(JNIEnv *env, const char *msg);
where throwOutOfMemoryError(...) wraps something like this:
jclass cls = (*env)->FindClass(env, name);
if (cls != 0) /* Otherwise an exception has already been
thrown */
(*env)->ThrowNew(env, cls, msg);
If this is the right idea, what messages should I pass when an OOM
exception is thrown?
Thanks!
John
--
John Zavgren
john.zavgren at oracle.com
603-821-0904
US-Burlington-MA
-- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA
tags as empty Message-ID: <20130320021726.56BFA4827E@hg.openjdk.java.net> Changeset: 74d7f9bcac93 Author: jjg Date: 2013-03-19 19:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/74d7f9bcac93 8010317: DocLint incorrectly reports sometags as empty Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/EmptyPreTest.java From sean.mullan at oracle.com Wed Mar 20 07:18:12 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 Mar 2013 10:18:12 -0400 Subject: [8] Code Review Request for 8010112: NullPointerException in sun.security.provider.certpath.CertId() Message-ID: <5149C524.1040504@oracle.com> Please review this fix for a NullPointerException when checking revocation status of certificates: webrev: http://cr.openjdk.java.net/~mullan/webrevs/8010112/webrev.00/ The bug is not available online for some reason, so here are the relevant details: There were 2 issues that needed to be fixed: 1. CertId did not handle the case where a TrustAnchor was specified as a name/key pair. Added a new constructor to allow for that. 2. DistributionPointFetcher.verifyCRL was not comparing Authority Key Ids correctly. It was comparing the bytes of the entire extension value, instead of just the KeyIdentifier field. It turns out that there are some AKID extensions that have matching key ids but also may include additional information in the other fields, causing the previous comparison to fail even though the key identifiers match. noreg-hard because the bug requires a complex setup to reproduce. Thanks, Sean From vincent.x.ryan at oracle.com Wed Mar 20 07:43:45 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 20 Mar 2013 14:43:45 +0000 Subject: [8] Code Review Request for 8010112: NullPointerException in sun.security.provider.certpath.CertId() In-Reply-To: <5149C524.1040504@oracle.com> References: <5149C524.1040504@oracle.com> Message-ID: <118075E6-3D60-4F67-B305-F70017C3C7E4@oracle.com> Looks fine Sean. On 20 Mar 2013, at 14:18, Sean Mullan wrote: > Please review this fix for a NullPointerException when checking revocation status of certificates: > > webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8010112/webrev.00/ > > The bug is not available online for some reason, so here are the relevant details: > > There were 2 issues that needed to be fixed: > > 1. CertId did not handle the case where a TrustAnchor was specified as a name/key pair. Added a new constructor to allow for that. > > 2. DistributionPointFetcher.verifyCRL was not comparing Authority Key Ids correctly. It was comparing the bytes of the entire extension value, instead of just the KeyIdentifier field. It turns out that there are some AKID extensions that have matching key ids but also may include additional information in the other fields, causing the previous comparison to fail even though the key identifiers match. > > noreg-hard because the bug requires a complex setup to reproduce. > > Thanks, > Sean From chris.hegarty at oracle.com Wed Mar 20 09:00:34 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 20 Mar 2013 16:00:34 +0000 Subject: hg: jdk8/tl/jdk: 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe Message-ID: <20130320160054.9B3564829D@hg.openjdk.java.net> Changeset: 3070b7363853 Author: chegar Date: 2013-03-20 14:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3070b7363853 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe Reviewed-by: khazra, alanb ! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java ! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java From sean.mullan at oracle.com Wed Mar 20 09:07:12 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 20 Mar 2013 16:07:12 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130320160747.CAF5F4829F@hg.openjdk.java.net> Changeset: 38116bfe5323 Author: mullan Date: 2013-03-20 10:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38116bfe5323 8010112: NullPointerException in sun.security.provider.certpath.CertId() Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/x509/X509CertImpl.java Changeset: 9859856920ed Author: mullan Date: 2013-03-20 11:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9859856920ed Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 38c1d0c2d6a6 Author: mullan Date: 2013-03-20 12:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38c1d0c2d6a6 Merge From mandy.chung at oracle.com Wed Mar 20 09:51:42 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 20 Mar 2013 16:51:42 +0000 Subject: hg: jdk8/tl/jdk: 8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration Message-ID: <20130320165154.8D490482A5@hg.openjdk.java.net> Changeset: ccd9f53377c4 Author: mchung Date: 2013-03-20 09:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccd9f53377c4 8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration Reviewed-by: alanb ! test/java/util/logging/CustomLogManager.java ! test/java/util/logging/CustomLogManagerTest.java From the.rob.leland at gmail.com Tue Mar 19 21:43:25 2013 From: the.rob.leland at gmail.com (Rob Leland) Date: Wed, 20 Mar 2013 00:43:25 -0400 Subject: hg: jdk8/tl/jdk: 8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong In-Reply-To: <20130319231031.7F46B48272@hg.openjdk.java.net> References: <20130319231031.7F46B48272@hg.openjdk.java.net> Message-ID: Has the optional classes been verified to serialize/deserialize correctly? I noticed it tries to use the null object pattern with the use of EMPTY private instance. When I have implemented the NULL pattern I have used a private subclass of the object as opposed to an instance variable to insure it unmarshalls correctly with a simple override of the default desearization to insure this. I also wonder why a marker interface wasn't used or something more substantial at least for methods like isPresent(). Also why does the static factory initialization parameters use primatives as opposed to objects? If objects were used then there would be the oppertunity to use a abstract base class, which has the potential to move the use of isPresent() strictly into the base class. Finally, are these utilities critical to some other part JDK 8 that they were pushed out now as opposed to JDK 9? On Mar 19, 2013 7:18 PM, wrote: > Changeset: 2241a2d34085 > Author: mduigou > Date: 2013-03-19 16:05 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2241a2d34085 > > 8001642: Add Optional , OptionalDouble, OptionalInt, OptionalLong > Reviewed-by: mduigou, darcy, alanb, jjb > Contributed-by: Brian Goetz > > + src/share/classes/java/util/Optional.java > + src/share/classes/java/util/OptionalDouble.java > + src/share/classes/java/util/OptionalInt.java > + src/share/classes/java/util/OptionalLong.java > + test/java/util/Optional/Basic.java > + test/java/util/Optional/BasicDouble.java > + test/java/util/Optional/BasicInt.java > + test/java/util/Optional/BasicLong.java > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130320/810e7f13/attachment-0001.html From alexey.utkin at oracle.com Wed Mar 20 02:29:53 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Wed, 20 Mar 2013 09:29:53 +0000 Subject: hg: jdk8/tl/jdk: 8006193: (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public Message-ID: <20130320093007.2E72848291@hg.openjdk.java.net> Changeset: fb23896a01f5 Author: uta Date: 2013-03-20 13:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb23896a01f5 8006193: (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public Reviewed-by: alanb ! src/windows/classes/java/lang/ProcessImpl.java From joe.darcy at oracle.com Wed Mar 20 15:21:33 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 20 Mar 2013 22:21:33 +0000 Subject: hg: jdk8/tl/jdk: 8010427: Refine Method.isDefault implementation Message-ID: <20130320222204.58614482BF@hg.openjdk.java.net> Changeset: cf0049037deb Author: darcy Date: 2013-03-20 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf0049037deb 8010427: Refine Method.isDefault implementation Reviewed-by: acorn, dlsmith ! src/share/classes/java/lang/reflect/Method.java From joe.darcy at oracle.com Wed Mar 20 17:41:53 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 21 Mar 2013 00:41:53 +0000 Subject: hg: jdk8/tl/langtools: 8010364: Clarify javax.lang.model API for Type Annotations Message-ID: <20130321004156.BF54C482CC@hg.openjdk.java.net> Changeset: 972474640b7d Author: darcy Date: 2013-03-20 17:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/972474640b7d 8010364: Clarify javax.lang.model API for Type Annotations Reviewed-by: jjg, abuckley ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/type/ExecutableType.java From weijun.wang at oracle.com Wed Mar 20 18:57:38 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Mar 2013 09:57:38 +0800 Subject: Code review request: 8009875: Provide a default udp_preference_limit for krb5.conf Message-ID: <514A6912.3020609@oracle.com> Please review the code change at http://cr.openjdk.java.net/~weijun/8009875/webrev.00/ A default udp_preference_limit value is defined. Note: The fix in KDC.java is trivial and not related to this bug. Thanks Max From david.holmes at oracle.com Wed Mar 20 19:40:14 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 21 Mar 2013 02:40:14 +0000 Subject: hg: jdk8/tl/jdk: 8006818: SunEC and SunPKCS11 providers should be in all profiles Message-ID: <20130321024037.46C27482D2@hg.openjdk.java.net> Changeset: 3c1a4966d901 Author: dholmes Date: 2013-03-20 22:39 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a4966d901 8006818: SunEC and SunPKCS11 providers should be in all profiles Reviewed-by: dholmes, alanb, valeriep Contributed-by: Jen Dority ! makefiles/profile-includes.txt From simone.bordet at gmail.com Thu Mar 21 09:01:02 2013 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 21 Mar 2013 17:01:02 +0100 Subject: Next Protocol Negotiation TLS Extension Message-ID: Hi all, [cross-posted to jdk8-dev and security-dev] I am a member of the Jetty servlet container (http://eclipse.org/jetty) team and the implementor of the Next Protocol Negotiation (NPN) TLS Extension used by Jetty to support the SPDY protocol (API at http://git.eclipse.org/c/jetty/org.eclipse.jetty.npn.git/ and implementation at https://github.com/jetty-project/jetty-npn). The SPDY protocol has been chosen as the basis for HTTP 2.0. I would like to ask for suggestions for what would be the best way to have NPN support in OpenJDK 8 rather than via the Jetty NPN implementation. Currently, the Jetty implementation is kind of "hacky" in that it is the smallest possible hack (in a positive meaning) to make NPN work in OpenJDK. It modifies 5 sun.security.ssl.* classes and introduces 5 new classes. These modifies classes must be put in the bootclasspath. The API of public classes like SSLEngine is not modified; instead the current implementation relies on a static class that maps SSLEngine (or SSLSocket) with application code that is invoked at the right time during the TLS handshake when NPN data is detected. Currently, the Jetty project maintains the NPN implementation locked with OpenJDK "releases": every time the sun.security.ssl.* classes are modified, we pull in the changes from OpenJDK, re-patch these classes with NPN support and make a new release of the NPN jar. The NPN TLS extension requires an API exposed to applications (usually web servers, but they are "applications" for the Java runtime). In this sense, JEP 114 (http://openjdk.java.net/jeps/114, SNI TLS extension) is similar: I am guessing it also has to expose an API to applications. It seems to me that both NPN and SNI would require a standard way to access TLS extensions at the proper time during the TLS handshake. In light of this, it would be great if NPN could be piggybacked on JEP 114, exposing a standard TLS extensions API provided by OpenJDK that application can use to plug in their code for NPN and/or SNI. Now, I understand that designing a TLS extensions API is not as simple as including the current Jetty NPN implementation in OpenJDK, but I would rather see a generic solution in OpenJDK rather than a "hacky" solution like current Jetty NPN's included in OpenJDK. A "private" TLS extensions API already exists in the sun.security.ssl.* classes, but it's mostly package private and of course under sun.* packages. So perhaps the work to be done is not a from-scratch effort. I would like to get a discussion started on how NPN can be supported in OpenJDK 8. Ideally, my best plan would be: * NPN included in JEP 114. * JEP 114 designing a standard TLS extensions API that can serve for both NPN and SNI (and, generically, others TLS extensions) * JEP 114 shipped in OpenJDK 8. We're happy to keep Jetty NPN up-to-date for OpenJDK 7 "releases", but we will really like to see NPN in OpenJDK 8. We are open to comply with any legal papers that needs to be in place for this contribution. I will be more than happy to provide detailed information about the implementation of Jetty NPN and have it discussed (or even reviewed) by security experts. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rob.mckenna at oracle.com Thu Mar 21 10:32:52 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 21 Mar 2013 17:32:52 +0000 Subject: hg: jdk8/tl/jdk: 8009251: Add proxy handling and keep-alive fixes to jsse Message-ID: <20130321173305.A6311482F0@hg.openjdk.java.net> Changeset: 3f8fbb0ab155 Author: robm Date: 2013-03-21 17:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f8fbb0ab155 8009251: Add proxy handling and keep-alive fixes to jsse Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java From sundararajan.athijegannathan at oracle.com Thu Mar 21 06:50:20 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 21 Mar 2013 13:50:20 +0000 Subject: hg: jdk8/tl/jdk: 8009869: Need to modify java.security property package.access to include nashorn packages Message-ID: <20130321135033.A694C482E8@hg.openjdk.java.net> Changeset: 9ee1aff76498 Author: sundar Date: 2013-03-21 19:19 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ee1aff76498 8009869: Need to modify java.security property package.access to include nashorn packages Reviewed-by: ahgross, jlaskey, lagergren ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows From bernd-2013 at eckenfels.net Thu Mar 21 15:44:23 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Thu, 21 Mar 2013 23:44:23 +0100 Subject: Next Protocol Negotiation TLS Extension In-Reply-To: References: Message-ID: Am 21.03.2013, 17:01 Uhr, schrieb Simone Bordet : > I would like to ask for suggestions for what would be the best way to > have NPN support in OpenJDK 8 rather than via the Jetty NPN > implementation. Is the Jetty solution related to the JSSE patch from Ben Murphy? https://github.com/benmmurphy/ssl_npn I was using this code for some SSL related tests, it is convinient to have a Github with Runtime code :) > * NPN included in JEP 114. > * JEP 114 designing a standard TLS extensions API that can serve for > both NPN and SNI (and, generically, others TLS extensions) > * JEP 114 shipped in OpenJDK 8. ... and some additional negotiation control code to help against excessive renegotiation attacks. Does Jetty have a fix here, as well? Gruss Bernd -- http://bernd.eckenfels.net From bradford.wetmore at oracle.com Thu Mar 21 17:08:41 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 21 Mar 2013 17:08:41 -0700 Subject: Next Protocol Negotiation TLS Extension In-Reply-To: References: Message-ID: <514BA109.6060901@oracle.com> Hi Simone, I haven't looked at the proposal yet, but just from a scheduling point of view, unfortunately we're finishing up the implementation of the last of the planned features for JDK 8, so getting this into 8 is likely not possible. We have an open bug for this (JDK-8007785) and it's on the radar for JDK 9. I'll put in a link to your email in that bug. I know Xuelei will want to look at this more closely, and I hope to also. Brad On 3/21/2013 9:01 AM, Simone Bordet wrote: > Hi all, > > [cross-posted to jdk8-dev and security-dev] > > I am a member of the Jetty servlet container > (http://eclipse.org/jetty) team and the implementor of the Next > Protocol Negotiation (NPN) TLS Extension used by Jetty to support the > SPDY protocol (API at > http://git.eclipse.org/c/jetty/org.eclipse.jetty.npn.git/ and > implementation at https://github.com/jetty-project/jetty-npn). > The SPDY protocol has been chosen as the basis for HTTP 2.0. > > I would like to ask for suggestions for what would be the best way to > have NPN support in OpenJDK 8 rather than via the Jetty NPN > implementation. > > Currently, the Jetty implementation is kind of "hacky" in that it is > the smallest possible hack (in a positive meaning) to make NPN work in > OpenJDK. It modifies 5 sun.security.ssl.* classes and introduces 5 new > classes. These modifies classes must be put in the bootclasspath. > The API of public classes like SSLEngine is not modified; instead the > current implementation relies on a static class that maps SSLEngine > (or SSLSocket) with application code that is invoked at the right time > during the TLS handshake when NPN data is detected. > > Currently, the Jetty project maintains the NPN implementation locked > with OpenJDK "releases": every time the sun.security.ssl.* classes are > modified, we pull in the changes from OpenJDK, re-patch these classes > with NPN support and make a new release of the NPN jar. > > The NPN TLS extension requires an API exposed to applications (usually > web servers, but they are "applications" for the Java runtime). In > this sense, JEP 114 (http://openjdk.java.net/jeps/114, SNI TLS > extension) is similar: I am guessing it also has to expose an API to > applications. > It seems to me that both NPN and SNI would require a standard way to > access TLS extensions at the proper time during the TLS handshake. > In light of this, it would be great if NPN could be piggybacked on JEP > 114, exposing a standard TLS extensions API provided by OpenJDK that > application can use to plug in their code for NPN and/or SNI. > > Now, I understand that designing a TLS extensions API is not as simple > as including the current Jetty NPN implementation in OpenJDK, but I > would rather see a generic solution in OpenJDK rather than a "hacky" > solution like current Jetty NPN's included in OpenJDK. > A "private" TLS extensions API already exists in the > sun.security.ssl.* classes, but it's mostly package private and of > course under sun.* packages. So perhaps the work to be done is not a > from-scratch effort. > > I would like to get a discussion started on how NPN can be supported > in OpenJDK 8. > > Ideally, my best plan would be: > > * NPN included in JEP 114. > * JEP 114 designing a standard TLS extensions API that can serve for > both NPN and SNI (and, generically, others TLS extensions) > * JEP 114 shipped in OpenJDK 8. > > We're happy to keep Jetty NPN up-to-date for OpenJDK 7 "releases", but > we will really like to see NPN in OpenJDK 8. > > We are open to comply with any legal papers that needs to be in place > for this contribution. > > I will be more than happy to provide detailed information about the > implementation of Jetty NPN and have it discussed (or even reviewed) > by security experts. > > Thanks ! > > -- > Simone Bordet > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > From weijun.wang at oracle.com Fri Mar 22 02:49:57 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 Mar 2013 02:49:57 -0700 (PDT) Subject: Code review request: 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 Message-ID: <514C2945.4080401@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8010531/webrev.00/ The tests have been failed a lot recently. Put them in problem list now. Thanks Max From Alan.Bateman at oracle.com Fri Mar 22 03:00:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Mar 2013 10:00:26 +0000 Subject: Code review request: 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 In-Reply-To: <514C2945.4080401@oracle.com> References: <514C2945.4080401@oracle.com> Message-ID: <514C2BBA.2070708@oracle.com> On 22/03/2013 09:49, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8010531/webrev.00/ > > The tests have been failed a lot recently. Put them in problem list now. > > Thanks > Max Looks fine to me but curious that this is Solaris 64-bit only (or is it Solaris 11 only?) -Alan From sean.coffey at oracle.com Fri Mar 22 03:02:19 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 22 Mar 2013 10:02:19 +0000 Subject: Code review request: 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 In-Reply-To: <514C2BBA.2070708@oracle.com> References: <514C2945.4080401@oracle.com> <514C2BBA.2070708@oracle.com> Message-ID: <514C2C2B.1050102@oracle.com> I was wondering the same. Is this sparc only or is solaris x86 impacted also ? regards, Sean. On 22/03/2013 10:00, Alan Bateman wrote: > On 22/03/2013 09:49, Weijun Wang wrote: >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8010531/webrev.00/ >> >> The tests have been failed a lot recently. Put them in problem list now. >> >> Thanks >> Max > Looks fine to me but curious that this is Solaris 64-bit only (or is > it Solaris 11 only?) > > -Alan From weijun.wang at oracle.com Fri Mar 22 03:05:57 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 Mar 2013 18:05:57 +0800 Subject: Code review request: 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 In-Reply-To: <514C2C2B.1050102@oracle.com> References: <514C2945.4080401@oracle.com> <514C2BBA.2070708@oracle.com> <514C2C2B.1050102@oracle.com> Message-ID: <514C2D05.8020902@oracle.com> All recent failures are on sparc. Since SQE only run 64 bit, I cannot confirm about 32 bit. They do run tests on solaris-i586 and tests run fine there. Definitely not only Solaris 11. Multiple Solaris 10 failures observed. Thanks Max On 3/22/13 6:02 PM, Se?n Coffey wrote: > I was wondering the same. Is this sparc only or is solaris x86 impacted > also ? > > regards, > Sean. > > On 22/03/2013 10:00, Alan Bateman wrote: >> On 22/03/2013 09:49, Weijun Wang wrote: >>> Please take a look at >>> >>> http://cr.openjdk.java.net/~weijun/8010531/webrev.00/ >>> >>> The tests have been failed a lot recently. Put them in problem list now. >>> >>> Thanks >>> Max >> Looks fine to me but curious that this is Solaris 64-bit only (or is >> it Solaris 11 only?) >> >> -Alan > From weijun.wang at oracle.com Fri Mar 22 05:05:58 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 22 Mar 2013 12:05:58 +0000 Subject: hg: jdk8/tl/jdk: 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 Message-ID: <20130322120610.2CBEA48337@hg.openjdk.java.net> Changeset: 93cd7052d306 Author: weijun Date: 2013-03-22 19:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93cd7052d306 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 Reviewed-by: alanb ! test/ProblemList.txt From maurizio.cimadamore at oracle.com Fri Mar 22 05:45:45 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 22 Mar 2013 12:45:45 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130322124559.BDE3D48338@hg.openjdk.java.net> Changeset: cc38a6723663 Author: mcimadamore Date: 2013-03-22 12:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc38a6723663 8009649: Lambda back-end should generate invokespecial for method handles referring to private instance methods Summary: Private lambda methods should be accessed through invokespecial Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/bytecode/TestLambdaBytecode.java Changeset: f3814edefb33 Author: mcimadamore Date: 2013-03-22 12:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3814edefb33 8010101: Intersection type cast issues redundant unchecked warning Summary: Code for checking intersection type cast is incorrectly swapping operands, leading to spurious warnings Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/Intersection02.java + test/tools/javac/lambda/Intersection02.out Changeset: b6cf07c54c29 Author: mcimadamore Date: 2013-03-22 12:41 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b6cf07c54c29 8009820: AssertionError when compiling java code with two identical static imports Summary: Speculative attribution is carried out twice with same method symbol in case of static imports Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/DoubleStaticImport.java Changeset: c6728c9addff Author: mcimadamore Date: 2013-03-22 12:43 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c6728c9addff 8010303: Graph inference: missing incorporation step causes spurious inference error Summary: Multiple equality constraints on inference vars are not used to generate new inference constraints Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/lambda/TargetType28.out + test/tools/javac/lambda/TargetType67.java + test/tools/javac/lambda/TargetType68.java + test/tools/javac/lambda/TargetType69.java Changeset: 5da12e8a59ba Author: mcimadamore Date: 2013-03-22 12:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5da12e8a59ba 8010387: Javac crashes when diagnostic mentions anonymous inner class' type variables Summary: Rich formatter doesn't preprocess supertypes of an anonymous inner class Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/8010387/T8010387.java + test/tools/javac/Diagnostics/8010387/T8010387.out From sean.mullan at oracle.com Fri Mar 22 08:50:03 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 Mar 2013 11:50:03 -0400 Subject: Code review request: 8009970: Several LoginModule classes need extra permission to load AuthResources In-Reply-To: <5140270A.4020007@oracle.com> References: <5140270A.4020007@oracle.com> Message-ID: <514C7DAB.7000801@oracle.com> This change looks fine to me. --Sean On 03/13/2013 03:13 AM, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/8009970/webrev.00 > > I was checking for krb5 permissions and noticed this. There is really no > need for a permission to access AuthResources strings in these login > modules. > > Also change to private, building JDK shows no other class uses the fields. > > Noreg-trivial. > > Thanks > Max From joe.darcy at oracle.com Fri Mar 22 10:09:00 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 22 Mar 2013 17:09:00 +0000 Subject: hg: jdk8/tl/langtools: 7080464: langtools regression test failures when assertions are enabled Message-ID: <20130322170906.1F92948345@hg.openjdk.java.net> Changeset: f4500abff1fd Author: darcy Date: 2013-03-22 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4500abff1fd 7080464: langtools regression test failures when assertions are enabled Reviewed-by: jjg ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/diags/MessageFile.java ! test/tools/javac/diags/MessageInfo.java From anthony.scarpino at oracle.com Fri Mar 22 11:57:09 2013 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 22 Mar 2013 11:57:09 -0700 Subject: code review request: 7171982 Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider Message-ID: <514CA985.5080106@oracle.com> Hi all, I need a code review for below webrev. The changes are to have SunJCE call itself, using it's current instance, for checking such things as parameters, instead of searching through the provider list or creating a one time instance. http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/webrev.00/ thanks Tony From valerie.peng at oracle.com Fri Mar 22 17:14:14 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 22 Mar 2013 17:14:14 -0700 Subject: Code review request: 8009875: Provide a default udp_preference_limit for krb5.conf In-Reply-To: <514A6912.3020609@oracle.com> References: <514A6912.3020609@oracle.com> Message-ID: <514CF3D6.2060101@oracle.com> Look fine to me. Thanks, Valerie On 03/20/13 18:57, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8009875/webrev.00/ > > A default udp_preference_limit value is defined. > > Note: The fix in KDC.java is trivial and not related to this bug. > > Thanks > Max From weijun.wang at oracle.com Fri Mar 22 20:50:00 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 23 Mar 2013 03:50:00 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130323035033.632B54836B@hg.openjdk.java.net> Changeset: 3470101fae58 Author: weijun Date: 2013-03-23 11:49 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3470101fae58 8009970: Several LoginModule classes need extra permission to load AuthResources Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java Changeset: ed63cace1d30 Author: weijun Date: 2013-03-23 11:49 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed63cace1d30 8009875: Provide a default udp_preference_limit for krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/config/DefUdpLimit.java From bernd-2013 at eckenfels.net Sun Mar 24 12:43:38 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Sun, 24 Mar 2013 20:43:38 +0100 Subject: Radomly Failed (RSA2013) Message-ID: Hallo, I am quite sure you received the paper directly, but nevertheless I want to be sure and point it out here on the list as well. http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations Kai Michaelis, Christopher Meyer and J?rg Schwenk - Ruhr Uni Bochum Abstract: This paper investigates the Randomness of several Java Run-time Libraries by inspecting the integrated Pseudo Random NumberGenerators. Signi?cant weaknesses in di?erent libraries including An-droid, are uncovered. For the OpenJDK most of the critics was in regards of the size limited state pool for the SHA-1 generator. I guess the analysis of the entropy collector is not that relevant, and since SHA1PRNG is miving with native random on most platforms it is also not so critical. However when building a strong version for key generation the state space should be defined/observed in spec, I think? Greetings Bernd PS: found this Paper via Kris K?hntopp, I think it is from the Cryptography Track at RSA 2013 conference. -- http://bernd.eckenfels.net From christopher.meyer at rub.de Mon Mar 25 01:28:40 2013 From: christopher.meyer at rub.de (Christopher Meyer) Date: 25 Mar 2013 09:28:40 +0100 Subject: Radomly Failed (RSA2013) In-Reply-To: References: Message-ID: <3719648.LaGiPfFKch@bender> Hi Bernd, we already discussed the problems together with Brad during the JEP 123 proposal conception. Most problems had already been adressed by his proposal or were already known. But nevertheless, thanks for highlighting :-) Cheers from Bochum, Chris On Sunday 24 March 2013 20:43:38 Bernd Eckenfels wrote: > Hallo, > > I am quite sure you received the paper directly, but nevertheless I want > to be sure and point it out here on the list as well. > > http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness- > in-Current-Java-Implementations > > Kai Michaelis, Christopher Meyer and J?rg Schwenk - Ruhr Uni Bochum > > Abstract: This paper investigates the Randomness of several Java Run-time > Libraries by inspecting the integrated Pseudo Random NumberGenerators. > Signi?cant weaknesses in di?erent libraries including An-droid, are > uncovered. > > > For the OpenJDK most of the critics was in regards of the size limited > state pool for the SHA-1 generator. I guess the analysis of the entropy > collector is not that relevant, and since SHA1PRNG is miving with native > random on most platforms it is also not so critical. However when building > a strong version for key generation the state space should be > defined/observed in spec, I think? > > Greetings > Bernd > > PS: found this Paper via Kris K?hntopp, I think it is from the > Cryptography Track at RSA 2013 conference. ______________________________________ Dipl.-Ing. Christopher Meyer Horst G?rtz Institute for IT-Security Chair for Network and Data Security Ruhr-University Bochum, Germany Universit?tsstr. 150, ID 2/415 D-44801 Bochum, Germany http:// www.nds.rub.de Phone: (+49) (0)234 / 32 - 29815 Fax: (+49) (0)234 / 32 - 14347 From simone.bordet at gmail.com Mon Mar 25 06:59:26 2013 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 25 Mar 2013 14:59:26 +0100 Subject: Next Protocol Negotiation TLS Extension In-Reply-To: <514BA109.6060901@oracle.com> References: <514BA109.6060901@oracle.com> Message-ID: Hi, On Fri, Mar 22, 2013 at 1:08 AM, Brad Wetmore wrote: > Hi Simone, > > I haven't looked at the proposal yet, but just from a scheduling point of > view, unfortunately we're finishing up the implementation of the last of the > planned features for JDK 8, so getting this into 8 is likely not possible. "Likely not possible" means "totally impossible" or "if you do this and that, then it's possible" ? :) Do you know the status of JEP 114 ? Will it be shipped in JDK 8 ? > We have an open bug for this (JDK-8007785) and it's on the radar for JDK 9. Ok, if impossible I will eventually pop up again when JDK 8 is released and JDK 9 work started. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From chris.hegarty at oracle.com Mon Mar 25 07:30:18 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 25 Mar 2013 14:30:18 +0000 Subject: hg: jdk8/tl/jdk: 8010668: builtin JNI libraries should not be unloaded Message-ID: <20130325143042.9F4E2483AB@hg.openjdk.java.net> Changeset: 5d0c891264bf Author: chegar Date: 2013-03-25 14:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d0c891264bf 8010668: builtin JNI libraries should not be unloaded Reviewed-by: chegar, alanb Contributed-by: Bill Pittore ! src/share/native/java/lang/ClassLoader.c From stefan.karlsson at oracle.com Fri Mar 22 06:54:32 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 22 Mar 2013 13:54:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130322135510.0F76C4833B@hg.openjdk.java.net> Changeset: 470232a8e89d Author: stefank Date: 2013-03-22 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/470232a8e89d 8005116: NPG: Rename -permstat option for jmap in jdk8 to -clstats Reviewed-by: jmasa, sla Contributed-by: Erik Helin ! src/share/classes/sun/tools/jmap/JMap.java Changeset: 518d6087e01f Author: stefank Date: 2013-03-22 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/518d6087e01f 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: mchung Contributed-by: Erik Helin ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk + test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk - test/sun/tools/jstat/gcPermCapacityOutput1.awk + test/sun/tools/jstat/jstatGcMetaCapacityOutput1.sh - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/options1.out ! test/sun/tools/jstat/options2.out ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk From sundararajan.athijegannathan at oracle.com Sun Mar 24 23:42:40 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 25 Mar 2013 06:42:40 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130325064243.334A64839B@hg.openjdk.java.net> Changeset: 3b0a0d9d51f0 Author: sundar Date: 2013-03-18 21:03 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3b0a0d9d51f0 8010199: javax.script.Invocable implementation for nashorn does not return null when matching functions are missing Reviewed-by: lagergren, jlaskey ! bin/jjs ! bin/jjssecure ! bin/nashorn ! bin/nashornsecure ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + test/script/basic/JDK-8010199.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 606a1946e3e2 Author: jlaskey Date: 2013-03-19 11:03 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/606a1946e3e2 8009969: CodeCoverage should use template Reviewed-by: jlaskey, sundar Contributed-by: pavel.stepanov at oracle.com ! make/build.xml ! make/code_coverage.xml ! make/project.properties Changeset: 4be452026847 Author: attila Date: 2013-03-23 00:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4be452026847 8010652: Eliminate non-child references in Block/FunctionNode, and make few node types immutable Reviewed-by: jlaskey, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java - src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8006755.js ! test/script/basic/NASHORN-837.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java From sundararajan.athijegannathan at oracle.com Mon Mar 25 06:55:29 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 25 Mar 2013 13:55:29 +0000 Subject: hg: jdk8/tl/jdk: 8010704: The test closed/java/lang/SecurityManager/CheckPackageDefinition.java failed after fix for 8009869 Message-ID: <20130325135608.10B40483A9@hg.openjdk.java.net> Changeset: d92a96dcbfe1 Author: sundar Date: 2013-03-25 19:25 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d92a96dcbfe1 8010704: The test closed/java/lang/SecurityManager/CheckPackageDefinition.java failed after fix for 8009869 Reviewed-by: lagergren, hannesw ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-solaris From bradford.wetmore at oracle.com Mon Mar 25 14:26:03 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 25 Mar 2013 14:26:03 -0700 Subject: Next Protocol Negotiation TLS Extension In-Reply-To: References: <514BA109.6060901@oracle.com> Message-ID: <5150C0EB.6030208@oracle.com> On 3/25/2013 6:59 AM, Simone Bordet wrote: > Hi, > > On Fri, Mar 22, 2013 at 1:08 AM, Brad Wetmore > wrote: >> Hi Simone, >> >> I haven't looked at the proposal yet, but just from a scheduling point of >> view, unfortunately we're finishing up the implementation of the last of the >> planned features for JDK 8, so getting this into 8 is likely not possible. > > "Likely not possible" means "totally impossible" or "if you do this > and that, then it's possible" ? :) I would never say "totally impossible," but closer to "totally impossible" than "likely not possible." > Do you know the status of JEP 114 ? Will it be shipped in JDK 8 ? That is still the expectation. We had to pull 114 temporarily because of a conflict in two projects, and we'll be working on resolving the merge when the engineer is back from vacation. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009925 >> We have an open bug for this (JDK-8007785) and it's on the radar for JDK 9. > > Ok, if impossible I will eventually pop up again when JDK 8 is > released and JDK 9 work started. Planning for JDK 9's features will start well before that. Some of the dev work will already be underway by release. Brad > Thanks ! > > -- > Simone Bordet > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > From mandy.chung at oracle.com Mon Mar 25 17:22:00 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 26 Mar 2013 00:22:00 +0000 Subject: hg: jdk8/tl/jdk: 8007703: Remove com.sun.servicetag API Message-ID: <20130326002227.A2616483BD@hg.openjdk.java.net> Changeset: 5e383a73386a Author: mchung Date: 2013-03-25 17:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e383a73386a 8007703: Remove com.sun.servicetag API Reviewed-by: dholmes, alanb, erikj ! make/com/sun/Makefile ! make/common/Release.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcProperties.gmk ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt ! test/Makefile From mandy.chung at oracle.com Mon Mar 25 18:17:13 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 26 Mar 2013 01:17:13 +0000 Subject: hg: jdk8/tl/jdk: 8010787: changeset for 8007703 is missing the deleted files Message-ID: <20130326011748.B254C483C1@hg.openjdk.java.net> Changeset: 335d2156222e Author: mchung Date: 2013-03-25 18:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/335d2156222e 8010787: changeset for 8007703 is missing the deleted files Reviewed-by: dholmes, alanb, erikj - make/com/sun/servicetag/Makefile - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties From michael.fang at oracle.com Mon Mar 25 19:10:35 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Tue, 26 Mar 2013 02:10:35 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130326021037.A6553483C4@hg.openjdk.java.net> Changeset: c3ec80715805 Author: mfang Date: 2013-03-25 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/c3ec80715805 8010521: jdk8 l10n resource file translation update 2 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 910af9c3f338 Author: mfang Date: 2013-03-25 18:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/910af9c3f338 Merge From michael.fang at oracle.com Mon Mar 25 19:14:22 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Tue, 26 Mar 2013 02:14:22 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130326021430.20979483C5@hg.openjdk.java.net> Changeset: fdf30b225e1c Author: mfang Date: 2013-03-25 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fdf30b225e1c 8010521: jdk8 l10n resource file translation update 2 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties Changeset: 65e1ca8dcdc7 Author: mfang Date: 2013-03-25 18:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65e1ca8dcdc7 Merge From sundararajan.athijegannathan at oracle.com Tue Mar 26 07:04:34 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 26 Mar 2013 14:04:34 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20130326140438.14F29483DB@hg.openjdk.java.net> Changeset: ae4ef3102d9c Author: lagergren Date: 2013-03-25 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ae4ef3102d9c 8017010: index evaluation to a temporary location for index operator much change temporaries to slots, but never scoped vars Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + test/script/basic/JDK-8017010.js + test/script/basic/JDK-8017010.js.EXPECTED ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-258.js.EXPECTED Changeset: 15dac7439921 Author: sundar Date: 2013-03-25 18:20 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/15dac7439921 8010709: org on the top level doesn't resolve Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8010709.js Changeset: 43e40c08e7f8 Author: lagergren Date: 2013-03-26 08:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/43e40c08e7f8 8010706: -Dnashorn.args system property to create command lines to wrapped nashorn.jar:s Reviewed-by: hannesw, sundar ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: ed60078f0a80 Author: sundar Date: 2013-03-26 18:26 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ed60078f0a80 8010720: Linkage problem with java.lang.String.length() Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8010720.js From martinrb at google.com Tue Mar 26 13:41:30 2013 From: martinrb at google.com (martinrb at google.com) Date: Tue, 26 Mar 2013 20:41:30 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130326204203.53C25483EF@hg.openjdk.java.net> Changeset: 3b56ef8e1ce1 Author: martin Date: 2013-03-26 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b56ef8e1ce1 8007905: To add a system property to create zip file without using ZIP64 end table when entry count > 64k Summary: Provide a system property to inhibit ZIP64 mode for >64k entries Reviewed-by: alanb, sherman ! src/share/classes/java/util/zip/ZipOutputStream.java + test/java/util/zip/EntryCount64k.java Changeset: 266b43683a2c Author: martin Date: 2013-03-26 13:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/266b43683a2c 8010316: Improve handling of char sequences containing surrogates Summary: Fix and optimize codePointAt, codePointBefore and similar methods Reviewed-by: sherman, okutsu, ulfzibis, kizune ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Character.java ! test/java/lang/StringBuilder/Supplementary.java From weijun.wang at oracle.com Tue Mar 26 16:29:34 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 Mar 2013 07:29:34 +0800 Subject: code review request: 8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass Message-ID: <51522F5E.6090409@oracle.com> http://cr.openjdk.java.net/~weijun/8010125/webrev.00/ Thanks Max From joe.darcy at oracle.com Tue Mar 26 17:17:33 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Mar 2013 00:17:33 +0000 Subject: hg: jdk8/tl/langtools: 7041251: Use j.u.Objects utility methods in langtools Message-ID: <20130327001738.A090C48400@hg.openjdk.java.net> Changeset: 330b35b27e68 Author: darcy Date: 2013-03-26 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/330b35b27e68 7041251: Use j.u.Objects utility methods in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/javax/annotation/processing/AbstractProcessor.java From joe.darcy at oracle.com Tue Mar 26 18:15:34 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Mar 2013 01:15:34 +0000 Subject: hg: jdk8/tl/langtools: 7059170: Assume availablility of URLClassLoader.close Message-ID: <20130327011539.80B7848402@hg.openjdk.java.net> Changeset: 33b6a52f0037 Author: darcy Date: 2013-03-26 18:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33b6a52f0037 7059170: Assume availablility of URLClassLoader.close Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java - src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java From dan.xu at oracle.com Wed Mar 27 09:02:17 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 27 Mar 2013 16:02:17 +0000 Subject: hg: jdk8/tl/jdk: 8010837: FileInputStream.available() throw IOException when encountering negative available values Message-ID: <20130327160234.87FFE4841B@hg.openjdk.java.net> Changeset: 49602f599c08 Author: dxu Date: 2013-03-27 09:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49602f599c08 8010837: FileInputStream.available() throw IOException when encountering negative available values Summary: Remove the check in the native code to allow negative values Reviewed-by: mchung ! src/solaris/native/java/io/io_util_md.c + test/java/io/FileInputStream/NegativeAvailable.java From joe.darcy at oracle.com Wed Mar 27 09:39:26 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Mar 2013 16:39:26 +0000 Subject: hg: jdk8/tl/jdk: 7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations Message-ID: <20130327163947.9634348424@hg.openjdk.java.net> Changeset: ae03282ba501 Author: darcy Date: 2013-03-27 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501 7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations Reviewed-by: mduigou, jfranck ! src/share/classes/sun/reflect/annotation/AnnotationType.java From stefan.karlsson at oracle.com Wed Mar 27 07:23:38 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Wed, 27 Mar 2013 14:23:38 +0000 Subject: hg: jdk8/tl/jdk: 8009427: Re-enable tests that were disable to ease complicated push Message-ID: <20130327142359.A5C2F48416@hg.openjdk.java.net> Changeset: caafe6dca35d Author: ehelin Date: 2013-03-21 20:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/caafe6dca35d 8009427: Re-enable tests that were disable to ease complicated push Reviewed-by: sla, mchung, dcubed Contributed-by: Erik Helin ! test/ProblemList.txt From karen.kinnear at oracle.com Wed Mar 27 10:58:32 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 27 Mar 2013 17:58:32 +0000 Subject: hg: jdk8/tl/jdk: 8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java Message-ID: <20130327175853.38B7248427@hg.openjdk.java.net> Changeset: d254a5f9b93f Author: acorn Date: 2013-03-27 13:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d254a5f9b93f 8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52 Reviewed-by: acorn, hseigel ! test/vm/verifier/TestStaticIF.java From maurizio.cimadamore at oracle.com Thu Mar 28 04:40:18 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 28 Mar 2013 11:40:18 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130328114024.08FB148466@hg.openjdk.java.net> Changeset: 7bebe17ff323 Author: mcimadamore Date: 2013-03-28 11:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bebe17ff323 8010469: Bad assertion in LambdaToMethod Summary: Add assertion in LambdaToMethod.serializedLambdaName Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java Changeset: a200d8ccfe47 Author: mcimadamore Date: 2013-03-28 11:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a200d8ccfe47 8010490: FindBugs: double assignments in LambdaToMethod.visitIdent Summary: Remove dead code from LambdaToMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java From Vincent.X.Ryan at Oracle.Com Thu Mar 28 04:50:36 2013 From: Vincent.X.Ryan at Oracle.Com (Vincent Ryan) Date: Thu, 28 Mar 2013 11:50:36 +0000 Subject: code review request: 8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass In-Reply-To: <51522F5E.6090409@oracle.com> References: <51522F5E.6090409@oracle.com> Message-ID: <8ABBEAC4-30C6-49D2-8AC9-F343BFE99FC0@Oracle.Com> Hello Max, That fix looks fine. Thanks. On 26 Mar 2013, at 23:29, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/8010125/webrev.00/ > > Thanks > Max From weijun.wang at oracle.com Thu Mar 28 05:28:44 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 28 Mar 2013 12:28:44 +0000 Subject: hg: jdk8/tl/jdk: 8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass Message-ID: <20130328122907.EE76A48467@hg.openjdk.java.net> Changeset: a87fac00915e Author: weijun Date: 2013-03-28 20:27 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a87fac00915e 8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass Reviewed-by: vinnie ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/keytool/Resources.java + test/sun/security/tools/keytool/p12importks.sh From vincent.x.ryan at oracle.com Thu Mar 28 06:24:49 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 28 Mar 2013 13:24:49 +0000 Subject: code review request: 7171982 Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider In-Reply-To: <514CA985.5080106@oracle.com> References: <514CA985.5080106@oracle.com> Message-ID: Hello Tony, Your changes look fine. Thanks. On 22 Mar 2013, at 18:57, Anthony Scarpino wrote: > Hi all, > > I need a code review for below webrev. The changes are to have SunJCE call itself, using it's current instance, for checking such things as parameters, instead of searching through the provider list or creating a one time instance. > > http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/webrev.00/ > > thanks > > Tony From brian.goetz at oracle.com Thu Mar 28 08:34:23 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 28 Mar 2013 08:34:23 -0700 Subject: hg: jdk8/tl/jdk: 8001642: Add Optional , OptionalDouble, OptionalInt, OptionalLong In-Reply-To: References: <20130319231031.7F46B48272@hg.openjdk.java.net> Message-ID: > Has the optional classes been verified to serialize/deserialize correctly? > They are not serializable. > Finally, are these utilities critical to some other part JDK 8 that they were pushed out now as opposed to JDK 9? > > They are part of the libraries being added by JSR-335 / Project Lambda. There is extensive discussion on Optional on lambda-dev and the JSR 335 EG lists. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130328/593b9a39/attachment.html From jonathan.gibbons at oracle.com Thu Mar 28 10:49:57 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 28 Mar 2013 17:49:57 +0000 Subject: hg: jdk8/tl/langtools: 8006346: doclint should make allowance for headers generated by standard doclet Message-ID: <20130328175002.0B94F48470@hg.openjdk.java.net> Changeset: 991f11e13598 Author: jjg Date: 2013-03-28 10:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/991f11e13598 8006346: doclint should make allowance for headers generated by standard doclet Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Env.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java + test/tools/javac/doclint/ImplicitHeadersTest.java + test/tools/javadoc/doclint/ImplicitHeadersTest.java From jonathan.gibbons at oracle.com Thu Mar 28 10:59:01 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 28 Mar 2013 17:59:01 +0000 Subject: hg: jdk8/tl/langtools: 8010511: Tests are creating files in /tmp Message-ID: <20130328175906.7F55348471@hg.openjdk.java.net> Changeset: d3648557391b Author: jjg Date: 2013-03-28 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d3648557391b 8010511: Tests are creating files in /tmp Reviewed-by: darcy ! test/tools/javac/T6558476.java ! test/tools/javac/T6900149.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/RunExamples.java From mandy.chung at oracle.com Thu Mar 28 13:16:32 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 28 Mar 2013 20:16:32 +0000 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level Message-ID: <20130328201656.E120C48477@hg.openjdk.java.net> Changeset: e433ed08b733 Author: mchung Date: 2013-03-28 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e433ed08b733 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level Reviewed-by: mchung Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java From anthony.scarpino at oracle.com Thu Mar 28 14:29:04 2013 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 28 Mar 2013 14:29:04 -0700 Subject: simple code review request: 8001596 Message-ID: <5154B620.60906@oracle.com> Hi all, I have a very simple code review request. It's a typo bug. 8001596 Incorrect condition check in PBKDF2KeyImpl.JAVA https://jbs.oracle.com/bugs/browse/JDK-8001596 http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/8001596/webrev.01/ thanks Tony From bradford.wetmore at oracle.com Thu Mar 28 14:34:30 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 28 Mar 2013 14:34:30 -0700 Subject: code review request: 7171982 Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider In-Reply-To: <514CA985.5080106@oracle.com> References: <514CA985.5080106@oracle.com> Message-ID: <5154B766.5040409@oracle.com> (Vinnie, what do you think about the SunJCE item below?) On 3/22/2013 11:57 AM, Anthony Scarpino wrote: > Hi all, > > I need a code review for below webrev. The changes are to have SunJCE > call itself, using it's current instance, for checking such things as > parameters, instead of searching through the provider list or creating a > one time instance. > > http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/webrev.00/ PBES1Core.java ============== 173: indention problem. Should be at the same level as (algo...) PBES2Core.java:173 PKCS12PBECipherCore.java:147 SealedObjectForKeyProtector:50/57 ======================== Indention problem. Normally 4 spaces unless you're trying to line it up with something. SealedObjectForKeyProtector.java ================================ 54/57: In general, you should initCause() everywhere you possibly can. This will help people (us) debug the real underlying root cause, instead of just the top-level error message. SunJCE.java =========== 781: Your code could race during initialization and potentially have many SunJCE instances active at once. Either make instance a volatile (will reduce some of the race opportunity), or instead, add locking around assignment/use. You may still be creating multiple SunJCEs, but only one instance will ever be obtained from getInstance: synchronized (SunJCE.class) { if (instance == null) { instance = this; } } and static SunJCE getInstance() { if (instance == null) { new SunJCE(); } synchronized (SunJCE.class) { return instance; } } Also, when you get ready to push, be sure to address also the closed side: that is, please remember to build/integrate the signed sunjce_provider.jar file in the closed repo. HTH, Brad From bradford.wetmore at oracle.com Thu Mar 28 14:40:51 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 28 Mar 2013 14:40:51 -0700 Subject: simple code review request: 8001596 In-Reply-To: <5154B620.60906@oracle.com> References: <5154B620.60906@oracle.com> Message-ID: <5154B8E3.9050202@oracle.com> Just realized, there are no regression tests here. Simplest is to probably do as much setup as you can, then java.security.Security.removeProvider("SunJCE"), then issue the calls that call into these changes. They should all pass in the new version, and fail in the old. Brad On 3/28/2013 2:29 PM, Anthony Scarpino wrote: > Hi all, > > I have a very simple code review request. It's a typo bug. > > 8001596 Incorrect condition check in PBKDF2KeyImpl.JAVA > https://jbs.oracle.com/bugs/browse/JDK-8001596 > > http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/8001596/webrev.01/ > > thanks > > Tony From bradford.wetmore at oracle.com Thu Mar 28 14:45:56 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 28 Mar 2013 14:45:56 -0700 Subject: code review request: 7171982 Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider In-Reply-To: <5154B766.5040409@oracle.com> References: <514CA985.5080106@oracle.com> <5154B766.5040409@oracle.com> Message-ID: <5154BA14.8050505@oracle.com> (Whoops, was working on two reviews with two related comments, and reversed the emails). Just realized, there are no regression tests here. Simplest is to probably do as much setup as you can, then java.security.Security.removeProvider("SunJCE"), then issue the calls that call into these changes. They should all pass in the new version, and fail in the old. Brad On 3/28/2013 2:34 PM, Brad Wetmore wrote: > (Vinnie, what do you think about the SunJCE item below?) > > On 3/22/2013 11:57 AM, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review for below webrev. The changes are to have SunJCE >> call itself, using it's current instance, for checking such things as >> parameters, instead of searching through the provider list or creating a >> one time instance. >> >> http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/webrev.00/ > > PBES1Core.java > ============== > 173: indention problem. Should be at the same level as (algo...) > > PBES2Core.java:173 > PKCS12PBECipherCore.java:147 > SealedObjectForKeyProtector:50/57 > ======================== > Indention problem. Normally 4 spaces unless you're trying to line it up > with something. > > SealedObjectForKeyProtector.java > ================================ > 54/57: In general, you should initCause() everywhere you possibly can. > This will help people (us) debug the real underlying root cause, > instead of just the top-level error message. > > SunJCE.java > =========== > 781: Your code could race during initialization and potentially have > many SunJCE instances active at once. > > Either make instance a volatile (will reduce some of the race > opportunity), or instead, add locking around assignment/use. You may > still be creating multiple SunJCEs, but only one instance will ever be > obtained from getInstance: > > synchronized (SunJCE.class) { > if (instance == null) { > instance = this; > } > } > > and > > static SunJCE getInstance() { > if (instance == null) { > new SunJCE(); > } > synchronized (SunJCE.class) { > return instance; > } > } > > Also, when you get ready to push, be sure to address also the closed > side: that is, please remember to build/integrate the signed > sunjce_provider.jar file in the closed repo. > > HTH, > > Brad > > From bradford.wetmore at oracle.com Thu Mar 28 14:46:11 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 28 Mar 2013 14:46:11 -0700 Subject: simple code review request: 8001596 In-Reply-To: <5154B620.60906@oracle.com> References: <5154B620.60906@oracle.com> Message-ID: <5154BA23.3060402@oracle.com> There is no regression test. I created one which relies on reflection, which is one way to test this problem. Feel free to create another, but that one is ready to go. Please see the attachment in the bug, and you'll probably want to update the copyright date. Brad On 3/28/2013 2:29 PM, Anthony Scarpino wrote: > Hi all, > > I have a very simple code review request. It's a typo bug. > > 8001596 Incorrect condition check in PBKDF2KeyImpl.JAVA > https://jbs.oracle.com/bugs/browse/JDK-8001596 > > http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/8001596/webrev.01/ > > thanks > > Tony From anthony.scarpino at oracle.com Thu Mar 28 14:51:20 2013 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 28 Mar 2013 14:51:20 -0700 Subject: simple code review request: 8001596 In-Reply-To: <5154BA23.3060402@oracle.com> References: <5154B620.60906@oracle.com> <5154BA23.3060402@oracle.com> Message-ID: <5154BB58.1050500@oracle.com> I had left the regression test out of this as it was a typo rather than a code logic issue or something someone could rebroken. Are you ok if this goes back without a test? Tony On 03/28/2013 02:46 PM, Brad Wetmore wrote: > There is no regression test. I created one which relies on reflection, > which is one way to test this problem. Feel free to create another, but > that one is ready to go. > > Please see the attachment in the bug, and you'll probably want to update > the copyright date. > > Brad > > > > On 3/28/2013 2:29 PM, Anthony Scarpino wrote: >> Hi all, >> >> I have a very simple code review request. It's a typo bug. >> >> 8001596 Incorrect condition check in PBKDF2KeyImpl.JAVA >> https://jbs.oracle.com/bugs/browse/JDK-8001596 >> >> http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/8001596/webrev.01/ >> >> thanks >> >> Tony From sundararajan.athijegannathan at oracle.com Thu Mar 28 02:06:59 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 28 Mar 2013 09:06:59 +0000 Subject: hg: jdk8/tl/jdk: 8010991: Enable test/javax/script/GetInterfaceTest.java again Message-ID: <20130328090857.B19F448458@hg.openjdk.java.net> Changeset: 811c771acf65 Author: sundar Date: 2013-03-28 14:36 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/811c771acf65 8010991: Enable test/javax/script/GetInterfaceTest.java again Reviewed-by: lagergren, hannesw ! test/javax/script/GetInterfaceTest.java From bradford.wetmore at oracle.com Thu Mar 28 15:10:33 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 28 Mar 2013 15:10:33 -0700 Subject: simple code review request: 8001596 In-Reply-To: <5154BB58.1050500@oracle.com> References: <5154B620.60906@oracle.com> <5154BA23.3060402@oracle.com> <5154BB58.1050500@oracle.com> Message-ID: <5154BFD9.9020202@oracle.com> Minor typos that don't affect program execution (comments/javadoc) are ok to not do unit tests, but even through this is a typo, I think this still needs a test. Brad On 3/28/2013 2:51 PM, Anthony Scarpino wrote: > I had left the regression test out of this as it was a typo rather than > a code logic issue or something someone could rebroken. Are you ok if > this goes back without a test? > > Tony > > On 03/28/2013 02:46 PM, Brad Wetmore wrote: >> There is no regression test. I created one which relies on reflection, >> which is one way to test this problem. Feel free to create another, but >> that one is ready to go. >> >> Please see the attachment in the bug, and you'll probably want to update >> the copyright date. >> >> Brad >> >> >> >> On 3/28/2013 2:29 PM, Anthony Scarpino wrote: >>> Hi all, >>> >>> I have a very simple code review request. It's a typo bug. >>> >>> 8001596 Incorrect condition check in PBKDF2KeyImpl.JAVA >>> https://jbs.oracle.com/bugs/browse/JDK-8001596 >>> >>> http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/8001596/webrev.01/ >>> >>> thanks >>> >>> Tony > From anthony.scarpino at oracle.com Thu Mar 28 18:00:03 2013 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 28 Mar 2013 18:00:03 -0700 Subject: code review request: 7171982 Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider In-Reply-To: <5154B766.5040409@oracle.com> References: <514CA985.5080106@oracle.com> <5154B766.5040409@oracle.com> Message-ID: <5154E793.7050004@oracle.com> On 03/28/2013 02:34 PM, Brad Wetmore wrote: > (Vinnie, what do you think about the SunJCE item below?) > > On 3/22/2013 11:57 AM, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review for below webrev. The changes are to have SunJCE >> call itself, using it's current instance, for checking such things as >> parameters, instead of searching through the provider list or creating a >> one time instance. >> >> http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/webrev.00/ > > PBES1Core.java > ============== > 173: indention problem. Should be at the same level as (algo...) > > PBES2Core.java:173 > PKCS12PBECipherCore.java:147 > SealedObjectForKeyProtector:50/57 > ======================== > Indention problem. Normally 4 spaces unless you're trying to line it up > with something. Looks like I need to change netbeans code formatting as I was letting it be my guide for those. > > SealedObjectForKeyProtector.java > ================================ > 54/57: In general, you should initCause() everywhere you possibly can. > This will help people (us) debug the real underlying root cause, > instead of just the top-level error message. Sounds reasonable. > > SunJCE.java > =========== > 781: Your code could race during initialization and potentially have > many SunJCE instances active at once. > > Either make instance a volatile (will reduce some of the race > opportunity), or instead, add locking around assignment/use. You may > still be creating multiple SunJCEs, but only one instance will ever be > obtained from getInstance: > > synchronized (SunJCE.class) { > if (instance == null) { > instance = this; > } > } > > and > > static SunJCE getInstance() { > if (instance == null) { > new SunJCE(); > } > synchronized (SunJCE.class) { > return instance; > } > } I think what you have there creates the situation where if two getInstance()'s were called with instance = null, the second thread to make it through the synchronized call creates a SunJCE object that never gets used and returns the first threads object. Maybe it makes sense to make 'instance' volatile, then: SunJCE() { ... if (instance == null) { instance = this; } } and static SunJCE getInstance() { if (instance == null) { return new SunJCE(); } return instance; } We don't stop multiple SunJCE objects, not that stopping them was ever the intention of this change, but we reduce their likelihood during a crunch and if they are created, at least they are used before being discarded. Tony > > Also, when you get ready to push, be sure to address also the closed > side: that is, please remember to build/integrate the signed > sunjce_provider.jar file in the closed repo. > > HTH, > > Brad > > From mandy.chung at oracle.com Thu Mar 28 19:55:01 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Mar 2013 19:55:01 -0700 Subject: Review Request 8007035: Deprecate SecurityManager.checkMemberAccess Message-ID: <51550285.9050706@oracle.com> Sean, John, Joe, Can you review this fix todeprecatesthe |SecurityManager.checkMemberAccess| method as proposed in http://openjdk.java.net/jeps/176? Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/webrev.00 Specdiff: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/specdiff The |checkMemberAccess| method requires the caller?s frame to be at a stack depth of four, which is fragile and difficult to enforce. The fix deprecates the SecurityManager.checkMemberAccess method and will throw an exception unconditionally in a future release.There are several methods in java.lang.Class and the class spec of java.lang.invoke.MethodHandles.Lookup in the JDK specify to call SecurityManager.checkMemberAccess. The spec and implementation are updated to do the appropriate permission check. SecurityManager.checkMemberAccess is not final and it can be overridden by a subclass. However, we believe a SecurityManager subclass implementation that overrides the checkMemberAccess method and behaves differently than the default implementation is very rare. Thus we decide not to handle the SecurityManager subclass case that overrids the checkMemberAccess method with this fix and the compatibility risk should be low. Thanks Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130328/68e3c70c/attachment.html From vincent.x.ryan at oracle.com Fri Mar 29 12:35:03 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 29 Mar 2013 19:35:03 +0000 Subject: code review request: 7171982 Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider In-Reply-To: <5154E793.7050004@oracle.com> References: <514CA985.5080106@oracle.com> <5154B766.5040409@oracle.com> <5154E793.7050004@oracle.com> Message-ID: I overlooked that potential race condition when creating the SunJCE singleton. Both proposed solutions risk the construction of superfluous SunJCE objects. Wouldn't it be better to use the Enum idiom to ensure that multiple SunJCE objects are not constructed? On 29 Mar 2013, at 01:00, Anthony Scarpino wrote: > On 03/28/2013 02:34 PM, Brad Wetmore wrote: >> (Vinnie, what do you think about the SunJCE item below?) >> >> On 3/22/2013 11:57 AM, Anthony Scarpino wrote: >>> Hi all, >>> >>> I need a code review for below webrev. The changes are to have SunJCE >>> call itself, using it's current instance, for checking such things as >>> parameters, instead of searching through the provider list or creating a >>> one time instance. >>> >>> http://cr.openjdk.java.net/~mullan/webrevs/ascarpin/webrev.00/ >> >> PBES1Core.java >> ============== >> 173: indention problem. Should be at the same level as (algo...) >> >> PBES2Core.java:173 >> PKCS12PBECipherCore.java:147 >> SealedObjectForKeyProtector:50/57 >> ======================== >> Indention problem. Normally 4 spaces unless you're trying to line it up >> with something. > > Looks like I need to change netbeans code formatting as I was letting it be my guide for those. > >> >> SealedObjectForKeyProtector.java >> ================================ >> 54/57: In general, you should initCause() everywhere you possibly can. >> This will help people (us) debug the real underlying root cause, >> instead of just the top-level error message. > > Sounds reasonable. > >> >> SunJCE.java >> =========== >> 781: Your code could race during initialization and potentially have >> many SunJCE instances active at once. >> >> Either make instance a volatile (will reduce some of the race >> opportunity), or instead, add locking around assignment/use. You may >> still be creating multiple SunJCEs, but only one instance will ever be >> obtained from getInstance: >> >> synchronized (SunJCE.class) { >> if (instance == null) { >> instance = this; >> } >> } >> >> and >> >> static SunJCE getInstance() { >> if (instance == null) { >> new SunJCE(); >> } >> synchronized (SunJCE.class) { >> return instance; >> } >> } > > I think what you have there creates the situation where if two getInstance()'s were called with instance = null, the second thread to make it through the synchronized call creates a SunJCE object that never gets used and returns the first threads object. > > Maybe it makes sense to make 'instance' volatile, then: > > SunJCE() { ... > if (instance == null) { > instance = this; > } > } > > and > > static SunJCE getInstance() { > if (instance == null) { > return new SunJCE(); > } > return instance; > } > > We don't stop multiple SunJCE objects, not that stopping them was ever the intention of this change, but we reduce their likelihood during a crunch and if they are created, at least they are used before being discarded. > > Tony > >> >> Also, when you get ready to push, be sure to address also the closed >> side: that is, please remember to build/integrate the signed >> sunjce_provider.jar file in the closed repo. >> >> HTH, >> >> Brad >> >> > From valerie.peng at oracle.com Fri Mar 29 17:32:43 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 29 Mar 2013 17:32:43 -0700 Subject: Code Review Request for 7155720: PKCS11 minor issues in native code Message-ID: <515632AB.7080009@oracle.com> Trivial fix - just add null check and OOM error handling for the 2 malloc calls inside src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c. Please find webrev against JDK8 at: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ Thanks, Valerie