Re: Code review request, 8017049: rename property jdk.tls.rejectClientInitializedRenego
Your fix looks good. On 26 Jun 2013, at 04:45, Xuelei Fan wrote: Hi, webrev: http://cr.openjdk.java.net/~xuelei/8017049/webrev.00/ In update of 7188658 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a76858faad59), we defines a new system property, jdk.tls.rejectClientInitializedRenego, in order to disable client initiated renegotiation. However, the name is not instinctive enough according to feedback. We want a name which can more succinctly captures the intent of this property. In this update, the property name is renamed to jdk.tls.rejectClientInitiatedRenegotiation. Thanks, Xuelei
Re: On 8017264: Java app crash on it's startup after Java updated to 7u25 from 7u21
Max,
Is a minidump available (not that I know how to work with them but they
are more reliable than stack traces) ?
I suspect the symbolic information in the stacktrace is reflecting
closest available symbol rather than actual symbol. As you say the
sequence of calls don't really make sense.
David
On 26/06/2013 11:23 AM, Weijun Wang wrote:
Hi, Hotspot guys
We (SE security) received a bug report on a new crash for 7u25 and need
some help from you:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017264
Here the top frames look like:
C [msvcr100.dll+0x10b3b] wcspbrk+0x12d
V [jvm.dll+0xa9b63]
C [w2k_lsa_auth.dll+0x167c] JNI_OnUnload+0x1c1
j
sun.security.krb5.Credentials.acquireDefaultNativeCreds()Lsun/security/krb5/Credentials;+0
acquireDefaultNativeCreds() is a native method and it's defined at
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/3c08c9ebd1fb/src/windows/native/sun/security/krb5/NativeCreds.c
I'm not sure why JNI_OnUnload is called so immediately, and as you can
see it's simply
338 if ((*jvm)-GetEnv(jvm, (void **)env, JNI_VERSION_1_2)) {
339 return; /* Nothing else we can do */
340 }
341
342 if (ticketClass != NULL) {
343 (*env)-DeleteWeakGlobalRef(env,ticketClass);
344 }
... More DeleteWeakGlobalRefs
How is it able to call wcspbrk and get crashed?
BTW, the .c file has not been changed for 2 years.
Also, according to the report, the customer (whose automatic reply has
out of office with no internet access till 15 July) runs 7u25 b16 but
the public release on java.com is b17. Does it matter?
Thanks
Max
Re: On 8017264: Java app crash on it's startup after Java updated to 7u25 from 7u21
Hi David
I'm able to reproduce the problem on my computer and has pinpointed the
exact Win32 API failing: The LSA login function returns a ticket with
size 131074 bytes. Normally a ticket is smaller than several KB. There
must be something wrong.
It's a windows-i586 JRE running on a windows-x64 machine. I tried 7u21
and 8b94 and they all fails. So at least not a regression.
Thanks
Max
On 6/26/13 8:38 PM, David Holmes wrote:
Max,
Is a minidump available (not that I know how to work with them but they
are more reliable than stack traces) ?
I suspect the symbolic information in the stacktrace is reflecting
closest available symbol rather than actual symbol. As you say the
sequence of calls don't really make sense.
David
On 26/06/2013 11:23 AM, Weijun Wang wrote:
Hi, Hotspot guys
We (SE security) received a bug report on a new crash for 7u25 and need
some help from you:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017264
Here the top frames look like:
C [msvcr100.dll+0x10b3b] wcspbrk+0x12d
V [jvm.dll+0xa9b63]
C [w2k_lsa_auth.dll+0x167c] JNI_OnUnload+0x1c1
j
sun.security.krb5.Credentials.acquireDefaultNativeCreds()Lsun/security/krb5/Credentials;+0
acquireDefaultNativeCreds() is a native method and it's defined at
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/3c08c9ebd1fb/src/windows/native/sun/security/krb5/NativeCreds.c
I'm not sure why JNI_OnUnload is called so immediately, and as you can
see it's simply
338 if ((*jvm)-GetEnv(jvm, (void **)env, JNI_VERSION_1_2)) {
339 return; /* Nothing else we can do */
340 }
341
342 if (ticketClass != NULL) {
343 (*env)-DeleteWeakGlobalRef(env,ticketClass);
344 }
... More DeleteWeakGlobalRefs
How is it able to call wcspbrk and get crashed?
BTW, the .c file has not been changed for 2 years.
Also, according to the report, the customer (whose automatic reply has
out of office with no internet access till 15 July) runs 7u25 b16 but
the public release on java.com is b17. Does it matter?
Thanks
Max
hg: jdk8/tl/jdk: 8017049: rename property jdk.tls.rejectClientInitializedRenego
Changeset: 0822bcddbd4f Author:xuelei Date: 2013-06-26 06:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0822bcddbd4f 8017049: rename property jdk.tls.rejectClientInitializedRenego Reviewed-by: vinnie, wetmore, mullan ! src/share/classes/sun/security/ssl/Handshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java
Re: 8017325, 8017326: Cleanup of javadoc code tag
Nithya,
Thanks for catching that. I've labeled the bugs with noreg-doc.
Jason
On 6/25/13 9:25 PM, Nithya Srinivasan wrote:
Jason
Can you please add the appropriate noreg- label for the 2 bugs -
JDK-8017325 JDK-8017326
Thanks
Nithya
On 6/25/2013 1:32 PM, Joe Darcy wrote:
Hi Jason,
The javadoc changes look good to go back.
Thanks,
-Joe
On 6/25/2013 1:23 PM, Jason Uh wrote:
Joe,
Here are the updated webrevs:
- java.security.cert:
http://cr.openjdk.java.net/~juh/8017325/webrev.02/
- java.security.spec:
http://cr.openjdk.java.net/~juh/8017326/webrev.01/
I have converted tt.../tt to {@code ...} and have updated the
copyright dates.
I've attached diffs of the patches to show what has been updated in
these new webrevs. There is a little extra noise in them due to the
change in the timestamps.
Thanks,
Jason
On 06/24/2013 06:11 PM, Joseph Darcy wrote:
On 6/24/2013 3:00 PM, Jason Uh wrote:
On 6/24/13 10:51 AM, Joe Darcy wrote:
Hi Jason,
On 6/21/2013 6:58 PM, Jason Uh wrote:
After learning that javadoc is now capable of properly formatting
the
pre{@code ...}/pre construct, I have updated the changeset for
java.security.cert. Please review instead:
Webrevs --
- java.security.cert (updated):
http://cr.openjdk.java.net/~juh/8017325/webrev.01/
- java.security.spec (no change):
http://cr.openjdk.java.net/~juh/8017326/webrev.00/
I've looked over both patches and they look fine.
However, as a follow-up, please also expand the conversion to include
mapping ttfoo/tt = {@code foo}.
Thanks. I can make those changes, but are you suggesting that I add
them to this changeset or that I do that separately?
For review purposes, I'd like to see them separately in some fashion,
even if it was produced by diffing the patch files.
Note that this change does visibly change the generated javadoc, as
reported by specdiff. In particular, the change to pre{@code
...}/pre in the javadoc for the
X509Extension.getNonCriticalExtensionOIDs() method now allows the
generated HTML to correctly display the line:
SetString nonCritSet = badCert.getNonCriticalExtensionOIDs();
which was previously (incorrectly) displayed as
Set nonCritSet = badCert.getNonCriticalExtensionOIDs();
when the text String was still enclosed within
precode.../code/pre.
Running specdiff is a good double-check in this situation.
Should the scripts you are using here to placed somewhere in the JDK
repo or in the code tools project?
I'm not sure that I follow. Are you requesting that I include
somewhere in the repo the line of Perl that I ran? (It was used to
make most, but not all of these changes.) If so, where would be the
most appropriate place to add that?
If it is a one-liner, it could be included in the summary line of the
commit message or as a comment in the bug. If it is more substantive
(since we will be rolling out this change across the JDK libraries),
having the command in a known-location would be helpful. Especially, if
a check for this pattern is built into future code-quality checks.
-Joe
Thanks,
Jason
Thanks,
-Joe
Thanks,
Jason
The files that have been updated
On 6/21/13 5:47 PM, Jason Uh wrote:
Joe, all,
Could I please get a review of the following changes?
These changesets convert the code.../code javadoc tags to
{@code
...} as part of an overall effort to clean up doclint warnings.
Webrevs --
- java.security.cert:
http://cr.openjdk.java.net/~juh/8017325/webrev.00/
- java.security.spec:
http://cr.openjdk.java.net/~juh/8017326/webrev.00/
specdiff reported no changes in the generated docs.
More of these to come.
Thanks,
Jason
hg: jdk8/tl/jdk: 8013836: getFirstDayOfWeek reports wrong day for pt-BR locale
Changeset: 510035b7 Author:yhuang Date: 2013-06-25 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/510035b7 8013836: getFirstDayOfWeek reports wrong day for pt-BR locale Reviewed-by: naoto + src/share/classes/sun/util/resources/pt/CalendarData_pt_BR.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java
Re: Smart Cards in Java Kerberos
Even easier. Just set useTicketCache=true in the JAAS config. On Jun 25, 2013, at 5:37 PM, Weijun Wang weijun.w...@oracle.com wrote: Java (at least Oracle JDK) does not support PKINIT. Yes, you can do it outside, create a KerberosTicket and a KerberosPrincipal, create a JAAS Subject containing them, and call Subject.doAs() later. It should work. On Windows, if you manage to use Windows' own login and have the ticket stored inside LSA, Java should be able to read it. There is a registry key allowtgtsessionkey you need to take care of. Or maybe you can use any third party kinit to save a ccache file which can also be picked up by Java. --Max On 6/26/13 7:29 AM, Henry B. Hotz wrote: I'm not authoritative, but AFAIK there is no smart card support in Java, though there is pkcs11 support. If I had to do it, I would do the smart card/PKINIT stuff outside Java, and then let Java use the acquired tgt. On Jun 25, 2013, at 5:52 AM, Ostap Andrusiv pifos...@gmail.com wrote: Hi everyone, I've been playing with smart cards and faced some issues. Long story short: Prerequisites: • I set up a basic Kerberos realm via Windows Active Directory. • I managed to successfully login into service via login/password pair using Java Kerberos(Krb5LoginModule), which is provided via JAAS. Now I try to implement Kerberos login via smart card. Smart card preauthentication in Kerberos is done via AS-REQ/AS-REP messages (PA-PK-AS-REQ/P extensions). Unfortunately, JAAS Kerberos hasn't used the smartcard. As far as I have seen, there were no PA-PK-AS-REQ/P extensions in openjdk sources. Maybe, I missed something. Question: 1. Does Java Kerberos support smart card preauthentication out of the box? 2. If it doesn't, can I somehow extends existing Kerberos module or should I implement whole Kerberos from the ground up? Thanks in advance, Ostap Andrusiv web: http://andrusiv.com skype: ostap.andrusiv ::p!F
hg: jdk8/tl/jdk: 8016761: Lambda metafactory - incorrect type conversion of constructor method handle
Changeset: 71059bca036a Author:rfield Date: 2013-06-26 07:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71059bca036a 8016761: Lambda metafactory - incorrect type conversion of constructor method handle Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaConstructorMethodHandleUnbox.java
hg: jdk8/tl/jdk: 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum)
Changeset: e83cdd58f1cf Author:chegar Date: 2013-06-26 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e83cdd58f1cf 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) Reviewed-by: chegar, alanb, psandoz Contributed-by: Doug Lea d...@cs.oswego.edu, Tristan Yan tristan@oracle.com, Chris Hegarty chris.hega...@oracle.com + src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Arrays.java + test/java/util/Arrays/ParallelPrefix.java
Re: getCodeBase broken locally in 7 update 25
Sandeep Konchady sandeep.konchady@... writes: Hi Mickey, The issue you are seeing is intended behavior. This was caused because of a vulnerability that was fixed in 7u25 in which which a getCodeBase call against all local applet/jnlp apps will return null. Thanks, Sandeep On Jun 19, 2013, at 3:18 PM, Mickey Segal ja...@segal.org wrote: The local getCodeBase problem is not present in Java 8 build 94, the most recent version. From: Mickey Segal [mailto:java3 at segal.org] Sent: Wednesday, June 19, 2013 3:56 PMTo: Java Security (security-dev@openjdk.java.net)Subject: RE: getCodeBase broken locally in 7 update 25 The same getCodeBase problem seems to be occurring on the MacOS version too. From: Mickey Segal [mailto:ja...@segal.org] I upgraded a Windows 7 computer to Java version 1.7.0_25 from 1.7.0_21. A getCodeBase call in a signed applet now returns null. In previous versions of Java, getCodeBase returned a URL that referred to the current directory (tested from Java 1.1 to 1.7.0_21 over the years). Was this done purposely for security reasons, or is it just a bug? I will also test on Macintosh and report back on macosx-port-dev if it is a problem there too. Howdy, Is there any more information on this change, such as what security this actually provides? Thanks In Advance, Phillip Thomas
Re: [8] code review request for 7165807: Non optimized initialization of NSS crypto library leads to scalability issues
Thanks for the review Valerie. Comments below. On 26 Jun 2013, at 00:23, Valerie (Yu-Ching) Peng wrote: Secmod.java - The private static native boolean nssInit(...) method should be removed? It seems obsolete by nssInitWithOptions(...) and I didn't see it being used anywhere. Same goes for the corresponding JNI method impl, i.e. Java_sun_security_pkcs11_Secmod_nssInit, in the j2secmod.c file. I considered zapping nssInit() but I wanted to ensure I didn't break anything in the JDK 7 Update release. I can remove it from the JDK 8 version. Config.java - Particular reason to use different variable name, i.e. nssUseOptimizeSpace and property/option name nssOptimizeSpace? It seems inconsistent as most config variable name matches the property/option name. Can't we just use nssOptimizeSpaceacross board? The previous name of the SunPKCS11 configuration flag was 'nssUseOptimizeSpace'. I'll update all the internal references. j2secmod.c - line 127, empty string is used instead of the passed configDir. I am not sure if this correct. Why not just pass the configDir to this call? To be consistent with the NSS native code: it passes an empty string. Lastly, is the NSS_Initialize(...) method always available for the supported NSS library versions, i.e. 3.7+? Is this a newer method meant to replace NSS_Init(...)? It's available in addition to the NSS_Init* functions (not a replacement). Thanks, Valerie On 06/19/13 10:38, Vincent Ryan wrote: Thanks for the review. I've simplified the name of the NSS flag, updated the bug report and filed a doc bug, as you suggest. On 19 Jun 2013, at 18:21, Sean Mullan wrote: Looks good, just a couple of comments: 1. I think the name nssOptimizeSpace is clearer. The Use part seems a bit odd in the property name. 2. Add the appropriate noreg label to the bug. 3. File a followup doc bug to document the attribute in the PKCS11 guide. --Sean On 06/19/2013 08:49 AM, Vincent Ryan wrote: I've made some corrections to the native method that initializes NSS. The new webrev is at: http://cr.openjdk.java.net/~vinnie/7165807/webrev.01 On 14 Jun 2013, at 18:38, Vincent Ryan wrote: Please review the following fix: http://cr.openjdk.java.net/~vinnie/7165807/webrev.00/ http://bugs.sun.com/view_bug.do?bug_id=7165807 NSS may be initialized to favour performance or to favour memory footprint. This fix introduces a new configuration flag to allow Java applications to choose. By default, NSS will be initialized for performance. Thanks.
hg: jdk8/tl/langtools: 8016908: TEST_BUG: removing non-ascii characters causes tests to fail
Changeset: c2d9303c3477 Author:ksrini Date: 2013-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c2d9303c3477 8016908: TEST_BUG: removing non-ascii characters causes tests to fail Reviewed-by: jjg, vromero ! test/tools/javac/api/6437999/T6437999.java - test/tools/javac/api/6437999/Utf8.java ! test/tools/javac/api/T6306137.java
hg: jdk8/tl/jdk: 7018139: Fix HTML accessibility and doclint issues in java.math
Changeset: 1fda8fa7ae97 Author:darcy Date: 2013-06-26 13:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fda8fa7ae97 7018139: Fix HTML accessibility and doclint issues in java.math Reviewed-by: lancea, bpb ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java
Re: [8] code review request for 7165807: Non optimized initialization of NSS crypto library leads to scalability issues
Sure, zapping the nssInit() for only JDK 8 is fine. Being a private static method, I doubt that its removal will break anything though. Thanks, Valerie On 06/26/13 11:38, Vincent Ryan wrote: Thanks for the review Valerie. Comments below. On 26 Jun 2013, at 00:23, Valerie (Yu-Ching) Peng wrote: Secmod.java - The private static native boolean nssInit(...) method should be removed? It seems obsolete by nssInitWithOptions(...) and I didn't see it being used anywhere. Same goes for the corresponding JNI method impl, i.e. Java_sun_security_pkcs11_Secmod_nssInit, in the j2secmod.c file. I considered zapping nssInit() but I wanted to ensure I didn't break anything in the JDK 7 Update release. I can remove it from the JDK 8 version. Config.java - Particular reason to use different variable name, i.e. nssUseOptimizeSpace and property/option name nssOptimizeSpace? It seems inconsistent as most config variable name matches the property/option name. Can't we just use nssOptimizeSpaceacross board? The previous name of the SunPKCS11 configuration flag was 'nssUseOptimizeSpace'. I'll update all the internal references. j2secmod.c - line 127, empty string is used instead of the passed configDir. I am not sure if this correct. Why not just pass the configDir to this call? To be consistent with the NSS native code: it passes an empty string. Lastly, is the NSS_Initialize(...) method always available for the supported NSS library versions, i.e. 3.7+? Is this a newer method meant to replace NSS_Init(...)? It's available in addition to the NSS_Init* functions (not a replacement). Thanks, Valerie On 06/19/13 10:38, Vincent Ryan wrote: Thanks for the review. I've simplified the name of the NSS flag, updated the bug report and filed a doc bug, as you suggest. On 19 Jun 2013, at 18:21, Sean Mullan wrote: Looks good, just a couple of comments: 1. I think the name nssOptimizeSpace is clearer. The Use part seems a bit odd in the property name. 2. Add the appropriate noreg label to the bug. 3. File a followup doc bug to document the attribute in the PKCS11 guide. --Sean On 06/19/2013 08:49 AM, Vincent Ryan wrote: I've made some corrections to the native method that initializes NSS. The new webrev is at: http://cr.openjdk.java.net/~vinnie/7165807/webrev.01 On 14 Jun 2013, at 18:38, Vincent Ryan wrote: Please review the following fix: http://cr.openjdk.java.net/~vinnie/7165807/webrev.00/ http://bugs.sun.com/view_bug.do?bug_id=7165807 NSS may be initialized to favour performance or to favour memory footprint. This fix introduces a new configuration flag to allow Java applications to choose. By default, NSS will be initialized for performance. Thanks.
hg: jdk8/tl/langtools: 8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases with min/max values
Changeset: 3b2e10524627 Author:jjg Date: 2013-06-26 18:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b2e10524627 8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases with min/max values Reviewed-by: jjg, darcy Contributed-by: matherey.nu...@oracle.com ! test/tools/javac/literals/UnderscoreLiterals.java
hg: jdk8/tl/jdk: 8019223: Fix doclint warnings in java.rmi.server
Changeset: a5aa57eb85b6 Author:darcy Date: 2013-06-26 19:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5aa57eb85b6 8019223: Fix doclint warnings in java.rmi.server Reviewed-by: smarks ! src/share/classes/java/rmi/server/RMIClassLoader.java
Review Request: JDK-8019227: JDK-8010325 broke the old build
Brent/Alan/Mike, Hashing.java was removed from the JDK workspace, but was not removed from the old java/java/FILES_java.gmk. Things that still depend on the old build (JCE/deploy) are currently broken. http://cr.openjdk.java.net/~wetmore/8019227/webrev.00/ Brad P.S. I'm very aware that we need to move off the old build soon and am getting closer to finally working on it with Erik, and that the old build isn't complete. But it's complete enough for the JCE dependencies. Unfortunately, this isn't a simple transition (JDK-8006350), and this is a quick fix to get the JCE bits built.
hg: jdk8/tl/langtools: 8014230: Compilation incorrectly succeeds with inner class constructor with 254 parameters
Changeset: c674b396827c Author:emc Date: 2013-06-27 00:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c674b396827c 8014230: Compilation incorrectly succeeds with inner class constructor with 254 parameters Summary: The compiler does not account fr extra parameters due to inner this parameters Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javac/limits/NestedClassConstructorArgs.java + test/tools/javac/limits/NestedClassMethodArgs.java - test/tools/javac/limits/NumArgs1.java - test/tools/javac/limits/NumArgs2.java - test/tools/javac/limits/NumArgs3.java - test/tools/javac/limits/NumArgs4.java + test/tools/javac/limits/NumArgsTest.java + test/tools/javac/limits/StaticNestedClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassMethodArgs.java + test/tools/javac/limits/TopLevelClassStaticMethodArgs.java
hg: jdk8/tl/jdk: 8019228: Fix doclint issues in java.util.zip
Changeset: ac65905883a7 Author:darcy Date: 2013-06-26 22:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac65905883a7 8019228: Fix doclint issues in java.util.zip Reviewed-by: sherman, mchung ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java
