From jim.holmlund at sun.com Tue Nov 1 15:50:55 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 01 Nov 2011 22:50:55 +0000 Subject: hg: jdk8/tl/langtools: 7101933: langtools jtreg tests do not work with jprt on windows Message-ID: <20111101225059.479F9471F7@hg.openjdk.java.net> Changeset: 9e2eb4bc49eb Author: jjh Date: 2011-11-01 15:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9e2eb4bc49eb 7101933: langtools jtreg tests do not work with jprt on windows Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1 and JCK to JCK8. Reviewed-by: jjg, ohair ! test/Makefile From mark.reinhold at oracle.com Tue Nov 1 16:17:37 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 01 Nov 2011 16:17:37 -0700 Subject: JEP 121: Stronger Algorithms for Password-Based Encryption Message-ID: <20111101231737.8967D2E80@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/121 - Mark From tomas at primekey.se Wed Nov 2 02:42:31 2011 From: tomas at primekey.se (Tomas Gustavsson) Date: Wed, 02 Nov 2011 10:42:31 +0100 Subject: Review 7053252: New regression test does not compile on windows-amd64 In-Reply-To: <4EAF2248.1050507@oracle.com> References: <4EAF10DE.4050506@oracle.com> <4EAF2248.1050507@oracle.com> Message-ID: <4EB11087.5040003@primekey.se> Will there ever be a pkcs11 for windows-x64? Cheers, Tomas On 10/31/2011 11:33 PM, Valerie (Yu-Ching) Peng wrote: > Looks good to me. > Valerie > > On 10/31/11 14:19, Brad Wetmore wrote: >> >> Hi Valerie, >> >> http://cr.openjdk.java.net/~wetmore/7053252/ >> >> Review 7053252: New regression test does not compile on windows-amd64 >> >> As you know, there is a broken JDK test on windows-x64 under the >> jdk_security3 target (no pkcs11 library, thus the import fails on >> compile). Someone has to manually check this failure. (Obviously, it >> was me last time, thus the bug! ;) ) >> >> Removing the incorrect import in both jdk7u/jdk8. >> >> Brad >> >> > From valerie.peng at oracle.com Wed Nov 2 16:00:20 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 02 Nov 2011 16:00:20 -0700 Subject: Review 7053252: New regression test does not compile on windows-amd64 In-Reply-To: <4EB11087.5040003@primekey.se> References: <4EAF10DE.4050506@oracle.com> <4EAF2248.1050507@oracle.com> <4EB11087.5040003@primekey.se> Message-ID: <4EB1CB84.5090607@oracle.com> I think so. If you have NSS libs for testing on windows-x64, that'd certainly move our schedule ahead. Regards, Valerie On 11/02/11 02:42, Tomas Gustavsson wrote: > Will there ever be a pkcs11 for windows-x64? > > Cheers, > Tomas > > > On 10/31/2011 11:33 PM, Valerie (Yu-Ching) Peng wrote: > >> Looks good to me. >> Valerie >> >> On 10/31/11 14:19, Brad Wetmore wrote: >> >>> Hi Valerie, >>> >>> http://cr.openjdk.java.net/~wetmore/7053252/ >>> >>> Review 7053252: New regression test does not compile on windows-amd64 >>> >>> As you know, there is a broken JDK test on windows-x64 under the >>> jdk_security3 target (no pkcs11 library, thus the import fails on >>> compile). Someone has to manually check this failure. (Obviously, it >>> was me last time, thus the bug! ;) ) >>> >>> Removing the incorrect import in both jdk7u/jdk8. >>> >>> Brad >>> >>> >>> From mark.reinhold at oracle.com Thu Nov 3 11:15:01 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 03 Nov 2011 11:15:01 -0700 Subject: JEP 123: Configurable Secure Random-Number Generation Message-ID: <20111103181501.B390D26CF@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/123 - Mark From mark.reinhold at oracle.com Thu Nov 3 11:38:53 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 03 Nov 2011 11:38:53 -0700 Subject: JEP 124: Enhance the Certificate Revocation-Checking API Message-ID: <20111103183853.A126326CF@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/124 - Mark From mike.duigou at oracle.com Thu Nov 3 14:00:24 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 03 Nov 2011 21:00:24 +0000 Subject: hg: jdk8/tl/jdk: 4533691: Add Collections.emptySortedSet() Message-ID: <20111103210053.E80D247224@hg.openjdk.java.net> Changeset: 2f2f56ac8b82 Author: mduigou Date: 2011-11-03 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f2f56ac8b82 4533691: Add Collections.emptySortedSet() Reviewed-by: mduigou, alanb, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EmptySortedSet.java From maurizio.cimadamore at oracle.com Fri Nov 4 05:57:22 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 04 Nov 2011 12:57:22 +0000 Subject: hg: jdk8/tl/langtools: 7104201: Refactor DocCommentScanner Message-ID: <20111104125724.B49FB4723F@hg.openjdk.java.net> Changeset: 56830d5cb5bb Author: mcimadamore Date: 2011-11-04 12:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/56830d5cb5bb 7104201: Refactor DocCommentScanner Summary: Add new Comment helper class to parse contents of comments in source code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + test/tools/javac/depDocComment/DeprecatedDocComment4.java + test/tools/javac/depDocComment/DeprecatedDocComment4.out From lana.steuck at oracle.com Sat Nov 5 09:47:07 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:07 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20111105164707.BC4B847253@hg.openjdk.java.net> Changeset: ca977d167697 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ca977d167697 Added tag jdk8-b11 for changeset d1b7a4f6dd20 ! .hgtags Changeset: bcc739229f63 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bcc739229f63 Added tag jdk8-b12 for changeset ca977d167697 ! .hgtags From lana.steuck at oracle.com Sat Nov 5 09:47:07 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:07 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20111105164707.BF55447254@hg.openjdk.java.net> Changeset: 8e2104d565ba Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8e2104d565ba Added tag jdk8-b11 for changeset 1defbc57940a ! .hgtags Changeset: 26fb81a1e9ce Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/26fb81a1e9ce Added tag jdk8-b12 for changeset 8e2104d565ba ! .hgtags From lana.steuck at oracle.com Sat Nov 5 09:47:10 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:10 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20111105164710.BC5BE47255@hg.openjdk.java.net> Changeset: e6eed2ff5d5f Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e6eed2ff5d5f Added tag jdk8-b11 for changeset a12ab897a249 ! .hgtags Changeset: adf2a6b5fde1 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/adf2a6b5fde1 Added tag jdk8-b12 for changeset e6eed2ff5d5f ! .hgtags From lana.steuck at oracle.com Sat Nov 5 09:47:07 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:07 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20111105164712.A8FEC47256@hg.openjdk.java.net> Changeset: 31d70911b712 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/31d70911b712 Added tag jdk8-b11 for changeset 0199e4fef5cc ! .hgtags Changeset: 5b9d9b839d3d Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5b9d9b839d3d Added tag jdk8-b12 for changeset 31d70911b712 ! .hgtags From lana.steuck at oracle.com Sat Nov 5 09:47:25 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:25 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20111105164737.0309147257@hg.openjdk.java.net> Changeset: 8ff85191a7ac Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8ff85191a7ac Added tag jdk8-b11 for changeset 4bf01f1c4e34 ! .hgtags Changeset: 52df2131e294 Author: lana Date: 2011-10-25 21:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/52df2131e294 Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: f2d6ed25857d Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f2d6ed25857d Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: ae25163501bc Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ae25163501bc Added tag jdk8-b12 for changeset f2d6ed25857d ! .hgtags Changeset: 11c184155128 Author: lana Date: 2011-11-05 00:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/11c184155128 Merge From lana.steuck at oracle.com Sat Nov 5 09:47:14 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:14 +0000 Subject: hg: jdk8/tl/hotspot: 34 new changesets Message-ID: <20111105164829.5A42547258@hg.openjdk.java.net> Changeset: bc257a801090 Author: jcoomes Date: 2011-10-14 21:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc257a801090 7101096: Bump the hs23 build number to 03 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 940513efe83a Author: iveresov Date: 2011-10-04 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/940513efe83a 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Summary: Save bci of instruction that produced Goto and use it to call back to runtime Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: ec5ce9326985 Author: kvn Date: 2011-10-04 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec5ce9326985 6865265: JVM crashes with "missing exception handler" error Summary: Retry the call to fast_exception_handler_bci_for() after it returned with a pending exception. Don't cache the exception handler pc computed by compute_compiled_exc_handler() if the handler is for another (nested) exception. Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6865265/StackOverflowBug.java Changeset: eba73e0c7780 Author: bdelsart Date: 2011-10-07 13:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eba73e0c7780 7096366: PPC: corruption of floating-point values with DeoptimizeALot Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms Reviewed-by: roland, dholmes ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 0abefdb54d21 Author: twisti Date: 2011-10-11 02:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0abefdb54d21 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Reviewed-by: never, bdelsart ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp Changeset: 5eb9169b1a14 Author: twisti Date: 2011-10-12 21:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5eb9169b1a14 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp Changeset: a786fdc79c5f Author: never Date: 2011-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a786fdc79c5f 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: kvn, twisti ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 4bac06a82bc3 Author: kvn Date: 2011-10-14 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4bac06a82bc3 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/7100757/Test7100757.java Changeset: 11d17c7d2ee6 Author: iveresov Date: 2011-10-16 02:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11d17c7d2ee6 Merge Changeset: 2ef3386478e6 Author: dholmes Date: 2011-10-10 21:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ef3386478e6 7096278: Update the VM name to indicate it is an embedded build Reviewed-by: kvn, never, jcoomes, bobv ! src/share/vm/runtime/vm_version.cpp Changeset: 436b4a3231bf Author: dcubed Date: 2011-10-13 09:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/436b4a3231bf 7098194: integrate macosx-port changes Summary: Integrate bsd-port/hotspot and macosx-port/hotspot changes as of 2011.09.29. Reviewed-by: kvn, dholmes, never, phh Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller , Alexander Strange , Mike Swingler , Roger Hoover , Victor Hernandez , Pratik Solanki ! .hgignore + agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/symtab.c ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/top.make ! make/bsd/makefiles/vm.make ! make/defs.make - make/templates/bsd-header ! src/cpu/x86/vm/jni_x86.h + src/os/bsd/dtrace/generateJvmOffsets.cpp + src/os/bsd/dtrace/generateJvmOffsets.h + src/os/bsd/dtrace/generateJvmOffsetsMain.c + src/os/bsd/dtrace/hotspot.d + src/os/bsd/dtrace/hotspot_jni.d + src/os/bsd/dtrace/hs_private.d + src/os/bsd/dtrace/jhelper.d + src/os/bsd/dtrace/jvm_dtrace.c + src/os/bsd/dtrace/jvm_dtrace.h + src/os/bsd/dtrace/libjvm_db.c + src/os/bsd/dtrace/libjvm_db.h ! src/os/bsd/vm/dtraceJSDT_bsd.cpp ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/dtrace.hpp + src/share/vm/utilities/dtrace_usdt2_disabled.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/hashtable.cpp Changeset: 23a1c8de9d51 Author: dholmes Date: 2011-10-17 01:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23a1c8de9d51 Merge - make/templates/bsd-header ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: 8187c94a9a87 Author: never Date: 2011-10-17 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8187c94a9a87 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java Changeset: e5928e7dab26 Author: never Date: 2011-10-17 21:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5928e7dab26 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp Changeset: 16f9fa2bf76c Author: kvn Date: 2011-10-19 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16f9fa2bf76c 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations Summary: replace the call to memmove by a simple copy loop Reviewed-by: dholmes, kvn, never Contributed-by: axel.siebenborn at sap.com, volker.simonis at gmail.com ! src/cpu/sparc/vm/copy_sparc.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp + test/runtime/7100935/TestConjointAtomicArraycopy.java + test/runtime/7100935/TestShortArraycopy.java Changeset: 1179647ee175 Author: iveresov Date: 2011-10-21 00:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1179647ee175 Merge Changeset: ec4b032a4977 Author: tonyp Date: 2011-10-13 13:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec4b032a4977 7098085: G1: partially-young GCs not initiated under certain circumstances Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 074f0252cc13 Author: tonyp Date: 2011-10-14 11:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/074f0252cc13 7088680: G1: Cleanup in the G1CollectorPolicy class Summary: Removed unused fields and methods, removed the G1CollectoryPolicy_BestRegionsFirst class and folded its functionality into the G1CollectorPolicy class. Reviewed-by: ysr, brutisso, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/universe.cpp Changeset: bf2d2b8b1726 Author: johnc Date: 2011-10-17 09:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf2d2b8b1726 7095243: Disambiguate ReferenceProcessor::_discoveredSoftRefs Summary: Add a new, separate, pointer to the base of the array of discovered reference lists and use this new pointer in places where we iterate over the entire array. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 647872693572 Author: tonyp Date: 2011-10-21 07:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/647872693572 Merge Changeset: 4d3850d9d326 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4d3850d9d326 Merge - make/templates/bsd-header Changeset: 4538caeef7b6 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4538caeef7b6 Added tag hs23-b03 for changeset 4d3850d9d326 ! .hgtags Changeset: 02fe430d493e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02fe430d493e Added tag jdk8-b11 for changeset 4538caeef7b6 ! .hgtags Changeset: c9d25d93ddfe Author: jcoomes Date: 2011-10-21 16:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9d25d93ddfe 7103619: Bump the hs23 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5e5d4821bf07 Author: brutisso Date: 2011-10-20 10:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e5d4821bf07 7097516: G1: assert(0<= from_card && from_card Changeset: e1f4b4b4b96e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1f4b4b4b96e Added tag jdk8-b11 for changeset 7ab0d613cd1a ! .hgtags Changeset: 7746eb8c610b Author: bae Date: 2011-10-17 15:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7746eb8c610b 6997116: The case automatically failed due to java.lang.ClassCastException. Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/DrawBitmaskToSurfaceTest.java Changeset: a7a001378444 Author: jgodinez Date: 2011-10-24 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7a001378444 6604109: javax.print.PrintServiceLookup.lookupPrintServices fails SOMETIMES for Cups Reviewed-by: bae, prr ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 8f9b0629d088 Author: lana Date: 2011-10-25 21:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f9b0629d088 Merge Changeset: 7814800c64bd Author: lana Date: 2011-10-25 21:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7814800c64bd Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 09fd2067f715 Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09fd2067f715 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: d636e737c478 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d636e737c478 Added tag jdk8-b12 for changeset 09fd2067f715 ! .hgtags Changeset: ead9dabe8c75 Author: lana Date: 2011-11-05 00:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ead9dabe8c75 Merge From weijun.wang at oracle.com Mon Nov 7 02:54:46 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 07 Nov 2011 18:54:46 +0800 Subject: keytool -selfcert fails for MSCAPI Message-ID: <4EB7B8F6.5020809@oracle.com> Hi Vinnie I find a problem with the keytool -selfcert command for MSCAPI. As you know, -selfcert reads the key/cert pair from an entry, updates several fields in the cert, and writes them back to the keystore. However, in MSCAPI's KeyStore, there is public void engineSetKeyEntry(String alias, java.security.Key key, char[] password, Certificate[] chain) throws KeyStoreException { .... if (key instanceof RSAPrivateCrtKey) { .... } else { throw new UnsupportedOperationException( "Cannot assign the key to the given alias."); } So here the key must be a RSAPrivateCrtKey. It will be nice if a sun.security.mscapi.RSAPrivateKey can also be accepted. Thanks Max From weijun.wang at oracle.com Mon Nov 7 03:34:01 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 07 Nov 2011 19:34:01 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert Message-ID: <4EB7C229.7060909@oracle.com> Description: keytool uses CertAndKeyGen to generate a basic self-signed certificate with no extensions. When -ext option was introduced, -genkeypair was implemented as original -genkeypair plus -selfcert, and extensions info was added in the -selfcert step. This means the keystore object is modified twice in this single operation. In the case of PKCS11 or MSCAPI, it is actually written to the token twice. If a token can only be written once, the action will fail. Webrev: http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ No new regression test (noreg-cleanup). Note: NetBeans consolidates the multiple import lines in CertAndKeyGen into one. I'm not against that. Thanks Max From xueming.shen at oracle.com Mon Nov 7 13:43:24 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 07 Nov 2011 21:43:24 +0000 Subject: hg: jdk8/tl/jdk: 7096080: UTF8 update and new CESU-8 charset; ... Message-ID: <20111107214342.E2C4047272@hg.openjdk.java.net> Changeset: 417d91754849 Author: sherman Date: 2011-11-07 13:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/417d91754849 7096080: UTF8 update and new CESU-8 charset 7082884: Incorrect UTF8 conversion for sequence ED 31 7082883: Incorrect UTF8 conversion for sequence fc 80 80 8f bf bf Summary: Updated UTF8 and added CESU-8 to following the latest Standard Reviewed-by: alanb ! make/java/nio/FILES_java.gmk + src/share/classes/sun/nio/cs/CESU_8.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/standard-charsets ! test/java/nio/charset/coders/Errors.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestStringCodingUTF8.java ! test/sun/nio/cs/TestUTF8.java From weijun.wang at oracle.com Mon Nov 7 15:56:52 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 08 Nov 2011 07:56:52 +0800 Subject: UAC in Java Message-ID: <4EB87044.50401@oracle.com> Hi Dennis I recently had some casual talk with a customer and he would like Java to be able to work with Windows UAC nicely. We imagined two ways to do this: 1. The whole webstart app in "elevated" mode: There can be a special flag in the JNLP file. It can take a value of "elevated" or "run-as-admin". When JRE sees it, it pops out a dialog and then run the whole app in the requested mode. 2. Run part of an app in "elevated" mode: Grammatically, this would looks like the AccessController.doPrivileged method, say // normal user mode doUAC(new PrivilegedAction() { public void run() { // do administrative jobs } }); but I doubt if this is possible. First, this doUAC will be a very Windows-only concept and I don't how to express this in a Java preferred way. Second, the running context of normal mode and elevated mode are quite isolated from each other and I wonder how to pass arguments or result between them. Maybe serialization? Any comment? Thanks Max On 11/07/2011 08:00 PM, Henning Horst wrote: > Hi Max, > > thanks for your prompt reply. And sorry for being unclear. > > Users with local administrative Windows 7 / Vista accounts that are also > member of the AD domain do not seem to be able to do Kerberos > negotiation. In the actual situation we have a Java app that is started > with webstart. It is an terminal emulator which then connects via > kerberized SSH to a kerberos capable SSH server. All types of Windows > users are able to run java webstart and start the application. When an > SSH connection is to be established from within the application however, > the Kerberos part of the connection establishment is only successful for > regular users. For local admin users within the domain the Kerberos > handshake via JGSS results in an "Integrity check on decrypted field > failed" error. > > In contrast to starting the application via the browser (which then > calls java ws), if the same administrators run javaws with "Run as > Administrator" from the CMD the app launches successfully (as before) > and they can connect to the kerberized SSH server successfully (in > contrast to the integrity check on decrypted field failed error when not > running javaws with runas). > > When running the "Standard User Analyser" which is recommended by the > MSDN article > > http://msdn.microsoft.com/en-us/library/bb530410.aspx > > describing the UAC "feature" it shows that administrative privileges > seem to be required to access the Kerberos Ticket of a local > administrator within the domain (please see image attached). > > So this seems to correllate with the Windows "feature" that local admins > cannot get the session key for the TGT you wrote about. > > It seems that with UAC domain users that are in the local admin group > only have access to their Kerberos ticket(s) if they use "run as". > > During research I found e.g. > > http://mark.koli.ch/2009/12/uac-prompt-from-java-createprocess-error740-the-requested-operation-requires-elevation.html > > which shows a way how to work around this "feature" by calling a native > program from within Java to trigger the UAC promt and do the privileged > actions. But this should not be the solution, of course. > > So if Microsoft forces this UAC stuff I would think that it would be > possible to trigger that UAC ask for permission dialog from within Java, > say to do the following > > 1) run Java program as regular user > 2) user requests task that requires admin privileges (e.g. to copy a > file to the UAC protected "Program Files" directory) > 3) Java application triggers UAC to ask user for permissions to switch > to administrative user > 4) Java app does privileged work > 5) Java app throws away privileges after task has been completed > successfully > > > Maybe you know something more about the state of play regarding to that > feature (domain users that also are in the local admin group cannot use > Kerberos without "run as") and what Oracle will do about (if something). > > Maybe there is "just" a hidden switch to fix the issue with local admins > within the AD domain not being able to do Kerberos handshakes with JGSS? > > Any help would be very appreciated! > > Thanks again and many regards, > > Henning > > > > On 11/07/2011 11:35 AM, Weijun Wang wrote: >> Hi Henning >> >> I don't quite understand the problem here. >> >> What do you mean Windows administrators cannot run the program? So the >> user is on a local admin group but also a member of an AD domain? I >> don't know why the result is "Kerberos tickets cannot be accessed >> correctly". There was a Windows "feature" that local admins cannot get >> the session key for the TGT, is it still so? >> >> Anyway, I don't know a way to trigger UAC from within Java. If I >> understand correctly, the UAC dialog pops out when some specific >> UAC-related Win32 APIs (or, launch another process) are called. It's not >> that you to use a normal API to access an admin-read-only file and >> suddenly UAC is automatically triggered. >> >> If you are requesting for a general webstart feature (and not >> specifically about JGSS), can you be a little more clear? I'll forward >> the mail to the deployment team. >> >> >> Thanks >> Max >> >> On 11/07/2011 06:16 PM, Henning Horst wrote: >>> Hi Max, >>> >>> some time ago we had some mails back and forth regarding using TCP for >>> KDC communication in which I really appreciated your help and expertise. >>> >>> I am wondering if you could be so kind to give me a hint on the following: >>> >>> Due to our customers upgrading to Windows 7 we run into trouble with >>> using Java Kerberos. This is because due to the new UAC feature of >>> Windows, Windows {Vista,7} administrators cannot run our java webstart >>> app from the browser anymore (Integrity check on decrypted field failed, >>> Kerberos tickets cannot be accessed correctly). From research in the >>> Internet it seems that there is no possibility to trigger the UAC dialog >>> to ask for administrative permissions from within Java. It seems the >>> only way is to use a native helper application with a corresponding >>> manifest file or start java from the console with runas. >>> >>> Is anything planned yet from Oracle how to proceed with that? Will this >>> be handled some time? Or are all vendors required to write their own >>> native wrapper application - which in some sense defies the purpose of java? >>> >>> I would really appreciate your help, even a pointer to the correct >>> resource would be very helpful. >>> >>> Thanks a lot in advance, >>> >>> Henning >>> >>> >>> >>> Henning Horst >>> Systems Analyst >>> comForte 21 GmbH >>> Germany Time zone (GMT +1) >>> >>> h.horst at comforte.com >>> www.comForte.com >>> >>> Phone Germany: +49 (0)461 40 888 09 >>> Mobile: +49 (0)151 2031 5474 >>> >>> comForte 21 GmbH / Steubenstra?e 9 / D-65189 Wiesbaden / Germany >>> phone +49 (0) 611-93199-00 / fax +49 (0) 611-93199-05 / www.comforte.com >>> / info at comforte.com >>> >>> Gesch?ftsf?hrer: Michael Horst, Dr. Michael Rossbach, Michael Weilbacher >>> Sitz der Gesellschaft: Wiesbaden / HRB 25507 >>> ____________________________________________________________ >>> >>> This e-mail may contain confidential and/or privileged information. >>> If you are not the intended recipient (or have received this e-mail >>> in error) please notify the sender immediately and destroy this e-mail. >>> Any unauthorized copying, disclosure or distribution of the material >>> in this e-mail is strictly forbidden. >> From weijun.wang at oracle.com Mon Nov 7 18:41:49 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 7 Nov 2011 18:41:49 -0800 (PST) Subject: code review request: 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Message-ID: <4EB896ED.5090503@oracle.com> Hi Valerie Please review my fix at http://cr.openjdk.java.net/~weijun/7107019/webrev.00/ This is a harmless bug, but it would be nice to code it correct and add some notes. Thanks Max -------- Original Message -------- *Change Request ID*: 7107019 *Synopsis*: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data === *Description* ============================================================ sun.security.krb5.internal.ccache.CCacheInputStream.readCred() AuthorizationDataEntry[] auDataEntry = readAuth(); AuthorizationData auData = null; if (auData != null) { auData = new AuthorizationData(auDataEntry); } Looks like auData should be auDataEntry ============================================================ From xuelei.fan at oracle.com Mon Nov 7 19:19:31 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 08 Nov 2011 11:19:31 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EB7C229.7060909@oracle.com> References: <4EB7C229.7060909@oracle.com> Message-ID: <4EB89FC3.4080909@oracle.com> Looks fine in general. Please make sure all regression tests are passed. Thanks, Xuelei On 11/7/2011 7:34 PM, Weijun Wang wrote: > Description: > > keytool uses CertAndKeyGen to generate a basic self-signed certificate > with no extensions. When -ext option was introduced, -genkeypair was > implemented as original -genkeypair plus -selfcert, and extensions info > was added in the -selfcert step. > > This means the keystore object is modified twice in this single > operation. In the case of PKCS11 or MSCAPI, it is actually written to > the token twice. If a token can only be written once, the action will fail. > > Webrev: > > http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ > > No new regression test (noreg-cleanup). > > Note: NetBeans consolidates the multiple import lines in CertAndKeyGen > into one. I'm not against that. > > Thanks > Max From weijun.wang at oracle.com Mon Nov 7 23:18:47 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 08 Nov 2011 15:18:47 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EB89FC3.4080909@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> Message-ID: <4EB8D7D7.6060004@oracle.com> I only run tests on my Linux before posting the webrev. Then, in the pre-push JPRT run, it fails on all Solaris! Turns out that CertAndKeyGen has public X509Key getPublicKey() { if (!(publicKey instanceof X509Key)) { return null; } return (X509Key)publicKey; } So the public key, which I guess is a P11RSAPublicKey, is now null. I'll try to find a workaround. Thanks Max On 11/08/2011 11:19 AM, Xuelei Fan wrote: > Looks fine in general. Please make sure all regression tests are passed. > > Thanks, > Xuelei > > On 11/7/2011 7:34 PM, Weijun Wang wrote: >> Description: >> >> keytool uses CertAndKeyGen to generate a basic self-signed certificate >> with no extensions. When -ext option was introduced, -genkeypair was >> implemented as original -genkeypair plus -selfcert, and extensions info >> was added in the -selfcert step. >> >> This means the keystore object is modified twice in this single >> operation. In the case of PKCS11 or MSCAPI, it is actually written to >> the token twice. If a token can only be written once, the action will fail. >> >> Webrev: >> >> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >> >> No new regression test (noreg-cleanup). >> >> Note: NetBeans consolidates the multiple import lines in CertAndKeyGen >> into one. I'm not against that. >> >> Thanks >> Max > From weijun.wang at oracle.com Tue Nov 8 00:29:06 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 08 Nov 2011 16:29:06 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EB8D7D7.6060004@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> Message-ID: <4EB8E852.3090308@oracle.com> webrev updated at http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ This time JPRT tests jdk_security3 passes on all platforms. Thanks Max On 11/08/2011 03:18 PM, Weijun Wang wrote: > I only run tests on my Linux before posting the webrev. Then, in the > pre-push JPRT run, it fails on all Solaris! > > Turns out that CertAndKeyGen has > > public X509Key getPublicKey() > { > if (!(publicKey instanceof X509Key)) { > return null; > } > return (X509Key)publicKey; > } > > So the public key, which I guess is a P11RSAPublicKey, is now null. I'll > try to find a workaround. > > Thanks > Max > > > On 11/08/2011 11:19 AM, Xuelei Fan wrote: >> Looks fine in general. Please make sure all regression tests are passed. >> >> Thanks, >> Xuelei >> >> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>> Description: >>> >>> keytool uses CertAndKeyGen to generate a basic self-signed certificate >>> with no extensions. When -ext option was introduced, -genkeypair was >>> implemented as original -genkeypair plus -selfcert, and extensions info >>> was added in the -selfcert step. >>> >>> This means the keystore object is modified twice in this single >>> operation. In the case of PKCS11 or MSCAPI, it is actually written to >>> the token twice. If a token can only be written once, the action will >>> fail. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>> >>> No new regression test (noreg-cleanup). >>> >>> Note: NetBeans consolidates the multiple import lines in CertAndKeyGen >>> into one. I'm not against that. >>> >>> Thanks >>> Max >> From xuelei.fan at oracle.com Tue Nov 8 03:57:49 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 08 Nov 2011 19:57:49 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EB8E852.3090308@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> Message-ID: <4EB9193D.9030806@oracle.com> Did you get any failure report about the CR? I asked the question because I concern about the format of the encoded public key. I'm not sure whether it is always be X.509 or not. If it is not of X.509, we properly cannot calculate the KID properly, and then would be in the risk to chain the AKID, SKID incorrectly. Or if it is not of X.509, we may get another exception during parse public key. If we got complains about the issue, I would suggest you check the encoded format: 179 public PublicKey getPublicKeyAnyway() { + if ((publicKey instanceof X509Key) || + publicKey.getFormat().equalsIgnoreCases("X.509")) { 180 return publicKey; + } + + return null; 181 } If we cannot get the expected public key as expected, I think we proper have to resign it in order to get the public key from signed certificate. Fortunately, our PKCS11 implementation do returns "x.509" format for RSA, DSA, DH and EC public key. And a minor comment: 178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. I think is is not because of Solaris platform, but because of the PKCS11 provider, so that publicKey is not an instance of X509Key. How about: /** * Always returns the public key of the generated key pair. Used * by KeyTool only. * * The publicKey is not necessarily to be an instance of * X509Key in some JCA/JCE providers, for example SunPKCS11. */ BTW, I just noticed that KeyTool does not use AKID in self-signed certificated. It's fine, but personally, I prefer to use both AKID and SKID in all certificates. Xuelei On 11/8/2011 4:29 PM, Weijun Wang wrote: > webrev updated at > > http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ > > This time JPRT tests jdk_security3 passes on all platforms. > > Thanks > Max > > > On 11/08/2011 03:18 PM, Weijun Wang wrote: >> I only run tests on my Linux before posting the webrev. Then, in the >> pre-push JPRT run, it fails on all Solaris! >> >> Turns out that CertAndKeyGen has >> >> public X509Key getPublicKey() >> { >> if (!(publicKey instanceof X509Key)) { >> return null; >> } >> return (X509Key)publicKey; >> } >> >> So the public key, which I guess is a P11RSAPublicKey, is now null. I'll >> try to find a workaround. >> >> Thanks >> Max >> >> >> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>> Looks fine in general. Please make sure all regression tests are passed. >>> >>> Thanks, >>> Xuelei >>> >>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>> Description: >>>> >>>> keytool uses CertAndKeyGen to generate a basic self-signed certificate >>>> with no extensions. When -ext option was introduced, -genkeypair was >>>> implemented as original -genkeypair plus -selfcert, and extensions info >>>> was added in the -selfcert step. >>>> >>>> This means the keystore object is modified twice in this single >>>> operation. In the case of PKCS11 or MSCAPI, it is actually written to >>>> the token twice. If a token can only be written once, the action will >>>> fail. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>> >>>> No new regression test (noreg-cleanup). >>>> >>>> Note: NetBeans consolidates the multiple import lines in CertAndKeyGen >>>> into one. I'm not against that. >>>> >>>> Thanks >>>> Max >>> From mstjohns at comcast.net Tue Nov 8 11:24:35 2011 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 08 Nov 2011 14:24:35 -0500 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EB9193D.9030806@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> <4EB9193D.9030806@oracle.com> Message-ID: <20111108192435.E54456C0E@mail.openjdk.java.net> Looking at the API definitions, it's possible for an RSAPublicKey implementation to have an encoding that is not "X.509". So, the right check really is "publicKey.getFormat().equalsIgnoreCase("X.509") and not "publicKey instanceof RSAPublicKey". No need for the "or" check. Or maybe the instance check is "publicKey instanceof PublicKey" Mike At 06:57 AM 11/8/2011, Xuelei Fan wrote: >Did you get any failure report about the CR? > >I asked the question because I concern about the format of the encoded >public key. I'm not sure whether it is always be X.509 or not. If it is >not of X.509, we properly cannot calculate the KID properly, and then >would be in the risk to chain the AKID, SKID incorrectly. Or if it is >not of X.509, we may get another exception during parse public key. > >If we got complains about the issue, I would suggest you check the >encoded format: > > 179 public PublicKey getPublicKeyAnyway() { > + if ((publicKey instanceof X509Key) || > + publicKey.getFormat().equalsIgnoreCases("X.509")) { > 180 return publicKey; > + } > + > + return null; > 181 } > > >If we cannot get the expected public key as expected, I think we proper >have to resign it in order to get the public key from signed >certificate. Fortunately, our PKCS11 implementation do returns "x.509" >format for RSA, DSA, DH and EC public key. > > >And a minor comment: > >178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. > >I think is is not because of Solaris platform, but because of the PKCS11 >provider, so that publicKey is not an instance of X509Key. How about: > > /** > * Always returns the public key of the generated key pair. Used > * by KeyTool only. > * > * The publicKey is not necessarily to be an instance of > * X509Key in some JCA/JCE providers, for example SunPKCS11. > */ > >BTW, I just noticed that KeyTool does not use AKID in self-signed >certificated. It's fine, but personally, I prefer to use both AKID and >SKID in all certificates. > >Xuelei > >On 11/8/2011 4:29 PM, Weijun Wang wrote: >> webrev updated at >> >> http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ >> >> This time JPRT tests jdk_security3 passes on all platforms. >> >> Thanks >> Max >> >> >> On 11/08/2011 03:18 PM, Weijun Wang wrote: >>> I only run tests on my Linux before posting the webrev. Then, in the >>> pre-push JPRT run, it fails on all Solaris! >>> >>> Turns out that CertAndKeyGen has >>> >>> public X509Key getPublicKey() >>> { >>> if (!(publicKey instanceof X509Key)) { >>> return null; >>> } >>> return (X509Key)publicKey; >>> } >>> >>> So the public key, which I guess is a P11RSAPublicKey, is now null. I'll >>> try to find a workaround. >>> >>> Thanks >>> Max >>> >>> >>> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>>> Looks fine in general. Please make sure all regression tests are passed. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>>> Description: >>>>> >>>>> keytool uses CertAndKeyGen to generate a basic self-signed certificate >>>>> with no extensions. When -ext option was introduced, -genkeypair was >>>>> implemented as original -genkeypair plus -selfcert, and extensions info >>>>> was added in the -selfcert step. >>>>> >>>>> This means the keystore object is modified twice in this single >>>>> operation. In the case of PKCS11 or MSCAPI, it is actually written to >>>>> the token twice. If a token can only be written once, the action will >>>>> fail. >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>>> >>>>> No new regression test (noreg-cleanup). >>>>> >>>>> Note: NetBeans consolidates the multiple import lines in CertAndKeyGen >>>>> into one. I'm not against that. >>>>> >>>>> Thanks >>>>> Max >>>> From jonathan.gibbons at oracle.com Tue Nov 8 11:52:10 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 08 Nov 2011 19:52:10 +0000 Subject: hg: jdk8/tl/langtools: 6921494: provide way to print javac tree tag values Message-ID: <20111108195215.4E9F747298@hg.openjdk.java.net> Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ca49d50318dc 6921494: provide way to print javac tree tag values Reviewed-by: jjg, mcimadamore Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java From valerie.peng at oracle.com Tue Nov 8 17:08:22 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 08 Nov 2011 17:08:22 -0800 Subject: code review request: 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data In-Reply-To: <4EB896ED.5090503@oracle.com> References: <4EB896ED.5090503@oracle.com> Message-ID: <4EB9D286.20406@oracle.com> Looks fine to me. Thanks, Valerie On 11/07/11 18:41, Weijun Wang wrote: > Hi Valerie > > Please review my fix at > > http://cr.openjdk.java.net/~weijun/7107019/webrev.00/ > > This is a harmless bug, but it would be nice to code it correct and > add some notes. > > Thanks > Max > > > -------- Original Message -------- > *Change Request ID*: 7107019 > > *Synopsis*: > sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not > use auth data > > > === *Description* > ============================================================ > sun.security.krb5.internal.ccache.CCacheInputStream.readCred() > > AuthorizationDataEntry[] auDataEntry = readAuth(); > AuthorizationData auData = null; > if (auData != null) { > auData = new AuthorizationData(auDataEntry); > } > > Looks like auData should be auDataEntry > ============================================================ > From jonathan.gibbons at oracle.com Tue Nov 8 17:29:18 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Nov 2011 01:29:18 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111109012923.97C05472A1@hg.openjdk.java.net> Changeset: 36553cb94345 Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36553cb94345 7108668: allow Log to be initialized and used earlier Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: ae361e7f435a Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ae361e7f435a 7108669: cleanup Log methods for direct printing to streams Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java From weijun.wang at oracle.com Tue Nov 8 17:51:19 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 09 Nov 2011 01:51:19 +0000 Subject: hg: jdk8/tl/jdk: 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Message-ID: <20111109015130.0CF22472A2@hg.openjdk.java.net> Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f410b91caf45 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java From weijun.wang at oracle.com Tue Nov 8 19:32:25 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Nov 2011 11:32:25 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <201111081924.pA8JOam3009953@acsinet13.oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> <4EB9193D.9030806@oracle.com> <201111081924.pA8JOam3009953@acsinet13.oracle.com> Message-ID: <4EB9F449.2060902@oracle.com> Well, in fact the whole CertAndKeyGen class already assumes that the public key has an X.509 encoding format. public X509Certificate getSelfCertificate ( X500Name myname, Date firstDate, long validity) ... { .... info.set(X509CertInfo.KEY, new CertificateX509Key(publicKey)); .... and CertificateX509Key.encode() simply calls key.getEncoded() without checking its format. So here is an updated webrev: http://cr.openjdk.java.net/~weijun/7109096/webrev.02/ BTW, I didn't get external report on the failure. But the -selfcert command is now failing on MSCAPI because of some other instanceof checks. Before that gets fixed, I want to take -selfcert out of -genkeypair. -selfcert is an obsolete command but -genkeypair is almost the most important one for keytool. Thanks Max On 11/09/2011 03:24 AM, Michael StJohns wrote: > Looking at the API definitions, it's possible for an RSAPublicKey implementation to have an encoding that is not "X.509". So, the right check really is "publicKey.getFormat().equalsIgnoreCase("X.509") and not "publicKey instanceof RSAPublicKey". No need for the "or" check. Or maybe the instance check is "publicKey instanceof PublicKey" > > Mike > > > > At 06:57 AM 11/8/2011, Xuelei Fan wrote: >> Did you get any failure report about the CR? >> >> I asked the question because I concern about the format of the encoded >> public key. I'm not sure whether it is always be X.509 or not. If it is >> not of X.509, we properly cannot calculate the KID properly, and then >> would be in the risk to chain the AKID, SKID incorrectly. Or if it is >> not of X.509, we may get another exception during parse public key. >> >> If we got complains about the issue, I would suggest you check the >> encoded format: >> >> 179 public PublicKey getPublicKeyAnyway() { >> + if ((publicKey instanceof X509Key) || >> + publicKey.getFormat().equalsIgnoreCases("X.509")) { >> 180 return publicKey; >> + } >> + >> + return null; >> 181 } >> >> >> If we cannot get the expected public key as expected, I think we proper >> have to resign it in order to get the public key from signed >> certificate. Fortunately, our PKCS11 implementation do returns "x.509" >> format for RSA, DSA, DH and EC public key. >> >> >> And a minor comment: >> >> 178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. >> >> I think is is not because of Solaris platform, but because of the PKCS11 >> provider, so that publicKey is not an instance of X509Key. How about: >> >> /** >> * Always returns the public key of the generated key pair. Used >> * by KeyTool only. >> * >> * The publicKey is not necessarily to be an instance of >> * X509Key in some JCA/JCE providers, for example SunPKCS11. >> */ >> >> BTW, I just noticed that KeyTool does not use AKID in self-signed >> certificated. It's fine, but personally, I prefer to use both AKID and >> SKID in all certificates. >> >> Xuelei >> >> On 11/8/2011 4:29 PM, Weijun Wang wrote: >>> webrev updated at >>> >>> http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ >>> >>> This time JPRT tests jdk_security3 passes on all platforms. >>> >>> Thanks >>> Max >>> >>> >>> On 11/08/2011 03:18 PM, Weijun Wang wrote: >>>> I only run tests on my Linux before posting the webrev. Then, in the >>>> pre-push JPRT run, it fails on all Solaris! >>>> >>>> Turns out that CertAndKeyGen has >>>> >>>> public X509Key getPublicKey() >>>> { >>>> if (!(publicKey instanceof X509Key)) { >>>> return null; >>>> } >>>> return (X509Key)publicKey; >>>> } >>>> >>>> So the public key, which I guess is a P11RSAPublicKey, is now null. I'll >>>> try to find a workaround. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>>>> Looks fine in general. Please make sure all regression tests are passed. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>>>> Description: >>>>>> >>>>>> keytool uses CertAndKeyGen to generate a basic self-signed certificate >>>>>> with no extensions. When -ext option was introduced, -genkeypair was >>>>>> implemented as original -genkeypair plus -selfcert, and extensions info >>>>>> was added in the -selfcert step. >>>>>> >>>>>> This means the keystore object is modified twice in this single >>>>>> operation. In the case of PKCS11 or MSCAPI, it is actually written to >>>>>> the token twice. If a token can only be written once, the action will >>>>>> fail. >>>>>> >>>>>> Webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>>>> >>>>>> No new regression test (noreg-cleanup). >>>>>> >>>>>> Note: NetBeans consolidates the multiple import lines in CertAndKeyGen >>>>>> into one. I'm not against that. >>>>>> >>>>>> Thanks >>>>>> Max >>>>> > > From xuelei.fan at oracle.com Tue Nov 8 20:01:10 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Nov 2011 12:01:10 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EB9F449.2060902@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> <4EB9193D.9030806@oracle.com> <201111081924.pA8JOam3009953@acsinet13.oracle.com> <4EB9F449.2060902@oracle.com> Message-ID: <4EB9FB06.3070603@oracle.com> I'm also working on some other CR that need to considering the key format. The key.getFormat() may return null, so the safer comparing should be: + 160 if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { - 160 if (!publicKey.getFormat().equalsIgnoreCase("X.509")) { Otherwise, looks fine to me. Thanks, Xuelei On 11/9/2011 11:32 AM, Weijun Wang wrote: > Well, in fact the whole CertAndKeyGen class already assumes that the > public key has an X.509 encoding format. > > public X509Certificate getSelfCertificate ( > X500Name myname, Date firstDate, long validity) ... > { > .... > info.set(X509CertInfo.KEY, new CertificateX509Key(publicKey)); > .... > > and CertificateX509Key.encode() simply calls key.getEncoded() without > checking its format. > > So here is an updated webrev: > > http://cr.openjdk.java.net/~weijun/7109096/webrev.02/ > > BTW, I didn't get external report on the failure. But the -selfcert > command is now failing on MSCAPI because of some other instanceof > checks. Before that gets fixed, I want to take -selfcert out of > -genkeypair. -selfcert is an obsolete command but -genkeypair is almost > the most important one for keytool. > > Thanks > Max > > > On 11/09/2011 03:24 AM, Michael StJohns wrote: >> Looking at the API definitions, it's possible for an RSAPublicKey >> implementation to have an encoding that is not "X.509". So, the >> right check really is "publicKey.getFormat().equalsIgnoreCase("X.509") >> and not "publicKey instanceof RSAPublicKey". No need for the "or" >> check. Or maybe the instance check is "publicKey instanceof PublicKey" >> >> Mike >> >> >> >> At 06:57 AM 11/8/2011, Xuelei Fan wrote: >>> Did you get any failure report about the CR? >>> >>> I asked the question because I concern about the format of the encoded >>> public key. I'm not sure whether it is always be X.509 or not. If it is >>> not of X.509, we properly cannot calculate the KID properly, and then >>> would be in the risk to chain the AKID, SKID incorrectly. Or if it is >>> not of X.509, we may get another exception during parse public key. >>> >>> If we got complains about the issue, I would suggest you check the >>> encoded format: >>> >>> 179 public PublicKey getPublicKeyAnyway() { >>> + if ((publicKey instanceof X509Key) || >>> + publicKey.getFormat().equalsIgnoreCases("X.509")) { >>> 180 return publicKey; >>> + } >>> + >>> + return null; >>> 181 } >>> >>> >>> If we cannot get the expected public key as expected, I think we proper >>> have to resign it in order to get the public key from signed >>> certificate. Fortunately, our PKCS11 implementation do returns "x.509" >>> format for RSA, DSA, DH and EC public key. >>> >>> >>> And a minor comment: >>> >>> 178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. >>> >>> I think is is not because of Solaris platform, but because of the PKCS11 >>> provider, so that publicKey is not an instance of X509Key. How about: >>> >>> /** >>> * Always returns the public key of the generated key pair. Used >>> * by KeyTool only. >>> * >>> * The publicKey is not necessarily to be an instance of >>> * X509Key in some JCA/JCE providers, for example SunPKCS11. >>> */ >>> >>> BTW, I just noticed that KeyTool does not use AKID in self-signed >>> certificated. It's fine, but personally, I prefer to use both AKID and >>> SKID in all certificates. >>> >>> Xuelei >>> >>> On 11/8/2011 4:29 PM, Weijun Wang wrote: >>>> webrev updated at >>>> >>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ >>>> >>>> This time JPRT tests jdk_security3 passes on all platforms. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 11/08/2011 03:18 PM, Weijun Wang wrote: >>>>> I only run tests on my Linux before posting the webrev. Then, in the >>>>> pre-push JPRT run, it fails on all Solaris! >>>>> >>>>> Turns out that CertAndKeyGen has >>>>> >>>>> public X509Key getPublicKey() >>>>> { >>>>> if (!(publicKey instanceof X509Key)) { >>>>> return null; >>>>> } >>>>> return (X509Key)publicKey; >>>>> } >>>>> >>>>> So the public key, which I guess is a P11RSAPublicKey, is now null. >>>>> I'll >>>>> try to find a workaround. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>>>>> Looks fine in general. Please make sure all regression tests are >>>>>> passed. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>>>>> Description: >>>>>>> >>>>>>> keytool uses CertAndKeyGen to generate a basic self-signed >>>>>>> certificate >>>>>>> with no extensions. When -ext option was introduced, -genkeypair was >>>>>>> implemented as original -genkeypair plus -selfcert, and >>>>>>> extensions info >>>>>>> was added in the -selfcert step. >>>>>>> >>>>>>> This means the keystore object is modified twice in this single >>>>>>> operation. In the case of PKCS11 or MSCAPI, it is actually >>>>>>> written to >>>>>>> the token twice. If a token can only be written once, the action >>>>>>> will >>>>>>> fail. >>>>>>> >>>>>>> Webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>>>>> >>>>>>> No new regression test (noreg-cleanup). >>>>>>> >>>>>>> Note: NetBeans consolidates the multiple import lines in >>>>>>> CertAndKeyGen >>>>>>> into one. I'm not against that. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>> >> >> From xuelei.fan at oracle.com Tue Nov 8 20:53:59 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Nov 2011 12:53:59 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EB9FB06.3070603@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> <4EB9193D.9030806@oracle.com> <201111081924.pA8JOam3009953@acsinet13.oracle.com> <4EB9F449.2060902@oracle.com> <4EB9FB06.3070603@oracle.com> Message-ID: <4EBA0767.803@oracle.com> One more comment that I'm not sure why you come to the conclusion that CertAndKeyGen has already assumed that the public key is of X.509 format. And what did you want to show with the example of getSelfCertificate() method? I did not find it is useful to come to the above conclusion. I'm not sure who are the caller of getPublicKey() and generate(). Conservatively, I think it would be safer to make the check in getPublicKeyAnyway() instead of generate(). Just my 0.2 cents. Xuelei On 11/9/2011 12:01 PM, Xuelei Fan wrote: > I'm also working on some other CR that need to considering the key > format. The key.getFormat() may return null, so the safer comparing > should be: > > + 160 if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { > - 160 if (!publicKey.getFormat().equalsIgnoreCase("X.509")) { > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > On 11/9/2011 11:32 AM, Weijun Wang wrote: >> Well, in fact the whole CertAndKeyGen class already assumes that the >> public key has an X.509 encoding format. >> >> public X509Certificate getSelfCertificate ( >> X500Name myname, Date firstDate, long validity) ... >> { >> .... >> info.set(X509CertInfo.KEY, new CertificateX509Key(publicKey)); >> .... >> >> and CertificateX509Key.encode() simply calls key.getEncoded() without >> checking its format. >> >> So here is an updated webrev: >> >> http://cr.openjdk.java.net/~weijun/7109096/webrev.02/ >> >> BTW, I didn't get external report on the failure. But the -selfcert >> command is now failing on MSCAPI because of some other instanceof >> checks. Before that gets fixed, I want to take -selfcert out of >> -genkeypair. -selfcert is an obsolete command but -genkeypair is almost >> the most important one for keytool. >> >> Thanks >> Max >> >> >> On 11/09/2011 03:24 AM, Michael StJohns wrote: >>> Looking at the API definitions, it's possible for an RSAPublicKey >>> implementation to have an encoding that is not "X.509". So, the >>> right check really is "publicKey.getFormat().equalsIgnoreCase("X.509") >>> and not "publicKey instanceof RSAPublicKey". No need for the "or" >>> check. Or maybe the instance check is "publicKey instanceof PublicKey" >>> >>> Mike >>> >>> >>> >>> At 06:57 AM 11/8/2011, Xuelei Fan wrote: >>>> Did you get any failure report about the CR? >>>> >>>> I asked the question because I concern about the format of the encoded >>>> public key. I'm not sure whether it is always be X.509 or not. If it is >>>> not of X.509, we properly cannot calculate the KID properly, and then >>>> would be in the risk to chain the AKID, SKID incorrectly. Or if it is >>>> not of X.509, we may get another exception during parse public key. >>>> >>>> If we got complains about the issue, I would suggest you check the >>>> encoded format: >>>> >>>> 179 public PublicKey getPublicKeyAnyway() { >>>> + if ((publicKey instanceof X509Key) || >>>> + publicKey.getFormat().equalsIgnoreCases("X.509")) { >>>> 180 return publicKey; >>>> + } >>>> + >>>> + return null; >>>> 181 } >>>> >>>> >>>> If we cannot get the expected public key as expected, I think we proper >>>> have to resign it in order to get the public key from signed >>>> certificate. Fortunately, our PKCS11 implementation do returns "x.509" >>>> format for RSA, DSA, DH and EC public key. >>>> >>>> >>>> And a minor comment: >>>> >>>> 178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. >>>> >>>> I think is is not because of Solaris platform, but because of the PKCS11 >>>> provider, so that publicKey is not an instance of X509Key. How about: >>>> >>>> /** >>>> * Always returns the public key of the generated key pair. Used >>>> * by KeyTool only. >>>> * >>>> * The publicKey is not necessarily to be an instance of >>>> * X509Key in some JCA/JCE providers, for example SunPKCS11. >>>> */ >>>> >>>> BTW, I just noticed that KeyTool does not use AKID in self-signed >>>> certificated. It's fine, but personally, I prefer to use both AKID and >>>> SKID in all certificates. >>>> >>>> Xuelei >>>> >>>> On 11/8/2011 4:29 PM, Weijun Wang wrote: >>>>> webrev updated at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ >>>>> >>>>> This time JPRT tests jdk_security3 passes on all platforms. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 11/08/2011 03:18 PM, Weijun Wang wrote: >>>>>> I only run tests on my Linux before posting the webrev. Then, in the >>>>>> pre-push JPRT run, it fails on all Solaris! >>>>>> >>>>>> Turns out that CertAndKeyGen has >>>>>> >>>>>> public X509Key getPublicKey() >>>>>> { >>>>>> if (!(publicKey instanceof X509Key)) { >>>>>> return null; >>>>>> } >>>>>> return (X509Key)publicKey; >>>>>> } >>>>>> >>>>>> So the public key, which I guess is a P11RSAPublicKey, is now null. >>>>>> I'll >>>>>> try to find a workaround. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>>>>>> Looks fine in general. Please make sure all regression tests are >>>>>>> passed. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>>>>>> Description: >>>>>>>> >>>>>>>> keytool uses CertAndKeyGen to generate a basic self-signed >>>>>>>> certificate >>>>>>>> with no extensions. When -ext option was introduced, -genkeypair was >>>>>>>> implemented as original -genkeypair plus -selfcert, and >>>>>>>> extensions info >>>>>>>> was added in the -selfcert step. >>>>>>>> >>>>>>>> This means the keystore object is modified twice in this single >>>>>>>> operation. In the case of PKCS11 or MSCAPI, it is actually >>>>>>>> written to >>>>>>>> the token twice. If a token can only be written once, the action >>>>>>>> will >>>>>>>> fail. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>>>>>> >>>>>>>> No new regression test (noreg-cleanup). >>>>>>>> >>>>>>>> Note: NetBeans consolidates the multiple import lines in >>>>>>>> CertAndKeyGen >>>>>>>> into one. I'm not against that. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>> >>> >>> > From weijun.wang at oracle.com Tue Nov 8 21:15:09 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Nov 2011 13:15:09 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EBA0767.803@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> <4EB9193D.9030806@oracle.com> <201111081924.pA8JOam3009953@acsinet13.oracle.com> <4EB9F449.2060902@oracle.com> <4EB9FB06.3070603@oracle.com> <4EBA0767.803@oracle.com> Message-ID: <4EBA0C5D.1090505@oracle.com> The CertAndKeyGen class is for generating a keypair and create a certificate or cert request. The normal usage for it will be 1. create an object 2. call generate() to generate keypair 3. call getSelfCertificate or getCertRequest Both methods in step 3 assume the publicKey to be X.509 encoded. Of course, one can only call the first 2 steps and do not go on. But in order to do that, a simple KeyPairGenerator is enough. I still think the current webrev.02 is correct. Yes, I can move the check back to getPublicKeyAnyway(). Or you can say the check is completely useless, because at least we are very sure in KeyTool that if the format is not X.509, something bad will happen anyway when we call getSelfCertificate. Maybe an assert statement is better. -Max On 11/09/2011 12:53 PM, Xuelei Fan wrote: > One more comment that I'm not sure why you come to the conclusion that > CertAndKeyGen has already assumed that the public key is of X.509 format. > > And what did you want to show with the example of getSelfCertificate() > method? I did not find it is useful to come to the above conclusion. > > I'm not sure who are the caller of getPublicKey() and generate(). > Conservatively, I think it would be safer to make the check in > getPublicKeyAnyway() instead of generate(). > > Just my 0.2 cents. > > Xuelei > > On 11/9/2011 12:01 PM, Xuelei Fan wrote: >> I'm also working on some other CR that need to considering the key >> format. The key.getFormat() may return null, so the safer comparing >> should be: >> >> + 160 if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { >> - 160 if (!publicKey.getFormat().equalsIgnoreCase("X.509")) { >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> On 11/9/2011 11:32 AM, Weijun Wang wrote: >>> Well, in fact the whole CertAndKeyGen class already assumes that the >>> public key has an X.509 encoding format. >>> >>> public X509Certificate getSelfCertificate ( >>> X500Name myname, Date firstDate, long validity) ... >>> { >>> .... >>> info.set(X509CertInfo.KEY, new CertificateX509Key(publicKey)); >>> .... >>> >>> and CertificateX509Key.encode() simply calls key.getEncoded() without >>> checking its format. >>> >>> So here is an updated webrev: >>> >>> http://cr.openjdk.java.net/~weijun/7109096/webrev.02/ >>> >>> BTW, I didn't get external report on the failure. But the -selfcert >>> command is now failing on MSCAPI because of some other instanceof >>> checks. Before that gets fixed, I want to take -selfcert out of >>> -genkeypair. -selfcert is an obsolete command but -genkeypair is almost >>> the most important one for keytool. >>> >>> Thanks >>> Max >>> >>> >>> On 11/09/2011 03:24 AM, Michael StJohns wrote: >>>> Looking at the API definitions, it's possible for an RSAPublicKey >>>> implementation to have an encoding that is not "X.509". So, the >>>> right check really is "publicKey.getFormat().equalsIgnoreCase("X.509") >>>> and not "publicKey instanceof RSAPublicKey". No need for the "or" >>>> check. Or maybe the instance check is "publicKey instanceof PublicKey" >>>> >>>> Mike >>>> >>>> >>>> >>>> At 06:57 AM 11/8/2011, Xuelei Fan wrote: >>>>> Did you get any failure report about the CR? >>>>> >>>>> I asked the question because I concern about the format of the encoded >>>>> public key. I'm not sure whether it is always be X.509 or not. If it is >>>>> not of X.509, we properly cannot calculate the KID properly, and then >>>>> would be in the risk to chain the AKID, SKID incorrectly. Or if it is >>>>> not of X.509, we may get another exception during parse public key. >>>>> >>>>> If we got complains about the issue, I would suggest you check the >>>>> encoded format: >>>>> >>>>> 179 public PublicKey getPublicKeyAnyway() { >>>>> + if ((publicKey instanceof X509Key) || >>>>> + publicKey.getFormat().equalsIgnoreCases("X.509")) { >>>>> 180 return publicKey; >>>>> + } >>>>> + >>>>> + return null; >>>>> 181 } >>>>> >>>>> >>>>> If we cannot get the expected public key as expected, I think we proper >>>>> have to resign it in order to get the public key from signed >>>>> certificate. Fortunately, our PKCS11 implementation do returns "x.509" >>>>> format for RSA, DSA, DH and EC public key. >>>>> >>>>> >>>>> And a minor comment: >>>>> >>>>> 178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. >>>>> >>>>> I think is is not because of Solaris platform, but because of the PKCS11 >>>>> provider, so that publicKey is not an instance of X509Key. How about: >>>>> >>>>> /** >>>>> * Always returns the public key of the generated key pair. Used >>>>> * by KeyTool only. >>>>> * >>>>> * The publicKey is not necessarily to be an instance of >>>>> * X509Key in some JCA/JCE providers, for example SunPKCS11. >>>>> */ >>>>> >>>>> BTW, I just noticed that KeyTool does not use AKID in self-signed >>>>> certificated. It's fine, but personally, I prefer to use both AKID and >>>>> SKID in all certificates. >>>>> >>>>> Xuelei >>>>> >>>>> On 11/8/2011 4:29 PM, Weijun Wang wrote: >>>>>> webrev updated at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ >>>>>> >>>>>> This time JPRT tests jdk_security3 passes on all platforms. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 11/08/2011 03:18 PM, Weijun Wang wrote: >>>>>>> I only run tests on my Linux before posting the webrev. Then, in the >>>>>>> pre-push JPRT run, it fails on all Solaris! >>>>>>> >>>>>>> Turns out that CertAndKeyGen has >>>>>>> >>>>>>> public X509Key getPublicKey() >>>>>>> { >>>>>>> if (!(publicKey instanceof X509Key)) { >>>>>>> return null; >>>>>>> } >>>>>>> return (X509Key)publicKey; >>>>>>> } >>>>>>> >>>>>>> So the public key, which I guess is a P11RSAPublicKey, is now null. >>>>>>> I'll >>>>>>> try to find a workaround. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>>>>>>> Looks fine in general. Please make sure all regression tests are >>>>>>>> passed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>>>>>>> Description: >>>>>>>>> >>>>>>>>> keytool uses CertAndKeyGen to generate a basic self-signed >>>>>>>>> certificate >>>>>>>>> with no extensions. When -ext option was introduced, -genkeypair was >>>>>>>>> implemented as original -genkeypair plus -selfcert, and >>>>>>>>> extensions info >>>>>>>>> was added in the -selfcert step. >>>>>>>>> >>>>>>>>> This means the keystore object is modified twice in this single >>>>>>>>> operation. In the case of PKCS11 or MSCAPI, it is actually >>>>>>>>> written to >>>>>>>>> the token twice. If a token can only be written once, the action >>>>>>>>> will >>>>>>>>> fail. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>>>>>>> >>>>>>>>> No new regression test (noreg-cleanup). >>>>>>>>> >>>>>>>>> Note: NetBeans consolidates the multiple import lines in >>>>>>>>> CertAndKeyGen >>>>>>>>> into one. I'm not against that. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>> >>>> >>>> >> > From xuelei.fan at oracle.com Tue Nov 8 21:36:42 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Nov 2011 13:36:42 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EBA0C5D.1090505@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> <4EB9193D.9030806@oracle.com> <201111081924.pA8JOam3009953@acsinet13.oracle.com> <4EB9F449.2060902@oracle.com> <4EB9FB06.3070603@oracle.com> <4EBA0767.803@oracle.com> <4EBA0C5D.1090505@oracle.com> Message-ID: <4EBA116A.8030208@oracle.com> >>>>>> Fortunately, our PKCS11 implementation do returns "x.509" >>>>>> format for RSA, DSA, DH and EC public key. Please go with your latest update. Please pay attention that publicKey.getFormat() may be null. Xuelei On 11/9/2011 1:15 PM, Weijun Wang wrote: > The CertAndKeyGen class is for generating a keypair and create a > certificate or cert request. The normal usage for it will be > > 1. create an object > 2. call generate() to generate keypair > 3. call getSelfCertificate or getCertRequest > > Both methods in step 3 assume the publicKey to be X.509 encoded. > > Of course, one can only call the first 2 steps and do not go on. But in > order to do that, a simple KeyPairGenerator is enough. > > I still think the current webrev.02 is correct. Yes, I can move the > check back to getPublicKeyAnyway(). Or you can say the check is > completely useless, because at least we are very sure in KeyTool that if > the format is not X.509, something bad will happen anyway when we call > getSelfCertificate. Maybe an assert statement is better. > > -Max > > On 11/09/2011 12:53 PM, Xuelei Fan wrote: >> One more comment that I'm not sure why you come to the conclusion that >> CertAndKeyGen has already assumed that the public key is of X.509 format. >> >> And what did you want to show with the example of getSelfCertificate() >> method? I did not find it is useful to come to the above conclusion. >> >> I'm not sure who are the caller of getPublicKey() and generate(). >> Conservatively, I think it would be safer to make the check in >> getPublicKeyAnyway() instead of generate(). >> >> Just my 0.2 cents. >> >> Xuelei >> >> On 11/9/2011 12:01 PM, Xuelei Fan wrote: >>> I'm also working on some other CR that need to considering the key >>> format. The key.getFormat() may return null, so the safer comparing >>> should be: >>> >>> + 160 if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { >>> - 160 if (!publicKey.getFormat().equalsIgnoreCase("X.509")) { >>> >>> Otherwise, looks fine to me. >>> >>> Thanks, >>> Xuelei >>> >>> On 11/9/2011 11:32 AM, Weijun Wang wrote: >>>> Well, in fact the whole CertAndKeyGen class already assumes that the >>>> public key has an X.509 encoding format. >>>> >>>> public X509Certificate getSelfCertificate ( >>>> X500Name myname, Date firstDate, long validity) ... >>>> { >>>> .... >>>> info.set(X509CertInfo.KEY, new >>>> CertificateX509Key(publicKey)); >>>> .... >>>> >>>> and CertificateX509Key.encode() simply calls key.getEncoded() without >>>> checking its format. >>>> >>>> So here is an updated webrev: >>>> >>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.02/ >>>> >>>> BTW, I didn't get external report on the failure. But the -selfcert >>>> command is now failing on MSCAPI because of some other instanceof >>>> checks. Before that gets fixed, I want to take -selfcert out of >>>> -genkeypair. -selfcert is an obsolete command but -genkeypair is almost >>>> the most important one for keytool. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 11/09/2011 03:24 AM, Michael StJohns wrote: >>>>> Looking at the API definitions, it's possible for an RSAPublicKey >>>>> implementation to have an encoding that is not "X.509". So, the >>>>> right check really is "publicKey.getFormat().equalsIgnoreCase("X.509") >>>>> and not "publicKey instanceof RSAPublicKey". No need for the "or" >>>>> check. Or maybe the instance check is "publicKey instanceof >>>>> PublicKey" >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> At 06:57 AM 11/8/2011, Xuelei Fan wrote: >>>>>> Did you get any failure report about the CR? >>>>>> >>>>>> I asked the question because I concern about the format of the >>>>>> encoded >>>>>> public key. I'm not sure whether it is always be X.509 or not. If >>>>>> it is >>>>>> not of X.509, we properly cannot calculate the KID properly, and then >>>>>> would be in the risk to chain the AKID, SKID incorrectly. Or if it is >>>>>> not of X.509, we may get another exception during parse public key. >>>>>> >>>>>> If we got complains about the issue, I would suggest you check the >>>>>> encoded format: >>>>>> >>>>>> 179 public PublicKey getPublicKeyAnyway() { >>>>>> + if ((publicKey instanceof X509Key) || >>>>>> + publicKey.getFormat().equalsIgnoreCases("X.509")) { >>>>>> 180 return publicKey; >>>>>> + } >>>>>> + >>>>>> + return null; >>>>>> 181 } >>>>>> >>>>>> >>>>>> If we cannot get the expected public key as expected, I think we >>>>>> proper >>>>>> have to resign it in order to get the public key from signed >>>>>> certificate. Fortunately, our PKCS11 implementation do returns >>>>>> "x.509" >>>>>> format for RSA, DSA, DH and EC public key. >>>>>> >>>>>> >>>>>> And a minor comment: >>>>>> >>>>>> 178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. >>>>>> >>>>>> I think is is not because of Solaris platform, but because of the >>>>>> PKCS11 >>>>>> provider, so that publicKey is not an instance of X509Key. How about: >>>>>> >>>>>> /** >>>>>> * Always returns the public key of the generated key pair. >>>>>> Used >>>>>> * by KeyTool only. >>>>>> * >>>>>> * The publicKey is not necessarily to be an instance of >>>>>> * X509Key in some JCA/JCE providers, for example SunPKCS11. >>>>>> */ >>>>>> >>>>>> BTW, I just noticed that KeyTool does not use AKID in self-signed >>>>>> certificated. It's fine, but personally, I prefer to use both AKID >>>>>> and >>>>>> SKID in all certificates. >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 11/8/2011 4:29 PM, Weijun Wang wrote: >>>>>>> webrev updated at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ >>>>>>> >>>>>>> This time JPRT tests jdk_security3 passes on all platforms. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 11/08/2011 03:18 PM, Weijun Wang wrote: >>>>>>>> I only run tests on my Linux before posting the webrev. Then, in >>>>>>>> the >>>>>>>> pre-push JPRT run, it fails on all Solaris! >>>>>>>> >>>>>>>> Turns out that CertAndKeyGen has >>>>>>>> >>>>>>>> public X509Key getPublicKey() >>>>>>>> { >>>>>>>> if (!(publicKey instanceof X509Key)) { >>>>>>>> return null; >>>>>>>> } >>>>>>>> return (X509Key)publicKey; >>>>>>>> } >>>>>>>> >>>>>>>> So the public key, which I guess is a P11RSAPublicKey, is now null. >>>>>>>> I'll >>>>>>>> try to find a workaround. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>>>>>>>> Looks fine in general. Please make sure all regression tests are >>>>>>>>> passed. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>>>>>>>> Description: >>>>>>>>>> >>>>>>>>>> keytool uses CertAndKeyGen to generate a basic self-signed >>>>>>>>>> certificate >>>>>>>>>> with no extensions. When -ext option was introduced, >>>>>>>>>> -genkeypair was >>>>>>>>>> implemented as original -genkeypair plus -selfcert, and >>>>>>>>>> extensions info >>>>>>>>>> was added in the -selfcert step. >>>>>>>>>> >>>>>>>>>> This means the keystore object is modified twice in this single >>>>>>>>>> operation. In the case of PKCS11 or MSCAPI, it is actually >>>>>>>>>> written to >>>>>>>>>> the token twice. If a token can only be written once, the action >>>>>>>>>> will >>>>>>>>>> fail. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>>>>>>>> >>>>>>>>>> No new regression test (noreg-cleanup). >>>>>>>>>> >>>>>>>>>> Note: NetBeans consolidates the multiple import lines in >>>>>>>>>> CertAndKeyGen >>>>>>>>>> into one. I'm not against that. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>> >>>>> >>>>> >>> >> From weijun.wang at oracle.com Tue Nov 8 21:54:04 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Nov 2011 13:54:04 +0800 Subject: code review request: 7109096: keytool -genkeypair needn't call -selfcert In-Reply-To: <4EBA116A.8030208@oracle.com> References: <4EB7C229.7060909@oracle.com> <4EB89FC3.4080909@oracle.com> <4EB8D7D7.6060004@oracle.com> <4EB8E852.3090308@oracle.com> <4EB9193D.9030806@oracle.com> <201111081924.pA8JOam3009953@acsinet13.oracle.com> <4EB9F449.2060902@oracle.com> <4EB9FB06.3070603@oracle.com> <4EBA0767.803@oracle.com> <4EBA0C5D.1090505@oracle.com> <4EBA116A.8030208@oracle.com> Message-ID: <4EBA157C.8000904@oracle.com> On 11/09/2011 01:36 PM, Xuelei Fan wrote: >>>>>>> Fortunately, our PKCS11 implementation do returns "x.509" >>>>>>> format for RSA, DSA, DH and EC public key. > Please go with your latest update. Please pay attention that > publicKey.getFormat() may be null. OK. I'll reverse the order. Thanks Max > > Xuelei > > On 11/9/2011 1:15 PM, Weijun Wang wrote: >> The CertAndKeyGen class is for generating a keypair and create a >> certificate or cert request. The normal usage for it will be >> >> 1. create an object >> 2. call generate() to generate keypair >> 3. call getSelfCertificate or getCertRequest >> >> Both methods in step 3 assume the publicKey to be X.509 encoded. >> >> Of course, one can only call the first 2 steps and do not go on. But in >> order to do that, a simple KeyPairGenerator is enough. >> >> I still think the current webrev.02 is correct. Yes, I can move the >> check back to getPublicKeyAnyway(). Or you can say the check is >> completely useless, because at least we are very sure in KeyTool that if >> the format is not X.509, something bad will happen anyway when we call >> getSelfCertificate. Maybe an assert statement is better. >> >> -Max >> >> On 11/09/2011 12:53 PM, Xuelei Fan wrote: >>> One more comment that I'm not sure why you come to the conclusion that >>> CertAndKeyGen has already assumed that the public key is of X.509 format. >>> >>> And what did you want to show with the example of getSelfCertificate() >>> method? I did not find it is useful to come to the above conclusion. >>> >>> I'm not sure who are the caller of getPublicKey() and generate(). >>> Conservatively, I think it would be safer to make the check in >>> getPublicKeyAnyway() instead of generate(). >>> >>> Just my 0.2 cents. >>> >>> Xuelei >>> >>> On 11/9/2011 12:01 PM, Xuelei Fan wrote: >>>> I'm also working on some other CR that need to considering the key >>>> format. The key.getFormat() may return null, so the safer comparing >>>> should be: >>>> >>>> + 160 if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { >>>> - 160 if (!publicKey.getFormat().equalsIgnoreCase("X.509")) { >>>> >>>> Otherwise, looks fine to me. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/9/2011 11:32 AM, Weijun Wang wrote: >>>>> Well, in fact the whole CertAndKeyGen class already assumes that the >>>>> public key has an X.509 encoding format. >>>>> >>>>> public X509Certificate getSelfCertificate ( >>>>> X500Name myname, Date firstDate, long validity) ... >>>>> { >>>>> .... >>>>> info.set(X509CertInfo.KEY, new >>>>> CertificateX509Key(publicKey)); >>>>> .... >>>>> >>>>> and CertificateX509Key.encode() simply calls key.getEncoded() without >>>>> checking its format. >>>>> >>>>> So here is an updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.02/ >>>>> >>>>> BTW, I didn't get external report on the failure. But the -selfcert >>>>> command is now failing on MSCAPI because of some other instanceof >>>>> checks. Before that gets fixed, I want to take -selfcert out of >>>>> -genkeypair. -selfcert is an obsolete command but -genkeypair is almost >>>>> the most important one for keytool. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 11/09/2011 03:24 AM, Michael StJohns wrote: >>>>>> Looking at the API definitions, it's possible for an RSAPublicKey >>>>>> implementation to have an encoding that is not "X.509". So, the >>>>>> right check really is "publicKey.getFormat().equalsIgnoreCase("X.509") >>>>>> and not "publicKey instanceof RSAPublicKey". No need for the "or" >>>>>> check. Or maybe the instance check is "publicKey instanceof >>>>>> PublicKey" >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> At 06:57 AM 11/8/2011, Xuelei Fan wrote: >>>>>>> Did you get any failure report about the CR? >>>>>>> >>>>>>> I asked the question because I concern about the format of the >>>>>>> encoded >>>>>>> public key. I'm not sure whether it is always be X.509 or not. If >>>>>>> it is >>>>>>> not of X.509, we properly cannot calculate the KID properly, and then >>>>>>> would be in the risk to chain the AKID, SKID incorrectly. Or if it is >>>>>>> not of X.509, we may get another exception during parse public key. >>>>>>> >>>>>>> If we got complains about the issue, I would suggest you check the >>>>>>> encoded format: >>>>>>> >>>>>>> 179 public PublicKey getPublicKeyAnyway() { >>>>>>> + if ((publicKey instanceof X509Key) || >>>>>>> + publicKey.getFormat().equalsIgnoreCases("X.509")) { >>>>>>> 180 return publicKey; >>>>>>> + } >>>>>>> + >>>>>>> + return null; >>>>>>> 181 } >>>>>>> >>>>>>> >>>>>>> If we cannot get the expected public key as expected, I think we >>>>>>> proper >>>>>>> have to resign it in order to get the public key from signed >>>>>>> certificate. Fortunately, our PKCS11 implementation do returns >>>>>>> "x.509" >>>>>>> format for RSA, DSA, DH and EC public key. >>>>>>> >>>>>>> >>>>>>> And a minor comment: >>>>>>> >>>>>>> 178 // Used by KeyTool, where publicKey is not a X509Key on Solaris. >>>>>>> >>>>>>> I think is is not because of Solaris platform, but because of the >>>>>>> PKCS11 >>>>>>> provider, so that publicKey is not an instance of X509Key. How about: >>>>>>> >>>>>>> /** >>>>>>> * Always returns the public key of the generated key pair. >>>>>>> Used >>>>>>> * by KeyTool only. >>>>>>> * >>>>>>> * The publicKey is not necessarily to be an instance of >>>>>>> * X509Key in some JCA/JCE providers, for example SunPKCS11. >>>>>>> */ >>>>>>> >>>>>>> BTW, I just noticed that KeyTool does not use AKID in self-signed >>>>>>> certificated. It's fine, but personally, I prefer to use both AKID >>>>>>> and >>>>>>> SKID in all certificates. >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>> On 11/8/2011 4:29 PM, Weijun Wang wrote: >>>>>>>> webrev updated at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.01/ >>>>>>>> >>>>>>>> This time JPRT tests jdk_security3 passes on all platforms. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> On 11/08/2011 03:18 PM, Weijun Wang wrote: >>>>>>>>> I only run tests on my Linux before posting the webrev. Then, in >>>>>>>>> the >>>>>>>>> pre-push JPRT run, it fails on all Solaris! >>>>>>>>> >>>>>>>>> Turns out that CertAndKeyGen has >>>>>>>>> >>>>>>>>> public X509Key getPublicKey() >>>>>>>>> { >>>>>>>>> if (!(publicKey instanceof X509Key)) { >>>>>>>>> return null; >>>>>>>>> } >>>>>>>>> return (X509Key)publicKey; >>>>>>>>> } >>>>>>>>> >>>>>>>>> So the public key, which I guess is a P11RSAPublicKey, is now null. >>>>>>>>> I'll >>>>>>>>> try to find a workaround. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/08/2011 11:19 AM, Xuelei Fan wrote: >>>>>>>>>> Looks fine in general. Please make sure all regression tests are >>>>>>>>>> passed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> On 11/7/2011 7:34 PM, Weijun Wang wrote: >>>>>>>>>>> Description: >>>>>>>>>>> >>>>>>>>>>> keytool uses CertAndKeyGen to generate a basic self-signed >>>>>>>>>>> certificate >>>>>>>>>>> with no extensions. When -ext option was introduced, >>>>>>>>>>> -genkeypair was >>>>>>>>>>> implemented as original -genkeypair plus -selfcert, and >>>>>>>>>>> extensions info >>>>>>>>>>> was added in the -selfcert step. >>>>>>>>>>> >>>>>>>>>>> This means the keystore object is modified twice in this single >>>>>>>>>>> operation. In the case of PKCS11 or MSCAPI, it is actually >>>>>>>>>>> written to >>>>>>>>>>> the token twice. If a token can only be written once, the action >>>>>>>>>>> will >>>>>>>>>>> fail. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~weijun/7109096/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> No new regression test (noreg-cleanup). >>>>>>>>>>> >>>>>>>>>>> Note: NetBeans consolidates the multiple import lines in >>>>>>>>>>> CertAndKeyGen >>>>>>>>>>> into one. I'm not against that. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>> >>>>>> >>>>>> >>>> >>> > From weijun.wang at oracle.com Tue Nov 8 23:51:52 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 09 Nov 2011 07:51:52 +0000 Subject: hg: jdk8/tl/jdk: 7109096: keytool -genkeypair needn't call -selfcert Message-ID: <20111109075203.1D76F472A5@hg.openjdk.java.net> Changeset: 52be75d060f9 Author: weijun Date: 2011-11-09 15:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52be75d060f9 7109096: keytool -genkeypair needn't call -selfcert Reviewed-by: xuelei ! src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java From chris.hegarty at oracle.com Thu Nov 10 04:23:07 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 10 Nov 2011 12:23:07 +0000 Subject: hg: jdk8/tl/jdk: 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Message-ID: <20111110122328.26002472E2@hg.openjdk.java.net> Changeset: d6a5da5f6ba0 Author: dl Date: 2011-11-10 12:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6a5da5f6ba0 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Reviewed-by: chegar, mduigou, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java From michael.x.mcmahon at oracle.com Thu Nov 10 08:25:42 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 10 Nov 2011 16:25:42 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111110162624.AB781472EE@hg.openjdk.java.net> Changeset: 0ccfb35cce26 Author: michaelm Date: 2011-11-10 15:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ccfb35cce26 7110484: HttpServer.stop() not closing selector Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: e5d65a583c15 Author: michaelm Date: 2011-11-10 15:41 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5d65a583c15 Merge From lance.andersen at oracle.com Thu Nov 10 08:42:39 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 10 Nov 2011 16:42:39 +0000 Subject: hg: jdk8/tl/jdk: 7110111: Minor Java SE javadoc & Constructor clean up Message-ID: <20111110164249.AEEAF472EF@hg.openjdk.java.net> Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/830d2e46023a 7110111: Minor Java SE javadoc & Constructor clean up Reviewed-by: alanb, darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/util/jar/Attributes.java From xuelei.fan at oracle.com Thu Nov 10 21:09:21 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Nov 2011 13:09:21 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Message-ID: <4EBCAE01.6060308@oracle.com> Hi Weijun, Are you available to review my fix for CR 7106773? The fix in JSSE part is straightforward in that the call to SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an additional Key parameter for RSA key exchanges. The significant change is at sun/security/util/DisabledAlgorithmConstraints.java. I modified the code in order to get the key size of the unextractable key in PKCS#11 device. webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ Thanks, Xuelei From weijun.wang at oracle.com Thu Nov 10 22:33:40 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 11 Nov 2011 14:33:40 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EBCAE01.6060308@oracle.com> References: <4EBCAE01.6060308@oracle.com> Message-ID: <4EBCC1C4.5030802@oracle.com> SSLContextVersion.java: typo: suported -> supported DisabledAlgorithmConstraints.java: When can size == 0? Why it's not allowed? Yes, I think the reflection calls should be wrapped in doPriv Please also consider keys from MSCAPI Try looking at sun.misc.SharedSecrets and see if it's better for you. Probably not. That class is used to share non-public methods in public classes. Not the same case here. SignatureAndHashAlgorithm.java: Is it possible to combine expected and signingKey into a single signingKey? Of course that means it might need to be never null and all key alg call it in a consistent way. I wonder if this is OK for you. The RSAKey interface seems not used anywhere. How about changing 288 } // Otherwise, cannot determine the key size, prefer the most 289 // perferable hash algorithm. to maxDigestLength = Integer.MAX_VALUE; then you don't need to assign -1 and check for < 0 later. I would be glad if lines 302-306 can be further indented 4 spaces The comment on lines 268-273 is confusing, because you did calculate maxDigestAlgorithm for 512 bits key later. Personally, I prefer comments on 274-281 and codes on 284-288 to be from a smaller keySize to bigger ones, but everything is OK. Test: I would like a unit test on DisabledAlgorithmConstraints::getKeySize. Hopefully the test can cover all SecretKey and PrivateKey from all providers with all keysizes. Thanks Max On 11/11/2011 01:09 PM, Xuelei Fan wrote: > Hi Weijun, > > Are you available to review my fix for CR 7106773? The fix in JSSE part > is straightforward in that the call to > SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an additional > Key parameter for RSA key exchanges. The significant change is at > sun/security/util/DisabledAlgorithmConstraints.java. I modified the code > in order to get the key size of the unextractable key in PKCS#11 device. > > webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ > > Thanks, > Xuelei From sean.coffey at oracle.com Fri Nov 11 02:09:07 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 11 Nov 2011 10:09:07 +0000 Subject: hg: jdk8/tl/jdk: 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Message-ID: <20111111100937.879D647312@hg.openjdk.java.net> Changeset: 9dd994f319ee Author: coffeys Date: 2011-11-11 10:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9dd994f319ee 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/solaris/classes/java/io/FileDescriptor.java ! src/windows/classes/java/io/FileDescriptor.java - test/java/io/FileDescriptor/FileChannelFDTest.java + test/java/io/FileDescriptor/Sharing.java - test/java/io/etc/FileDescriptorSharing.java From sean.coffey at oracle.com Fri Nov 11 02:16:25 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 11 Nov 2011 10:16:25 +0000 Subject: hg: jdk8/tl/corba: 7091388: Regular unexplained npe's from corba libs after system has been running for days Message-ID: <20111111101628.4F27947313@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/44c269731425 7091388: Regular unexplained npe's from corba libs after system has been running for days Reviewed-by: alanb ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java From xuelei.fan at oracle.com Mon Nov 14 00:45:58 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 14 Nov 2011 16:45:58 +0800 Subject: Code review request: unexpected debug log message Message-ID: <4EC0D546.9070406@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/7111548/webrev.00/ Simple fix, cleanup, no new regression test. Thanks, Xuelei From weijun.wang at oracle.com Mon Nov 14 00:52:37 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 14 Nov 2011 16:52:37 +0800 Subject: Code review request: unexpected debug log message In-Reply-To: <4EC0D546.9070406@oracle.com> References: <4EC0D546.9070406@oracle.com> Message-ID: <4EC0D6D5.5060208@oracle.com> Looks fine. -Max On 11/14/2011 04:45 PM, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net/~xuelei/7111548/webrev.00/ > > Simple fix, cleanup, no new regression test. > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon Nov 14 01:22:25 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 14 Nov 2011 09:22:25 +0000 Subject: hg: jdk8/tl/jdk: 7111548: unexpected debug log message Message-ID: <20111114092249.A7D3747352@hg.openjdk.java.net> Changeset: 5c7c83a6ee24 Author: xuelei Date: 2011-11-14 01:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c7c83a6ee24 7111548: unexpected debug log message Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From weijun.wang at oracle.com Mon Nov 14 02:58:37 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 14 Nov 2011 18:58:37 +0800 Subject: code review request: 7111579: klist starttime, renewtill, ticket etype Message-ID: <4EC0F45D.4070103@oracle.com> Webrev at http://cr.openjdk.java.net/~weijun/7111579/webrev.00/ Changes made (as in bug description). From [1] Service Principal: krbtgt/THREE.LOCAL at THREE.LOCAL Valid starting: Nov 14, 2011 17:53 Expires: Nov 15, 2011 03:53 Encryption type: RC4 with HMAC to [1] Service Principal: krbtgt/THREE.LOCAL at THREE.LOCAL Valid starting: Nov 14, 2011 17:56:54 Expires: Nov 15, 2011 03:53:18 Renew until: Nov 15, 2011 17:56:54 EType (skey, tkt): RC4 with HMAC, RC4 with HMAC BTW, there is no change for command line options and no change is needed for the klist.html [1]. So I think no CCC is needed. Thanks Max [1] http://download.oracle.com/javase/7/docs/technotes/tools/windows/klist.html -------- Original Message -------- *Change Request ID*: 7111579 *Synopsis*: klist starttime, renewtill, ticket etype === *Description* ============================================================ Java klist command is not consistent with other vendor's same tool: 1. starttime is in fact authtime 2. no renew until value 3. only one etype, and didn't say if it's for skey or ticket 4. no seconds in time From chris.hegarty at oracle.com Mon Nov 14 03:06:19 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 14 Nov 2011 11:06:19 +0000 Subject: hg: jdk8/tl/jdk: 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself Message-ID: <20111114110642.BEABE47356@hg.openjdk.java.net> Changeset: 68fc55d12ae6 Author: chegar Date: 2011-11-14 10:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68fc55d12ae6 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/windows/classes/java/net/PlainSocketImpl.java From kumar.x.srinivasan at oracle.com Mon Nov 14 08:38:16 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 14 Nov 2011 16:38:16 +0000 Subject: hg: jdk8/tl/langtools: 7110974: (javac) add coding conventions and style checkers for langtools Message-ID: <20111114163820.B61A847358@hg.openjdk.java.net> Changeset: c1238fcc9515 Author: ksrini Date: 2011-11-14 08:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c1238fcc9515 7110974: (javac) add coding conventions and style checkers for langtools Reviewed-by: jjg ! make/build.properties ! make/build.xml + make/conf/checkstyle-emacs.xsl + make/conf/checkstyle-langtools.xml From bradford.wetmore at oracle.com Mon Nov 14 15:28:11 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 14 Nov 2011 15:28:11 -0800 Subject: Code review request: unexpected debug log message In-Reply-To: <4EC0D6D5.5060208@oracle.com> References: <4EC0D546.9070406@oracle.com> <4EC0D6D5.5060208@oracle.com> Message-ID: <4EC1A40B.8030205@oracle.com> Not a big deal here, but Weijun was CR'er but you listed me in changeset. FYI, I also approve. Brad On 11/14/2011 12:52 AM, Weijun Wang wrote: > Looks fine. > > -Max > > On 11/14/2011 04:45 PM, Xuelei Fan wrote: >> webrev: http://cr.openjdk.java.net/~xuelei/7111548/webrev.00/ >> >> Simple fix, cleanup, no new regression test. >> >> Thanks, >> Xuelei From kumar.x.srinivasan at oracle.com Mon Nov 14 15:36:33 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 14 Nov 2011 23:36:33 +0000 Subject: hg: jdk8/tl/langtools: 7106166: (javac) re-factor EndPos parser Message-ID: <20111114233635.3AB444735E@hg.openjdk.java.net> Changeset: 7375d4979bd3 Author: ksrini Date: 2011-11-14 15:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7375d4979bd3 7106166: (javac) re-factor EndPos parser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/EndPosTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/TreePosTest.java From weijun.wang at oracle.com Mon Nov 14 17:10:46 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 15 Nov 2011 09:10:46 +0800 Subject: code review request: 7078816/7: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure In-Reply-To: <4EC1B625.8040706@oracle.com> References: <22056409.1321288328047.JavaMail.sbladm@swsblss4-new> <4EC1AD0E.4010808@oracle.com> <4EC1B625.8040706@oracle.com> Message-ID: <4EC1BC16.5030008@oracle.com> Hi Brad Turns out there is a tiny difference for 7u4 -- I need to remove the test from ProblemsList.txt. Can you take a review on it? The code change for the test itself is identical. http://cr.openjdk.java.net/~weijun/7078816/7u4/webrev.00/ Thanks Max On 11/15/2011 08:45 AM, Weijun Wang wrote: > > > On 11/15/2011 08:06 AM, Brad Wetmore wrote: >> Max, >> >> This bug was just MR/SubCR'd against JDK7 by Vera. Were you thinking of >> fixing this in 7u also? > > No I didn't (I thought there will be a big CR that backport all recent > test chanegs), but I can do it now. > > The webrev is identical, I'll ask for an approval. > > Thanks > Max > >> >> Brad >> >> >> >> On 11/14/2011 8:32 AM, vera.akulova at oracle.com wrote: >>> *Change Request ID*: 7078816/7 >>> *Synopsis*: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh >>> failure >>> From xuelei.fan at oracle.com Mon Nov 14 17:34:48 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Nov 2011 09:34:48 +0800 Subject: Code review request: unexpected debug log message In-Reply-To: <4EC1A40B.8030205@oracle.com> References: <4EC0D546.9070406@oracle.com> <4EC0D6D5.5060208@oracle.com> <4EC1A40B.8030205@oracle.com> Message-ID: <4EC1C1B8.1080909@oracle.com> My apologies for the mistake. Xuelei On 11/15/2011 7:28 AM, Brad Wetmore wrote: > > Not a big deal here, but Weijun was CR'er but you listed me in > changeset. FYI, I also approve. > > Brad > > > > On 11/14/2011 12:52 AM, Weijun Wang wrote: >> Looks fine. >> >> -Max >> >> On 11/14/2011 04:45 PM, Xuelei Fan wrote: >>> webrev: http://cr.openjdk.java.net/~xuelei/7111548/webrev.00/ >>> >>> Simple fix, cleanup, no new regression test. >>> >>> Thanks, >>> Xuelei From weijun.wang at oracle.com Mon Nov 14 17:45:25 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 15 Nov 2011 09:45:25 +0800 Subject: Code review request: unexpected debug log message In-Reply-To: <4EC1C1B8.1080909@oracle.com> References: <4EC0D546.9070406@oracle.com> <4EC0D6D5.5060208@oracle.com> <4EC1A40B.8030205@oracle.com> <4EC1C1B8.1080909@oracle.com> Message-ID: <4EC1C435.2060201@oracle.com> Ah, unfortunately in Mercurial you cannot create another changeset just to update the description for another changeset. ;) -Max On 11/15/2011 09:34 AM, Xuelei Fan wrote: > My apologies for the mistake. > > Xuelei > > On 11/15/2011 7:28 AM, Brad Wetmore wrote: >> >> Not a big deal here, but Weijun was CR'er but you listed me in >> changeset. FYI, I also approve. >> >> Brad >> >> >> >> On 11/14/2011 12:52 AM, Weijun Wang wrote: >>> Looks fine. >>> >>> -Max >>> >>> On 11/14/2011 04:45 PM, Xuelei Fan wrote: >>>> webrev: http://cr.openjdk.java.net/~xuelei/7111548/webrev.00/ >>>> >>>> Simple fix, cleanup, no new regression test. >>>> >>>> Thanks, >>>> Xuelei > From sean.mullan at oracle.com Tue Nov 15 07:32:08 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Nov 2011 10:32:08 -0500 Subject: code review request: 7111579: klist starttime, renewtill, ticket etype In-Reply-To: <4EC0F45D.4070103@oracle.com> References: <4EC0F45D.4070103@oracle.com> Message-ID: <4EC285F8.1030500@oracle.com> Looks fine to me. --Sean On 11/14/11 5:58 AM, Weijun Wang wrote: > Webrev at > > http://cr.openjdk.java.net/~weijun/7111579/webrev.00/ > > Changes made (as in bug description). From > > [1] Service Principal: krbtgt/THREE.LOCAL at THREE.LOCAL > Valid starting: Nov 14, 2011 17:53 > Expires: Nov 15, 2011 03:53 > Encryption type: RC4 with HMAC > > to > > [1] Service Principal: krbtgt/THREE.LOCAL at THREE.LOCAL > Valid starting: Nov 14, 2011 17:56:54 > Expires: Nov 15, 2011 03:53:18 > Renew until: Nov 15, 2011 17:56:54 > EType (skey, tkt): RC4 with HMAC, RC4 with HMAC > > BTW, there is no change for command line options and no change is needed > for the klist.html [1]. So I think no CCC is needed. > > Thanks > Max > > [1] > http://download.oracle.com/javase/7/docs/technotes/tools/windows/klist.html > > -------- Original Message -------- > *Change Request ID*: 7111579 > *Synopsis*: klist starttime, renewtill, ticket etype > > > === *Description* > ============================================================ > Java klist command is not consistent with other vendor's same tool: > > 1. starttime is in fact authtime > 2. no renew until value > 3. only one etype, and didn't say if it's for skey or ticket > 4. no seconds in time > > From weijun.wang at oracle.com Tue Nov 15 19:54:35 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 16 Nov 2011 03:54:35 +0000 Subject: hg: jdk8/tl/jdk: 7111579: klist starttime, renewtill, ticket etype Message-ID: <20111116035453.EF98B4738A@hg.openjdk.java.net> Changeset: c740519fe83a Author: weijun Date: 2011-11-16 11:53 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c740519fe83a 7111579: klist starttime, renewtill, ticket etype Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java From masayoshi.okutsu at oracle.com Tue Nov 15 20:31:00 2011 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 16 Nov 2011 04:31:00 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111116043119.9EFE64738B@hg.openjdk.java.net> Changeset: cd6d236e863b Author: okutsu Date: 2011-11-16 12:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd6d236e863b 7111903: (tz) Windows-only: tzmappings needs update for KB2570791 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 1266e72f7896 Author: okutsu Date: 2011-11-16 13:17 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1266e72f7896 Merge From weijun.wang at oracle.com Wed Nov 16 01:54:49 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 16 Nov 2011 17:54:49 +0800 Subject: Fwd: CR 7077172 Updated, P3 jgss/krb5plugin KerberosTime does not take into account system clock adjustement Message-ID: <4EC38869.5060504@oracle.com> Hi Valerie In code changes for 6882687, in order to increase the precision of KerberosTime, I use System.nanoTime() to calculate the current time. It is precise, but it's only an elapse of nanaseconds after the VM starts. What I did is, when the VM starts, I record a clock time, and after that, I add the elapsed time to it and get a current clock time. This would break if the user adjust the system time during the program execution, which will change the clock time, but not the elapse time since VM starts, and won't be noticed by me. Lines are added to detect system clock change. Please review: http://cr.openjdk.java.net/~weijun/7077172/webrev.00/ No reg, hard to simulate system clock change. Thanks Max -------- Original Message -------- *Change Request ID*: 7077172 *Synopsis*: KerberosTime does not take into account system clock adjustement === *Description* ============================================================ FULL PRODUCT VERSION : 7 A DESCRIPTION OF THE PROBLEM : Context ----------- In the Kerberos procotol, current client timestamp is encapsulated in the Kerberos query sent to the KDC to obtain a TGT. The timestamp in the query must be accurate (The KDC timestamp accepts 5mn deviation in most case); if not the KDC return a "Clock too skew" error. Problem ------------ To obtain the current Timestamp, previously in the JDK 6, the 'KerberosTime' 'setNow()' method instanciates a 'new Date()' object . A JDK 7 bug fix (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6882687) introduces a major change in this class. The current timestamp is evaluated using the time elapsed since the JVM startup (use of System.nanoTime()). This implementation totally misses the fact that both client and server generally use a time server (NTP) to synchronize their clocks. Clock adjustement is not taking into account in the current implementation while the previous implementation does. REGRESSION. Last worked in version 6u26 STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : 1. Develop a small Java client application that queries a KDC to obtain TGT each minutes. (Both client and KDC are hosted on the same machine) 2. Run the Java application. 3. Set the system clock and add 15 minutes to the current time EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - The KDC continues to deliver client TGT using the new time ACTUAL - The KDC returns an error 'Clock skew too great' ERROR MESSAGES/STACK TRACES THAT OCCUR : The Java application thrown an Exception javax.security.auth.login.LoginException: Clock skew too great (37) - PREAUTH_FAILED REPRODUCIBILITY : This bug can be reproduced always. From weijun.wang at oracle.com Wed Nov 16 01:55:51 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 16 Nov 2011 17:55:51 +0800 Subject: code review request: 7077172: KerberosTime does not take into account system clock adjustement Message-ID: <4EC388A7.4080800@oracle.com> Resent with an updated subject. -------- Original Message -------- Subject: Fwd: CR 7077172 Updated, P3 jgss/krb5plugin KerberosTime does not take into account system clock adjustement Date: Wed, 16 Nov 2011 17:54:49 +0800 From: Weijun Wang To: Valerie (Yu-Ching) Peng CC: OpenJDK Hi Valerie In code changes for 6882687, in order to increase the precision of KerberosTime, I use System.nanoTime() to calculate the current time. It is precise, but it's only an elapse of nanaseconds after the VM starts. What I did is, when the VM starts, I record a clock time, and after that, I add the elapsed time to it and get a current clock time. This would break if the user adjust the system time during the program execution, which will change the clock time, but not the elapse time since VM starts, and won't be noticed by me. Lines are added to detect system clock change. Please review: http://cr.openjdk.java.net/~weijun/7077172/webrev.00/ No reg, hard to simulate system clock change. Thanks Max -------- Original Message -------- *Change Request ID*: 7077172 *Synopsis*: KerberosTime does not take into account system clock adjustement === *Description* ============================================================ FULL PRODUCT VERSION : 7 A DESCRIPTION OF THE PROBLEM : Context ----------- In the Kerberos procotol, current client timestamp is encapsulated in the Kerberos query sent to the KDC to obtain a TGT. The timestamp in the query must be accurate (The KDC timestamp accepts 5mn deviation in most case); if not the KDC return a "Clock too skew" error. Problem ------------ To obtain the current Timestamp, previously in the JDK 6, the 'KerberosTime' 'setNow()' method instanciates a 'new Date()' object . A JDK 7 bug fix (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6882687) introduces a major change in this class. The current timestamp is evaluated using the time elapsed since the JVM startup (use of System.nanoTime()). This implementation totally misses the fact that both client and server generally use a time server (NTP) to synchronize their clocks. Clock adjustement is not taking into account in the current implementation while the previous implementation does. REGRESSION. Last worked in version 6u26 STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : 1. Develop a small Java client application that queries a KDC to obtain TGT each minutes. (Both client and KDC are hosted on the same machine) 2. Run the Java application. 3. Set the system clock and add 15 minutes to the current time EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - The KDC continues to deliver client TGT using the new time ACTUAL - The KDC returns an error 'Clock skew too great' ERROR MESSAGES/STACK TRACES THAT OCCUR : The Java application thrown an Exception javax.security.auth.login.LoginException: Clock skew too great (37) - PREAUTH_FAILED REPRODUCIBILITY : This bug can be reproduced always. From kumar.x.srinivasan at oracle.com Wed Nov 16 13:07:55 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 16 Nov 2011 21:07:55 +0000 Subject: hg: jdk8/tl/jdk: 7112160: jdk8 javadoc failure in jdk/make/docs javadoc: error - java.lang.OutOfMemoryError Message-ID: <20111116210812.E9E9F47393@hg.openjdk.java.net> Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/398442b00b2b 7112160: jdk8 javadoc failure in jdk/make/docs javadoc: error - java.lang.OutOfMemoryError Reviewed-by: ohair, katleman ! make/docs/Makefile From xuelei.fan at oracle.com Thu Nov 17 07:14:52 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Nov 2011 23:14:52 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EBCC1C4.5030802@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> Message-ID: <4EC524EC.1020104@oracle.com> Sean, could you also review the fix? I plan to backport the fix to JDK 7, so that the key size constraints for both JSSE and CertPath can work with PKCS11 and MSCPI. updated webrev: http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ In the new webrev, I add a new KeyLength class under sun.security.util. I think it may be useful for other models. On 11/11/2011 2:33 PM, Weijun Wang wrote: > SSLContextVersion.java: > > typo: suported -> supported > Updated. > DisabledAlgorithmConstraints.java: > > When can size == 0? Why it's not allowed? > It's a line of dummy code in case the get key size method return 0. > Yes, I think the reflection calls should be wrapped in doPriv > > Please also consider keys from MSCAPI > Support MSCAPI now. > Try looking at sun.misc.SharedSecrets and see if it's better > for you. Probably not. That class is used to share non-public > methods in public classes. Not the same case here. > > SignatureAndHashAlgorithm.java: > > Is it possible to combine expected and signingKey into a single > signingKey? Of course that means it might need to be never null > and all key alg call it in a consistent way. I wonder if this > is OK for you. > It not always work. For example, the key algorithm may be "EC", but the expected algorithm may be "ECDSA". > The RSAKey interface seems not used anywhere. > Yes, removed. > How about changing > > 288 } // Otherwise, cannot determine the key size, prefer the most > 289 // perferable hash algorithm. > > to > > maxDigestLength = Integer.MAX_VALUE; > > then you don't need to assign -1 and check for < 0 later. > Good point. > I would be glad if lines 302-306 can be further indented 4 spaces > > The comment on lines 268-273 is confusing, because you did calculate > maxDigestAlgorithm for 512 bits key later. > > Personally, I prefer comments on 274-281 and codes on 284-288 > to be from a smaller keySize to bigger ones, but everything is OK. > Updated. > Test: > > I would like a unit test on DisabledAlgorithmConstraints::getKeySize. > Hopefully the test can cover all SecretKey and PrivateKey from all > providers with all keysizes. > Added some new tests for PKCS11 and MSCAPI. Thanks, Xuelei > Thanks > Max > > On 11/11/2011 01:09 PM, Xuelei Fan wrote: >> Hi Weijun, >> >> Are you available to review my fix for CR 7106773? The fix in JSSE part >> is straightforward in that the call to >> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an additional >> Key parameter for RSA key exchanges. The significant change is at >> sun/security/util/DisabledAlgorithmConstraints.java. I modified the code >> in order to get the key size of the unextractable key in PKCS#11 device. >> >> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >> >> Thanks, >> Xuelei From sean.mullan at oracle.com Thu Nov 17 08:58:46 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 Nov 2011 11:58:46 -0500 Subject: JDK 8 Code Review Request: 7093090 Reduce synchronization in java.security.Policy.getPolicyNoCheck Message-ID: <4EC53D46.6040508@oracle.com> Hi Valerie, Could you review this one for me? http://cr.openjdk.java.net/~mullan/webrevs/7093090/webrev.00/ This one was tricky to fix, but I have confirmed that it does indeed fix the thread contention issue with the customer that reported this. The fix involved adding an initialized flag to indicate when the system-wide policy has been initialized and storing both the flag and the Policy object in an AtomicReference. Then, I also used the double-check locking idiom to avoid locking the Policy class when the Policy had already been initialized. Thanks, Sean From valerie.peng at oracle.com Thu Nov 17 15:24:18 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 17 Nov 2011 15:24:18 -0800 Subject: Fwd: CR 7077172 Updated, P3 jgss/krb5plugin KerberosTime does not take into account system clock adjustement In-Reply-To: <4EC38869.5060504@oracle.com> References: <4EC38869.5060504@oracle.com> Message-ID: <4EC597A2.3080106@oracle.com> Looks good to me. Thanks, Valerie On 11/16/11 01:54, Weijun Wang wrote: > Hi Valerie > > In code changes for 6882687, in order to increase the precision of > KerberosTime, I use System.nanoTime() to calculate the current time. > It is precise, but it's only an elapse of nanaseconds after the VM > starts. What I did is, when the VM starts, I record a clock time, and > after that, I add the elapsed time to it and get a current clock time. > This would break if the user adjust the system time during the program > execution, which will change the clock time, but not the elapse time > since VM starts, and won't be noticed by me. > > Lines are added to detect system clock change. Please review: > > http://cr.openjdk.java.net/~weijun/7077172/webrev.00/ > > No reg, hard to simulate system clock change. > > Thanks > Max > > > -------- Original Message -------- > *Change Request ID*: 7077172 > *Synopsis*: KerberosTime does not take into account system clock > adjustement > > === *Description* > ============================================================ > FULL PRODUCT VERSION : > 7 > > A DESCRIPTION OF THE PROBLEM : > Context > ----------- > In the Kerberos procotol, current client timestamp is encapsulated in > the Kerberos query sent to the KDC to obtain a TGT. The timestamp in > the query must be accurate (The KDC timestamp accepts 5mn deviation > in most case); if not the KDC return a "Clock too skew" error. > > Problem > ------------ > To obtain the current Timestamp, previously in the JDK 6, the > 'KerberosTime' 'setNow()' method instanciates a 'new Date()' object . > A JDK 7 bug fix > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6882687) > introduces a major change in this class. The current timestamp is > evaluated using the time elapsed since the JVM startup (use of > System.nanoTime()). > This implementation totally misses the fact that both client and > server generally use a time server (NTP) to synchronize their clocks. > Clock adjustement is not taking into account in the current > implementation while the previous implementation does. > > REGRESSION. Last worked in version 6u26 > > STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : > 1. Develop a small Java client application that queries a KDC to > obtain TGT each minutes. (Both client and KDC are hosted on the same > machine) > 2. Run the Java application. > 3. Set the system clock and add 15 minutes to the current time > > EXPECTED VERSUS ACTUAL BEHAVIOR : > EXPECTED - > The KDC continues to deliver client TGT using the new time > ACTUAL - > The KDC returns an error 'Clock skew too great' > > ERROR MESSAGES/STACK TRACES THAT OCCUR : > The Java application thrown an Exception > javax.security.auth.login.LoginException: Clock skew too great (37) - > PREAUTH_FAILED > > REPRODUCIBILITY : > This bug can be reproduced always. > From mandy.chung at oracle.com Thu Nov 17 15:48:10 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Nov 2011 23:48:10 +0000 Subject: hg: jdk8/tl/jdk: 7067691: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Message-ID: <20111117234828.14214473BD@hg.openjdk.java.net> Changeset: 3cd7dcf4a302 Author: mchung Date: 2011-11-17 15:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cd7dcf4a302 7067691: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung Contributed-by: gary.adams at oracle.com ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java From weijun.wang at oracle.com Fri Nov 18 00:14:34 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 18 Nov 2011 08:14:34 +0000 Subject: hg: jdk8/tl/jdk: 7077172: KerberosTime does not take into account system clock adjustement Message-ID: <20111118081452.A6274473CF@hg.openjdk.java.net> Changeset: 5bfff9616b86 Author: weijun Date: 2011-11-18 16:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bfff9616b86 7077172: KerberosTime does not take into account system clock adjustement Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/KerberosTime.java From weijun.wang at oracle.com Fri Nov 18 03:39:05 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Nov 2011 19:39:05 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC524EC.1020104@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> Message-ID: <4EC643D9.7080601@oracle.com> Oh, there seems to be much more non-trivial code changes then the previous version of webrev. I now focus on the utility class KeyLength.java: In ReflectiveProvider, how about adding a "." at the end of package name? Also, is the while loop really necessary in getKeyLengthMethod? Why not directly call getDeclaredMethod on the the baseClassName? If you want to make sure the current class is a subclass of the baseClassName, try isAssignableFrom. As for the test, I was thinking that you can add a unit test on the KeyLength class itself. Thanks Max On 11/17/2011 11:14 PM, Xuelei Fan wrote: > Sean, could you also review the fix? I plan to backport the fix to JDK > 7, so that the key size constraints for both JSSE and CertPath can work > with PKCS11 and MSCPI. > > updated webrev: > http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ > > In the new webrev, I add a new KeyLength class under sun.security.util. > I think it may be useful for other models. > > On 11/11/2011 2:33 PM, Weijun Wang wrote: >> SSLContextVersion.java: >> >> typo: suported -> supported >> > Updated. > >> DisabledAlgorithmConstraints.java: >> >> When can size == 0? Why it's not allowed? >> > It's a line of dummy code in case the get key size method return 0. > >> Yes, I think the reflection calls should be wrapped in doPriv >> >> Please also consider keys from MSCAPI >> > Support MSCAPI now. > >> Try looking at sun.misc.SharedSecrets and see if it's better >> for you. Probably not. That class is used to share non-public >> methods in public classes. Not the same case here. >> >> SignatureAndHashAlgorithm.java: >> >> Is it possible to combine expected and signingKey into a single >> signingKey? Of course that means it might need to be never null >> and all key alg call it in a consistent way. I wonder if this >> is OK for you. >> > It not always work. For example, the key algorithm may be "EC", but the > expected algorithm may be "ECDSA". > >> The RSAKey interface seems not used anywhere. >> > Yes, removed. > >> How about changing >> >> 288 } // Otherwise, cannot determine the key size, prefer the most >> 289 // perferable hash algorithm. >> >> to >> >> maxDigestLength = Integer.MAX_VALUE; >> >> then you don't need to assign -1 and check for< 0 later. >> > Good point. > >> I would be glad if lines 302-306 can be further indented 4 spaces >> >> The comment on lines 268-273 is confusing, because you did calculate >> maxDigestAlgorithm for 512 bits key later. >> >> Personally, I prefer comments on 274-281 and codes on 284-288 >> to be from a smaller keySize to bigger ones, but everything is OK. >> > Updated. > >> Test: >> >> I would like a unit test on DisabledAlgorithmConstraints::getKeySize. >> Hopefully the test can cover all SecretKey and PrivateKey from all >> providers with all keysizes. >> > Added some new tests for PKCS11 and MSCAPI. > > Thanks, > Xuelei > >> Thanks >> Max >> >> On 11/11/2011 01:09 PM, Xuelei Fan wrote: >>> Hi Weijun, >>> >>> Are you available to review my fix for CR 7106773? The fix in JSSE part >>> is straightforward in that the call to >>> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an additional >>> Key parameter for RSA key exchanges. The significant change is at >>> sun/security/util/DisabledAlgorithmConstraints.java. I modified the code >>> in order to get the key size of the unextractable key in PKCS#11 device. >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >>> >>> Thanks, >>> Xuelei > From xuelei.fan at oracle.com Fri Nov 18 04:39:24 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 18 Nov 2011 20:39:24 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC643D9.7080601@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> Message-ID: <4EC651FC.2070202@oracle.com> The VPN is awesomely bad today. The webrev in cr.openjdk is http://cr.openjdk.java.net/~xuelei/7106773/webrev.01/ On 11/18/2011 7:39 PM, Weijun Wang wrote: > Oh, there seems to be much more non-trivial code changes then the > previous version of webrev. > > I now focus on the utility class KeyLength.java: > > In ReflectiveProvider, how about adding a "." at the end of package name? > It's safer. > Also, is the while loop really necessary in getKeyLengthMethod? Why not > directly call getDeclaredMethod on the the baseClassName? If you want to > make sure the current class is a subclass of the baseClassName, try > isAssignableFrom. > It's a little strange of the implement of getKeyLengthMethod() because of the following causes: 1. Class.getDeclaredMethod() cannot return inherited methods. 2. Class.forName("sun.security.pkcs11.P11Key") is not reliable. The current class loader is not always able to find the P11Key class. As you saw in the previous webrev, I specified the class loader while searching for the class: Class.forName("sun.security.pkcs11.P11Key", true, key.getClass().getClassLoader()); There is one assumption that every key will come from the same class loader during the JVM life. So we can cache the loaded P11Key class. It's a little risky. And more, it's OK when there is only one PKCS11 provider. However, while we adding MSCAPI in, we will have to look through both PKCS11 provider and MSCAPI provider in order to select the proper cached key class. If we get a key from none of PKCS11 and MSCAPI, we will continue calling the Class.forName() repeatedly until we are able to encounter the PKCS11 key or MSCAPI key. It's very bad in performance. The calling in the getKeyLengthMethod() is lightweight, and we don't have to worry about the class loader any more. > As for the test, I was thinking that you can add a unit test on the > KeyLength class itself. > I may add some new and simple tests on KeyLength only. Thanks, Xuelei > Thanks > Max > > > On 11/17/2011 11:14 PM, Xuelei Fan wrote: >> Sean, could you also review the fix? I plan to backport the fix to JDK >> 7, so that the key size constraints for both JSSE and CertPath can work >> with PKCS11 and MSCPI. >> >> updated webrev: >> http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ >> >> In the new webrev, I add a new KeyLength class under sun.security.util. >> I think it may be useful for other models. >> >> On 11/11/2011 2:33 PM, Weijun Wang wrote: >>> SSLContextVersion.java: >>> >>> typo: suported -> supported >>> >> Updated. >> >>> DisabledAlgorithmConstraints.java: >>> >>> When can size == 0? Why it's not allowed? >>> >> It's a line of dummy code in case the get key size method return 0. >> >>> Yes, I think the reflection calls should be wrapped in doPriv >>> >>> Please also consider keys from MSCAPI >>> >> Support MSCAPI now. >> >>> Try looking at sun.misc.SharedSecrets and see if it's better >>> for you. Probably not. That class is used to share non-public >>> methods in public classes. Not the same case here. >>> >>> SignatureAndHashAlgorithm.java: >>> >>> Is it possible to combine expected and signingKey into a single >>> signingKey? Of course that means it might need to be never null >>> and all key alg call it in a consistent way. I wonder if this >>> is OK for you. >>> >> It not always work. For example, the key algorithm may be "EC", but the >> expected algorithm may be "ECDSA". >> >>> The RSAKey interface seems not used anywhere. >>> >> Yes, removed. >> >>> How about changing >>> >>> 288 } // Otherwise, cannot determine the key size, prefer the >>> most >>> 289 // perferable hash algorithm. >>> >>> to >>> >>> maxDigestLength = Integer.MAX_VALUE; >>> >>> then you don't need to assign -1 and check for< 0 later. >>> >> Good point. >> >>> I would be glad if lines 302-306 can be further indented 4 spaces >>> >>> The comment on lines 268-273 is confusing, because you did calculate >>> maxDigestAlgorithm for 512 bits key later. >>> >>> Personally, I prefer comments on 274-281 and codes on 284-288 >>> to be from a smaller keySize to bigger ones, but everything is OK. >>> >> Updated. >> >>> Test: >>> >>> I would like a unit test on >>> DisabledAlgorithmConstraints::getKeySize. >>> Hopefully the test can cover all SecretKey and PrivateKey from all >>> providers with all keysizes. >>> >> Added some new tests for PKCS11 and MSCAPI. >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>> On 11/11/2011 01:09 PM, Xuelei Fan wrote: >>>> Hi Weijun, >>>> >>>> Are you available to review my fix for CR 7106773? The fix in JSSE part >>>> is straightforward in that the call to >>>> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an additional >>>> Key parameter for RSA key exchanges. The significant change is at >>>> sun/security/util/DisabledAlgorithmConstraints.java. I modified the >>>> code >>>> in order to get the key size of the unextractable key in PKCS#11 >>>> device. >>>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >>>> >>>> Thanks, >>>> Xuelei >> From weijun.wang at oracle.com Fri Nov 18 06:16:58 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Nov 2011 22:16:58 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC651FC.2070202@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> Message-ID: <4EC668DA.2060106@oracle.com> On 11/18/2011 08:39 PM, Xuelei Fan wrote: > The VPN is awesomely bad today. > > The webrev in cr.openjdk is > http://cr.openjdk.java.net/~xuelei/7106773/webrev.01/ > > On 11/18/2011 7:39 PM, Weijun Wang wrote: >> Oh, there seems to be much more non-trivial code changes then the >> previous version of webrev. >> >> I now focus on the utility class KeyLength.java: >> >> In ReflectiveProvider, how about adding a "." at the end of package name? >> > It's safer. > >> Also, is the while loop really necessary in getKeyLengthMethod? Why not >> directly call getDeclaredMethod on the the baseClassName? If you want to >> make sure the current class is a subclass of the baseClassName, try >> isAssignableFrom. >> > It's a little strange of the implement of getKeyLengthMethod() because > of the following causes: > 1. Class.getDeclaredMethod() cannot return inherited methods. > > 2. Class.forName("sun.security.pkcs11.P11Key") is not reliable. > The current class loader is not always able to find the P11Key class. Oh, In which case? > As you saw in the previous webrev, I specified the class loader while > searching for the class: > Class.forName("sun.security.pkcs11.P11Key", true, > key.getClass().getClassLoader()); > > There is one assumption that every key will come from the same class > loader during the JVM life. So we can cache the loaded P11Key class. > It's a little risky. > > And more, it's OK when there is only one PKCS11 provider. However, > while we adding MSCAPI in, we will have to look through both PKCS11 > provider and MSCAPI provider in order to select the proper cached key > class. If we get a key from none of PKCS11 and MSCAPI, we will continue > calling the Class.forName() repeatedly until we are able to encounter > the PKCS11 key or MSCAPI key. It's very bad in performance. > > The calling in the getKeyLengthMethod() is lightweight, and we don't > have to worry about the class loader any more. Calling getDeclaredMethod each time is a waste. How about just while (clazz != null) { if (clazz.getName().equals(baseClassName)) { // do sth break; } clazz = clazz.getSuperclass(); } Also, you're using methods in reflection. Is it faster to use fields? Thanks Max > >> As for the test, I was thinking that you can add a unit test on the >> KeyLength class itself. >> > I may add some new and simple tests on KeyLength only. > > Thanks, > Xuelei > >> Thanks >> Max >> >> >> On 11/17/2011 11:14 PM, Xuelei Fan wrote: >>> Sean, could you also review the fix? I plan to backport the fix to JDK >>> 7, so that the key size constraints for both JSSE and CertPath can work >>> with PKCS11 and MSCPI. >>> >>> updated webrev: >>> http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ >>> >>> In the new webrev, I add a new KeyLength class under sun.security.util. >>> I think it may be useful for other models. >>> >>> On 11/11/2011 2:33 PM, Weijun Wang wrote: >>>> SSLContextVersion.java: >>>> >>>> typo: suported -> supported >>>> >>> Updated. >>> >>>> DisabledAlgorithmConstraints.java: >>>> >>>> When can size == 0? Why it's not allowed? >>>> >>> It's a line of dummy code in case the get key size method return 0. >>> >>>> Yes, I think the reflection calls should be wrapped in doPriv >>>> >>>> Please also consider keys from MSCAPI >>>> >>> Support MSCAPI now. >>> >>>> Try looking at sun.misc.SharedSecrets and see if it's better >>>> for you. Probably not. That class is used to share non-public >>>> methods in public classes. Not the same case here. >>>> >>>> SignatureAndHashAlgorithm.java: >>>> >>>> Is it possible to combine expected and signingKey into a single >>>> signingKey? Of course that means it might need to be never null >>>> and all key alg call it in a consistent way. I wonder if this >>>> is OK for you. >>>> >>> It not always work. For example, the key algorithm may be "EC", but the >>> expected algorithm may be "ECDSA". >>> >>>> The RSAKey interface seems not used anywhere. >>>> >>> Yes, removed. >>> >>>> How about changing >>>> >>>> 288 } // Otherwise, cannot determine the key size, prefer the >>>> most >>>> 289 // perferable hash algorithm. >>>> >>>> to >>>> >>>> maxDigestLength = Integer.MAX_VALUE; >>>> >>>> then you don't need to assign -1 and check for< 0 later. >>>> >>> Good point. >>> >>>> I would be glad if lines 302-306 can be further indented 4 spaces >>>> >>>> The comment on lines 268-273 is confusing, because you did calculate >>>> maxDigestAlgorithm for 512 bits key later. >>>> >>>> Personally, I prefer comments on 274-281 and codes on 284-288 >>>> to be from a smaller keySize to bigger ones, but everything is OK. >>>> >>> Updated. >>> >>>> Test: >>>> >>>> I would like a unit test on >>>> DisabledAlgorithmConstraints::getKeySize. >>>> Hopefully the test can cover all SecretKey and PrivateKey from all >>>> providers with all keysizes. >>>> >>> Added some new tests for PKCS11 and MSCAPI. >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>> On 11/11/2011 01:09 PM, Xuelei Fan wrote: >>>>> Hi Weijun, >>>>> >>>>> Are you available to review my fix for CR 7106773? The fix in JSSE part >>>>> is straightforward in that the call to >>>>> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an additional >>>>> Key parameter for RSA key exchanges. The significant change is at >>>>> sun/security/util/DisabledAlgorithmConstraints.java. I modified the >>>>> code >>>>> in order to get the key size of the unextractable key in PKCS#11 >>>>> device. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >>>>> >>>>> Thanks, >>>>> Xuelei >>> > From xuelei.fan at oracle.com Fri Nov 18 06:38:19 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 18 Nov 2011 22:38:19 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC668DA.2060106@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> Message-ID: <4EC66DDB.4060702@oracle.com> On 11/18/2011 10:16 PM, Weijun Wang wrote: > > On 11/18/2011 08:39 PM, Xuelei Fan wrote: >> The VPN is awesomely bad today. >> >> The webrev in cr.openjdk is >> http://cr.openjdk.java.net/~xuelei/7106773/webrev.01/ >> >> On 11/18/2011 7:39 PM, Weijun Wang wrote: >>> Oh, there seems to be much more non-trivial code changes then the >>> previous version of webrev. >>> >>> I now focus on the utility class KeyLength.java: >>> >>> In ReflectiveProvider, how about adding a "." at the end of package >>> name? >>> >> It's safer. >> >>> Also, is the while loop really necessary in getKeyLengthMethod? Why not >>> directly call getDeclaredMethod on the the baseClassName? If you want to >>> make sure the current class is a subclass of the baseClassName, try >>> isAssignableFrom. >>> >> It's a little strange of the implement of getKeyLengthMethod() because >> of the following causes: >> 1. Class.getDeclaredMethod() cannot return inherited methods. >> >> 2. Class.forName("sun.security.pkcs11.P11Key") is not reliable. >> The current class loader is not always able to find the P11Key class. > > Oh, In which case? > In the previous webrev, I found the case while running test/sun/security/pkcs11/KeyStore/ClientAuth.java while call Class.forName() with the current class loader. >> As you saw in the previous webrev, I specified the class loader while >> searching for the class: >> Class.forName("sun.security.pkcs11.P11Key", true, >> key.getClass().getClassLoader()); >> >> There is one assumption that every key will come from the same class >> loader during the JVM life. So we can cache the loaded P11Key class. >> It's a little risky. >> >> And more, it's OK when there is only one PKCS11 provider. However, >> while we adding MSCAPI in, we will have to look through both PKCS11 >> provider and MSCAPI provider in order to select the proper cached key >> class. If we get a key from none of PKCS11 and MSCAPI, we will continue >> calling the Class.forName() repeatedly until we are able to encounter >> the PKCS11 key or MSCAPI key. It's very bad in performance. >> >> The calling in the getKeyLengthMethod() is lightweight, and we don't >> have to worry about the class loader any more. > > Calling getDeclaredMethod each time is a waste. How about just > > while (clazz != null) { > if (clazz.getName().equals(baseClassName)) { > // do sth > break; > } > clazz = clazz.getSuperclass(); > } > > Also, you're using methods in reflection. Is it faster to use fields? > I also concerns about the override of the target method, although there is no such override at present. From some reports, it seems that fields reflection cost more cycles than method reflection. Performance is a big issue here. What do you think if we change the get key length method of pkcs11.P11Key and mscapi.Key for better performance? Thanks, Xuelei > Thanks > Max > >> >>> As for the test, I was thinking that you can add a unit test on the >>> KeyLength class itself. >>> >> I may add some new and simple tests on KeyLength only. >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>> >>> On 11/17/2011 11:14 PM, Xuelei Fan wrote: >>>> Sean, could you also review the fix? I plan to backport the fix to JDK >>>> 7, so that the key size constraints for both JSSE and CertPath can work >>>> with PKCS11 and MSCPI. >>>> >>>> updated webrev: >>>> http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ >>>> >>>> In the new webrev, I add a new KeyLength class under sun.security.util. >>>> I think it may be useful for other models. >>>> >>>> On 11/11/2011 2:33 PM, Weijun Wang wrote: >>>>> SSLContextVersion.java: >>>>> >>>>> typo: suported -> supported >>>>> >>>> Updated. >>>> >>>>> DisabledAlgorithmConstraints.java: >>>>> >>>>> When can size == 0? Why it's not allowed? >>>>> >>>> It's a line of dummy code in case the get key size method return 0. >>>> >>>>> Yes, I think the reflection calls should be wrapped in doPriv >>>>> >>>>> Please also consider keys from MSCAPI >>>>> >>>> Support MSCAPI now. >>>> >>>>> Try looking at sun.misc.SharedSecrets and see if it's better >>>>> for you. Probably not. That class is used to share non-public >>>>> methods in public classes. Not the same case here. >>>>> >>>>> SignatureAndHashAlgorithm.java: >>>>> >>>>> Is it possible to combine expected and signingKey into a single >>>>> signingKey? Of course that means it might need to be never null >>>>> and all key alg call it in a consistent way. I wonder if this >>>>> is OK for you. >>>>> >>>> It not always work. For example, the key algorithm may be "EC", but the >>>> expected algorithm may be "ECDSA". >>>> >>>>> The RSAKey interface seems not used anywhere. >>>>> >>>> Yes, removed. >>>> >>>>> How about changing >>>>> >>>>> 288 } // Otherwise, cannot determine the key size, prefer the >>>>> most >>>>> 289 // perferable hash algorithm. >>>>> >>>>> to >>>>> >>>>> maxDigestLength = Integer.MAX_VALUE; >>>>> >>>>> then you don't need to assign -1 and check for< 0 later. >>>>> >>>> Good point. >>>> >>>>> I would be glad if lines 302-306 can be further indented 4 spaces >>>>> >>>>> The comment on lines 268-273 is confusing, because you did >>>>> calculate >>>>> maxDigestAlgorithm for 512 bits key later. >>>>> >>>>> Personally, I prefer comments on 274-281 and codes on 284-288 >>>>> to be from a smaller keySize to bigger ones, but everything is >>>>> OK. >>>>> >>>> Updated. >>>> >>>>> Test: >>>>> >>>>> I would like a unit test on >>>>> DisabledAlgorithmConstraints::getKeySize. >>>>> Hopefully the test can cover all SecretKey and PrivateKey from >>>>> all >>>>> providers with all keysizes. >>>>> >>>> Added some new tests for PKCS11 and MSCAPI. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 11/11/2011 01:09 PM, Xuelei Fan wrote: >>>>>> Hi Weijun, >>>>>> >>>>>> Are you available to review my fix for CR 7106773? The fix in JSSE >>>>>> part >>>>>> is straightforward in that the call to >>>>>> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an >>>>>> additional >>>>>> Key parameter for RSA key exchanges. The significant change is at >>>>>> sun/security/util/DisabledAlgorithmConstraints.java. I modified the >>>>>> code >>>>>> in order to get the key size of the unextractable key in PKCS#11 >>>>>> device. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>> >> From weijun.wang at oracle.com Fri Nov 18 06:43:16 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Nov 2011 22:43:16 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC66DDB.4060702@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> <4EC66DDB.4060702@oracle.com> Message-ID: <4EC66F04.2070005@oracle.com> On 11/18/2011 10:38 PM, Xuelei Fan wrote: > On 11/18/2011 10:16 PM, Weijun Wang wrote: >> >> On 11/18/2011 08:39 PM, Xuelei Fan wrote: >>> The VPN is awesomely bad today. >>> >>> The webrev in cr.openjdk is >>> http://cr.openjdk.java.net/~xuelei/7106773/webrev.01/ >>> >>> On 11/18/2011 7:39 PM, Weijun Wang wrote: >>>> Oh, there seems to be much more non-trivial code changes then the >>>> previous version of webrev. >>>> >>>> I now focus on the utility class KeyLength.java: >>>> >>>> In ReflectiveProvider, how about adding a "." at the end of package >>>> name? >>>> >>> It's safer. >>> >>>> Also, is the while loop really necessary in getKeyLengthMethod? Why not >>>> directly call getDeclaredMethod on the the baseClassName? If you want to >>>> make sure the current class is a subclass of the baseClassName, try >>>> isAssignableFrom. >>>> >>> It's a little strange of the implement of getKeyLengthMethod() because >>> of the following causes: >>> 1. Class.getDeclaredMethod() cannot return inherited methods. >>> >>> 2. Class.forName("sun.security.pkcs11.P11Key") is not reliable. >>> The current class loader is not always able to find the P11Key class. >> >> Oh, In which case? >> > In the previous webrev, I found the case while running > test/sun/security/pkcs11/KeyStore/ClientAuth.java while call > Class.forName() with the current class loader. > >>> As you saw in the previous webrev, I specified the class loader while >>> searching for the class: >>> Class.forName("sun.security.pkcs11.P11Key", true, >>> key.getClass().getClassLoader()); >>> >>> There is one assumption that every key will come from the same class >>> loader during the JVM life. So we can cache the loaded P11Key class. >>> It's a little risky. >>> >>> And more, it's OK when there is only one PKCS11 provider. However, >>> while we adding MSCAPI in, we will have to look through both PKCS11 >>> provider and MSCAPI provider in order to select the proper cached key >>> class. If we get a key from none of PKCS11 and MSCAPI, we will continue >>> calling the Class.forName() repeatedly until we are able to encounter >>> the PKCS11 key or MSCAPI key. It's very bad in performance. >>> >>> The calling in the getKeyLengthMethod() is lightweight, and we don't >>> have to worry about the class loader any more. >> >> Calling getDeclaredMethod each time is a waste. How about just >> >> while (clazz != null) { >> if (clazz.getName().equals(baseClassName)) { >> // do sth >> break; >> } >> clazz = clazz.getSuperclass(); >> } >> >> Also, you're using methods in reflection. Is it faster to use fields? >> > I also concerns about the override of the target method, although there > is no such override at present. From some reports, it seems that fields > reflection cost more cycles than method reflection. Oh, I thought get a field is simpler. > > Performance is a big issue here. What do you think if we change the get > key length method of pkcs11.P11Key and mscapi.Key for better performance? How do you want to change? -Max > > Thanks, > Xuelei > >> Thanks >> Max >> >>> >>>> As for the test, I was thinking that you can add a unit test on the >>>> KeyLength class itself. >>>> >>> I may add some new and simple tests on KeyLength only. >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 11/17/2011 11:14 PM, Xuelei Fan wrote: >>>>> Sean, could you also review the fix? I plan to backport the fix to JDK >>>>> 7, so that the key size constraints for both JSSE and CertPath can work >>>>> with PKCS11 and MSCPI. >>>>> >>>>> updated webrev: >>>>> http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ >>>>> >>>>> In the new webrev, I add a new KeyLength class under sun.security.util. >>>>> I think it may be useful for other models. >>>>> >>>>> On 11/11/2011 2:33 PM, Weijun Wang wrote: >>>>>> SSLContextVersion.java: >>>>>> >>>>>> typo: suported -> supported >>>>>> >>>>> Updated. >>>>> >>>>>> DisabledAlgorithmConstraints.java: >>>>>> >>>>>> When can size == 0? Why it's not allowed? >>>>>> >>>>> It's a line of dummy code in case the get key size method return 0. >>>>> >>>>>> Yes, I think the reflection calls should be wrapped in doPriv >>>>>> >>>>>> Please also consider keys from MSCAPI >>>>>> >>>>> Support MSCAPI now. >>>>> >>>>>> Try looking at sun.misc.SharedSecrets and see if it's better >>>>>> for you. Probably not. That class is used to share non-public >>>>>> methods in public classes. Not the same case here. >>>>>> >>>>>> SignatureAndHashAlgorithm.java: >>>>>> >>>>>> Is it possible to combine expected and signingKey into a single >>>>>> signingKey? Of course that means it might need to be never null >>>>>> and all key alg call it in a consistent way. I wonder if this >>>>>> is OK for you. >>>>>> >>>>> It not always work. For example, the key algorithm may be "EC", but the >>>>> expected algorithm may be "ECDSA". >>>>> >>>>>> The RSAKey interface seems not used anywhere. >>>>>> >>>>> Yes, removed. >>>>> >>>>>> How about changing >>>>>> >>>>>> 288 } // Otherwise, cannot determine the key size, prefer the >>>>>> most >>>>>> 289 // perferable hash algorithm. >>>>>> >>>>>> to >>>>>> >>>>>> maxDigestLength = Integer.MAX_VALUE; >>>>>> >>>>>> then you don't need to assign -1 and check for< 0 later. >>>>>> >>>>> Good point. >>>>> >>>>>> I would be glad if lines 302-306 can be further indented 4 spaces >>>>>> >>>>>> The comment on lines 268-273 is confusing, because you did >>>>>> calculate >>>>>> maxDigestAlgorithm for 512 bits key later. >>>>>> >>>>>> Personally, I prefer comments on 274-281 and codes on 284-288 >>>>>> to be from a smaller keySize to bigger ones, but everything is >>>>>> OK. >>>>>> >>>>> Updated. >>>>> >>>>>> Test: >>>>>> >>>>>> I would like a unit test on >>>>>> DisabledAlgorithmConstraints::getKeySize. >>>>>> Hopefully the test can cover all SecretKey and PrivateKey from >>>>>> all >>>>>> providers with all keysizes. >>>>>> >>>>> Added some new tests for PKCS11 and MSCAPI. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> On 11/11/2011 01:09 PM, Xuelei Fan wrote: >>>>>>> Hi Weijun, >>>>>>> >>>>>>> Are you available to review my fix for CR 7106773? The fix in JSSE >>>>>>> part >>>>>>> is straightforward in that the call to >>>>>>> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an >>>>>>> additional >>>>>>> Key parameter for RSA key exchanges. The significant change is at >>>>>>> sun/security/util/DisabledAlgorithmConstraints.java. I modified the >>>>>>> code >>>>>>> in order to get the key size of the unextractable key in PKCS#11 >>>>>>> device. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>> >>> > From lana.steuck at oracle.com Fri Nov 18 14:37:19 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:19 +0000 Subject: hg: jdk8/tl: 7 new changesets Message-ID: <20111118223719.C1C08473E0@hg.openjdk.java.net> Changeset: 8da26d5c32a7 Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8da26d5c32a7 Added tag jdk8-b13 for changeset 26fb81a1e9ce ! .hgtags Changeset: a62a0f35eb9c Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a62a0f35eb9c Merge Changeset: f9b3e6b2aa2c Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f9b3e6b2aa2c Merge Changeset: ea2ab83ce564 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ea2ab83ce564 Merge Changeset: 8f525559ae73 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8f525559ae73 Merge Changeset: 23aa7f2c80a2 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/23aa7f2c80a2 Merge Changeset: a4f28069d44a Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a4f28069d44a Added tag jdk8-b14 for changeset 23aa7f2c80a2 ! .hgtags From lana.steuck at oracle.com Fri Nov 18 14:37:31 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:31 +0000 Subject: hg: jdk8/tl/jaxp: 7 new changesets Message-ID: <20111118223731.9AF06473E1@hg.openjdk.java.net> Changeset: e7172d80a8f4 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e7172d80a8f4 Added tag jdk8-b13 for changeset bcc739229f63 ! .hgtags Changeset: 7adf14d6060c Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7adf14d6060c Merge Changeset: d239aa024b6e Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d239aa024b6e Merge Changeset: eca33f89c823 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eca33f89c823 Merge Changeset: 0ed9ae36ee2a Author: asaha Date: 2011-11-07 21:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0ed9ae36ee2a Merge Changeset: 9d0c9d638757 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9d0c9d638757 Merge Changeset: 804f666d6d44 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/804f666d6d44 Added tag jdk8-b14 for changeset 9d0c9d638757 ! .hgtags From lana.steuck at oracle.com Fri Nov 18 14:37:36 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:36 +0000 Subject: hg: jdk8/tl/jaxws: 9 new changesets Message-ID: <20111118223737.3E29E473E2@hg.openjdk.java.net> Changeset: f502a343a92e Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f502a343a92e Added tag jdk8-b13 for changeset adf2a6b5fde1 ! .hgtags Changeset: 75a652e72489 Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/75a652e72489 Merge Changeset: b058cae6fd3b Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b058cae6fd3b Merge Changeset: 61c046c6895a Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/61c046c6895a Merge Changeset: 9e82b46cd4fa Author: asaha Date: 2011-07-25 11:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9e82b46cd4fa 7046794: Configurable behavior for server-side stacktraces Reviewed-by: ramap ! jaxws.properties Changeset: c78fccb01d4e Author: asaha Date: 2011-11-07 21:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c78fccb01d4e Merge Changeset: cae6db74d6af Author: asaha Date: 2011-11-10 13:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/cae6db74d6af 7110676: Update jaf source download url for jaxws Reviewed-by: ramap ! jaxws.properties Changeset: 54c4bf4b83ec Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/54c4bf4b83ec Merge Changeset: c9ab96ff23d5 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c9ab96ff23d5 Added tag jdk8-b14 for changeset 54c4bf4b83ec ! .hgtags From lana.steuck at oracle.com Fri Nov 18 14:37:26 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:26 +0000 Subject: hg: jdk8/tl/corba: 9 new changesets Message-ID: <20111118223744.5C049473E3@hg.openjdk.java.net> Changeset: 6f601a737e0f Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6f601a737e0f Added tag jdk8-b13 for changeset 5b9d9b839d3d ! .hgtags Changeset: d84682019b5f Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d84682019b5f Merge Changeset: 9c20c1e7cdd9 Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9c20c1e7cdd9 Merge Changeset: cb5aec0570a5 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb5aec0570a5 Merge Changeset: 21369018a679 Author: mbankal Date: 2011-08-09 05:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/21369018a679 7055902: Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 058c18d237a9 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/058c18d237a9 Merge Changeset: e59c47de1ad8 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e59c47de1ad8 Merge Changeset: 99925e8d1b86 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/99925e8d1b86 Added tag jdk8-b14 for changeset e59c47de1ad8 ! .hgtags Changeset: 7da69e7175a7 Author: lana Date: 2011-11-18 11:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7da69e7175a7 Merge From lana.steuck at oracle.com Fri Nov 18 14:37:17 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:17 +0000 Subject: hg: jdk8/tl/hotspot: 8 new changesets Message-ID: <20111118223755.A0417473E4@hg.openjdk.java.net> Changeset: 5c8c7bef6403 Author: jcoomes Date: 2011-10-28 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c8c7bef6403 7106092: Bump the hs23 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: d5c4c73aa855 Author: dholmes Date: 2011-10-27 18:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5c4c73aa855 7104173: sun/tools tests fail with debug build after 7012206 Summary: Disable PrintVMOptions in embedded debug builds so tests are unaffected by extra output Reviewed-by: twisti, coleenp, phh, fparain, dsamersoff ! src/share/vm/runtime/globals.hpp Changeset: 6da94c5a6746 Author: dholmes Date: 2011-10-30 18:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6da94c5a6746 Merge Changeset: 95009f678859 Author: brutisso Date: 2011-11-01 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95009f678859 7106766: Move the precompiled header from the src/share/vm directory Summary: Moved precompiled.hpp to src/share/vm/precompiled Reviewed-by: coleenp, dholmes Contributed-by: rbackman ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/windows/makefiles/vm.make - src/share/vm/precompiled.hpp + src/share/vm/precompiled/precompiled.hpp Changeset: 3e609627e780 Author: jcoomes Date: 2011-11-04 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3e609627e780 Merge - src/share/vm/precompiled.hpp Changeset: b92ca8e229d2 Author: jcoomes Date: 2011-11-04 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b92ca8e229d2 Added tag hs23-b05 for changeset 3e609627e780 ! .hgtags Changeset: 088d09a130ff Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/088d09a130ff Added tag jdk8-b13 for changeset b92ca8e229d2 ! .hgtags Changeset: 883328bfc472 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/883328bfc472 Added tag jdk8-b14 for changeset 088d09a130ff ! .hgtags From lana.steuck at oracle.com Fri Nov 18 14:37:48 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:48 +0000 Subject: hg: jdk8/tl/langtools: 9 new changesets Message-ID: <20111118223811.BD4E8473E5@hg.openjdk.java.net> Changeset: 65444e7998e3 Author: katleman Date: 2011-11-10 11:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65444e7998e3 Added tag jdk8-b13 for changeset ae25163501bc ! .hgtags Changeset: b7003a6a530b Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/15ea1c763273 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: c79cf0f04be6 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/16906df5bffc Added tag jdk8-b14 for changeset 58f1325d72b2 ! .hgtags Changeset: f07d6f55d39a Author: lana Date: 2011-11-18 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f07d6f55d39a Merge From lana.steuck at oracle.com Fri Nov 18 14:39:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:39:47 +0000 Subject: hg: jdk8/tl/jdk: 50 new changesets Message-ID: <20111118224756.C723B473E6@hg.openjdk.java.net> Changeset: bfd720647db2 Author: yhuang Date: 2011-10-31 20:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd720647db2 7077119: remove past transition dates from CurrencyData.properties file Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt Changeset: cfc6fd491b97 Author: yhuang Date: 2011-10-31 21:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfc6fd491b97 6755060: Collator.compare() does not compare correctly for the Thai locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/CollationData_th.java + test/sun/text/resources/Collator/Bug6755060.java Changeset: 0549410acf26 Author: yhuang Date: 2011-10-31 21:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0549410acf26 Merge Changeset: f3227efde13d Author: yhuang Date: 2011-10-31 21:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3227efde13d 7101495: In Latvia first day of week is Monday Reviewed-by: naoto, peytoia ! src/share/classes/sun/util/resources/CalendarData_lv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ab837acc60fb Author: yhuang Date: 2011-10-31 21:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab837acc60fb Merge Changeset: 631ee738378a Author: mfang Date: 2011-11-03 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/631ee738378a Merge Changeset: 94e5604022fa Author: ngmr Date: 2011-09-15 19:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e5604022fa 6988099: jvmti demos missing Publisher (COMPANY resource) in dlls/exes on windows Summary: Add creation/linking of resource data to link step for demos on Windows Reviewed-by: dcubed, zgu, ngmr, ohair Contributed-by: Sean Chou ! make/common/Demo.gmk Changeset: 5791714b9472 Author: ohair Date: 2011-11-04 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5791714b9472 Merge Changeset: 4cb2e8679b27 Author: katleman Date: 2011-11-09 13:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4cb2e8679b27 Merge Changeset: 52bd7fc8fcb0 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52bd7fc8fcb0 Added tag jdk8-b13 for changeset 4cb2e8679b27 ! .hgtags Changeset: 9de1dbf8c9be Author: lana Date: 2011-10-26 17:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9de1dbf8c9be Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 76defa20906a Author: ngmr Date: 2011-09-23 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76defa20906a 7105640: Unix printing does not check the result of exec'd lpr/lp command Summary: Add checking, exception for spool process failure Reviewed-by: prr, jgodinez Contributed-by: Neil Richards ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: 4544585a3cea Author: lana Date: 2011-11-05 14:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4544585a3cea Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: aa3f5117c485 Author: rupashka Date: 2011-10-17 15:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa3f5117c485 7099251: javax.swing.text.html.HTMLDocument.insertAfterStart(null, something) throws NPE Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 4f74e3fdf86b Author: rupashka Date: 2011-10-17 16:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f74e3fdf86b 7100004: javax.swing.JTable.setAutoCreateRowSorter(boolean autoCreateRowSorter) should mention default value Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/JTable.java Changeset: f1dbc62c7c6d Author: rupashka Date: 2011-10-17 17:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1dbc62c7c6d 7077293: javax/swing/JComponent/4337267/bug4337267.java failed on windows 2003 Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: a2f5d7049258 Author: dbuck Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2f5d7049258 6887286: StackOverflowError at sun.awt.image.ImageWatched$WeakLink.isWatcher Summary: Fixed OffScreenImageSource to call imageComplete() with SINGLEFAMEDONE, not STATICIMAGEDONE. This fixed memory leak (that caused SOFE when we use recursion to iterate over linked list). Reviewed-by: bae ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 7636a62aba7e Author: anthony Date: 2011-11-01 18:01 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7636a62aba7e 7104625: sun.awt.X11.XEvent is creating 600 MB of char[] for no good reason Summary: Wrap logging calls with if(){} statements Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/XComponentPeer.java Changeset: ac55f169fadd Author: anthony Date: 2011-11-01 18:03 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac55f169fadd 7105529: XAWT: Optimize getFieldsAsString() methods generated by WrapperGenerator Summary: Replace string concatenation with StringBuilder.append() Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java Changeset: 41610a897379 Author: rupashka Date: 2011-11-02 14:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41610a897379 6624077: Regression test fails: closed/javax/swing/ToolTipManager/6256140/bug6256140.java Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/ToolTipManager/Test6256140.java Changeset: 8068f1584715 Author: mrkam Date: 2011-11-02 17:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8068f1584715 7074853: TransparentRuler demos Readme should mention the correct jar file name Reviewed-by: rupashka ! src/share/demo/jfc/TransparentRuler/README.txt Changeset: 323f6d046cc9 Author: rupashka Date: 2011-11-02 23:53 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/323f6d046cc9 7049024: DnD fails with JTextArea and JTextField Reviewed-by: rupashka Contributed-by: Sean Chou ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/JTextArea/7049024/bug7049024.java Changeset: 7c29751a9331 Author: rupashka Date: 2011-11-03 14:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c29751a9331 6955919: Intermittent ClassCastException in bug4492274 test Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JEditorPane/4492274/bug4492274.java + test/javax/swing/JEditorPane/4492274/test.html Changeset: 1c0624d9a2b6 Author: ngmr Date: 2011-10-13 13:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c0624d9a2b6 7107957: AWT: Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: anthony, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h Changeset: adb31ff942ef Author: rupashka Date: 2011-11-07 16:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adb31ff942ef 7080203: JTree.getSelectionPaths() now returns empty array instead of null Reviewed-by: malenkov ! src/share/classes/javax/swing/JTree.java Changeset: d219e0b11327 Author: lana Date: 2011-11-07 10:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d219e0b11327 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: f8a3dff76b48 Author: rupashka Date: 2011-11-08 14:36 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8a3dff76b48 7107585: Test incorrect calculate position of object on frame Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JSlider/6348946/bug6348946.java Changeset: af4fb33fca29 Author: lana Date: 2011-11-08 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af4fb33fca29 Merge Changeset: 0bb498332894 Author: lana Date: 2011-11-08 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bb498332894 Merge Changeset: 51db54a3b953 Author: lana Date: 2011-11-14 18:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51db54a3b953 Merge Changeset: 3b2128c89361 Author: alanb Date: 2011-06-15 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b2128c89361 7000600: InputStream.skip() makes sensitive data accessible to malicious code Reviewed-by: hawtin, chegar ! src/share/classes/java/io/InputStream.java Changeset: 06e0d91548b3 Author: anthony Date: 2011-06-21 20:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06e0d91548b3 7022113: Security icon can be moved behind the window using the com.sun.SecurityWarning.setPosition() method Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: d32b75c73389 Author: alanb Date: 2011-06-27 20:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d32b75c73389 7059259: (process) ProcessBuilder.start permission check should be improved when redirecting output to append Reviewed-by: hawtin ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 446b13a08aca Author: asaha Date: 2011-06-27 12:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/446b13a08aca Merge Changeset: 4fdd1a44e846 Author: asaha Date: 2011-06-27 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fdd1a44e846 Merge Changeset: 3e42f7893861 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e42f7893861 Merge Changeset: f578448792b9 Author: ksrini Date: 2011-07-15 13:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f578448792b9 7057857: SIGSEGV [libunpack.so] store_Utf8_char(signed char*, unsigned short) in java.util.jar.pack200 Reviewed-by: jrose, asaha, hawtin ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h Changeset: 4b20375fe623 Author: asaha Date: 2011-07-19 11:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b20375fe623 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: bc9c70e57f62 Author: asaha Date: 2011-07-20 09:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc9c70e57f62 7032417: Fix for 6981922 does not address multiple VM case Reviewed-by: michaelm ! src/share/classes/sun/net/ResourceManager.java Changeset: a7177942302f Author: asaha Date: 2011-07-20 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7177942302f 7023640: calculation for malloc size in TransformHelper.c could overflow an integer Reviewed-by: flar ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 6c76f2a49061 Author: denis Date: 2011-07-22 21:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c76f2a49061 7019773: AWTKeyStroke.ctor is a mutable static Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: b25558c39ffc Author: smarks Date: 2011-08-30 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b25558c39ffc 7077466: fix for RMI DGC Reviewed-by: valeriep ! src/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: efd8035f3d14 Author: smarks Date: 2011-08-30 17:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efd8035f3d14 7083012: fix for RMI Registry Reviewed-by: jdn, valeriep ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java Changeset: 27bda11f1330 Author: smarks Date: 2011-09-21 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27bda11f1330 7092186: adjust package access in rmiregistry Reviewed-by: asaha, coffeys ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 42eb725f739c Author: xuelei Date: 2011-09-29 17:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42eb725f739c 7064341: jsse/runtime security problem Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.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/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java Changeset: 53a16cf28db3 Author: xuelei Date: 2011-09-30 18:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53a16cf28db3 7096936: issue in jsse/runtime 7096937: TEST: com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java need modification as a result of TLS fix Reviewed-by: wetmore, jdn, xuelei ! src/share/classes/com/sun/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java Changeset: 27a8f4fc555a Author: asaha Date: 2011-11-14 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27a8f4fc555a Merge ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 99632935785e Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99632935785e Merge Changeset: 00e2c88e2234 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00e2c88e2234 Added tag jdk8-b14 for changeset 99632935785e ! .hgtags Changeset: cd37d8066437 Author: lana Date: 2011-11-18 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd37d8066437 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From xuelei.fan at oracle.com Fri Nov 18 18:26:32 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 19 Nov 2011 10:26:32 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC66F04.2070005@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> <4EC66DDB.4060702@oracle.com> <4EC66F04.2070005@oracle.com> Message-ID: <4EC713D8.5010209@oracle.com> >> Performance is a big issue here. What do you think if >> we change the get key length method of pkcs11.P11Key >> and mscapi.Key for better performance? > How do you want to change? I thought to expose the package private class and method. The update looks like: package sun.security.pkcs11; ... - abstract class P11Key implements Key { + abstract public class P11Key implements Key { ... - int keyLength() { + public int keyLength() { ... } It is similar for MSCAPI. Then we may be able to call the keyLength() method directly. But as MSCPI is only available for Windows, we may run into compiling problem on non-windows platforms. Another solution is to define a new interface: package sun.security.util; public interface Measurable { public int getLength(); } And updated P11Key and MSCPI Key accordingly to implement the Measureable interface: package sun.security.pkcs11; ... - abstract class P11Key implements Key, Measurable { + abstract class P11Key implements Key { ... - int keyLength() { + public int getLength() { ... } It is similar for MSCAPI Key. Xuelei On 11/18/2011 10:43 PM, Weijun Wang wrote: > > > On 11/18/2011 10:38 PM, Xuelei Fan wrote: >> On 11/18/2011 10:16 PM, Weijun Wang wrote: >>> >>> On 11/18/2011 08:39 PM, Xuelei Fan wrote: >>>> The VPN is awesomely bad today. >>>> >>>> The webrev in cr.openjdk is >>>> http://cr.openjdk.java.net/~xuelei/7106773/webrev.01/ >>>> >>>> On 11/18/2011 7:39 PM, Weijun Wang wrote: >>>>> Oh, there seems to be much more non-trivial code changes then the >>>>> previous version of webrev. >>>>> >>>>> I now focus on the utility class KeyLength.java: >>>>> >>>>> In ReflectiveProvider, how about adding a "." at the end of package >>>>> name? >>>>> >>>> It's safer. >>>> >>>>> Also, is the while loop really necessary in getKeyLengthMethod? Why >>>>> not >>>>> directly call getDeclaredMethod on the the baseClassName? If you >>>>> want to >>>>> make sure the current class is a subclass of the baseClassName, try >>>>> isAssignableFrom. >>>>> >>>> It's a little strange of the implement of getKeyLengthMethod() because >>>> of the following causes: >>>> 1. Class.getDeclaredMethod() cannot return inherited methods. >>>> >>>> 2. Class.forName("sun.security.pkcs11.P11Key") is not reliable. >>>> The current class loader is not always able to find the P11Key >>>> class. >>> >>> Oh, In which case? >>> >> In the previous webrev, I found the case while running >> test/sun/security/pkcs11/KeyStore/ClientAuth.java while call >> Class.forName() with the current class loader. >> >>>> As you saw in the previous webrev, I specified the class loader >>>> while >>>> searching for the class: >>>> Class.forName("sun.security.pkcs11.P11Key", true, >>>> key.getClass().getClassLoader()); >>>> >>>> There is one assumption that every key will come from the same >>>> class >>>> loader during the JVM life. So we can cache the loaded P11Key class. >>>> It's a little risky. >>>> >>>> And more, it's OK when there is only one PKCS11 provider. >>>> However, >>>> while we adding MSCAPI in, we will have to look through both PKCS11 >>>> provider and MSCAPI provider in order to select the proper cached key >>>> class. If we get a key from none of PKCS11 and MSCAPI, we will continue >>>> calling the Class.forName() repeatedly until we are able to encounter >>>> the PKCS11 key or MSCAPI key. It's very bad in performance. >>>> >>>> The calling in the getKeyLengthMethod() is lightweight, and we >>>> don't >>>> have to worry about the class loader any more. >>> >>> Calling getDeclaredMethod each time is a waste. How about just >>> >>> while (clazz != null) { >>> if (clazz.getName().equals(baseClassName)) { >>> // do sth >>> break; >>> } >>> clazz = clazz.getSuperclass(); >>> } >>> >>> Also, you're using methods in reflection. Is it faster to use fields? >>> >> I also concerns about the override of the target method, although there >> is no such override at present. From some reports, it seems that fields >> reflection cost more cycles than method reflection. > > Oh, I thought get a field is simpler. > >> >> Performance is a big issue here. What do you think if we change the get >> key length method of pkcs11.P11Key and mscapi.Key for better performance? > > How do you want to change? > > -Max > >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>>> >>>>> As for the test, I was thinking that you can add a unit test on the >>>>> KeyLength class itself. >>>>> >>>> I may add some new and simple tests on KeyLength only. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 11/17/2011 11:14 PM, Xuelei Fan wrote: >>>>>> Sean, could you also review the fix? I plan to backport the fix to >>>>>> JDK >>>>>> 7, so that the key size constraints for both JSSE and CertPath can >>>>>> work >>>>>> with PKCS11 and MSCPI. >>>>>> >>>>>> updated webrev: >>>>>> http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ >>>>>> >>>>>> In the new webrev, I add a new KeyLength class under >>>>>> sun.security.util. >>>>>> I think it may be useful for other models. >>>>>> >>>>>> On 11/11/2011 2:33 PM, Weijun Wang wrote: >>>>>>> SSLContextVersion.java: >>>>>>> >>>>>>> typo: suported -> supported >>>>>>> >>>>>> Updated. >>>>>> >>>>>>> DisabledAlgorithmConstraints.java: >>>>>>> >>>>>>> When can size == 0? Why it's not allowed? >>>>>>> >>>>>> It's a line of dummy code in case the get key size method return 0. >>>>>> >>>>>>> Yes, I think the reflection calls should be wrapped in doPriv >>>>>>> >>>>>>> Please also consider keys from MSCAPI >>>>>>> >>>>>> Support MSCAPI now. >>>>>> >>>>>>> Try looking at sun.misc.SharedSecrets and see if it's better >>>>>>> for you. Probably not. That class is used to share non-public >>>>>>> methods in public classes. Not the same case here. >>>>>>> >>>>>>> SignatureAndHashAlgorithm.java: >>>>>>> >>>>>>> Is it possible to combine expected and signingKey into a >>>>>>> single >>>>>>> signingKey? Of course that means it might need to be never >>>>>>> null >>>>>>> and all key alg call it in a consistent way. I wonder if this >>>>>>> is OK for you. >>>>>>> >>>>>> It not always work. For example, the key algorithm may be "EC", >>>>>> but the >>>>>> expected algorithm may be "ECDSA". >>>>>> >>>>>>> The RSAKey interface seems not used anywhere. >>>>>>> >>>>>> Yes, removed. >>>>>> >>>>>>> How about changing >>>>>>> >>>>>>> 288 } // Otherwise, cannot determine the key size, >>>>>>> prefer the >>>>>>> most >>>>>>> 289 // perferable hash algorithm. >>>>>>> >>>>>>> to >>>>>>> >>>>>>> maxDigestLength = Integer.MAX_VALUE; >>>>>>> >>>>>>> then you don't need to assign -1 and check for< 0 later. >>>>>>> >>>>>> Good point. >>>>>> >>>>>>> I would be glad if lines 302-306 can be further indented 4 >>>>>>> spaces >>>>>>> >>>>>>> The comment on lines 268-273 is confusing, because you did >>>>>>> calculate >>>>>>> maxDigestAlgorithm for 512 bits key later. >>>>>>> >>>>>>> Personally, I prefer comments on 274-281 and codes on 284-288 >>>>>>> to be from a smaller keySize to bigger ones, but everything is >>>>>>> OK. >>>>>>> >>>>>> Updated. >>>>>> >>>>>>> Test: >>>>>>> >>>>>>> I would like a unit test on >>>>>>> DisabledAlgorithmConstraints::getKeySize. >>>>>>> Hopefully the test can cover all SecretKey and PrivateKey from >>>>>>> all >>>>>>> providers with all keysizes. >>>>>>> >>>>>> Added some new tests for PKCS11 and MSCAPI. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> On 11/11/2011 01:09 PM, Xuelei Fan wrote: >>>>>>>> Hi Weijun, >>>>>>>> >>>>>>>> Are you available to review my fix for CR 7106773? The fix in JSSE >>>>>>>> part >>>>>>>> is straightforward in that the call to >>>>>>>> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an >>>>>>>> additional >>>>>>>> Key parameter for RSA key exchanges. The significant change is at >>>>>>>> sun/security/util/DisabledAlgorithmConstraints.java. I modified the >>>>>>>> code >>>>>>>> in order to get the key size of the unextractable key in PKCS#11 >>>>>>>> device. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>> >>>> >> From alan.bateman at oracle.com Sat Nov 19 12:09:45 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 19 Nov 2011 20:09:45 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20111119201024.60B18473FC@hg.openjdk.java.net> Changeset: c98235762b30 Author: alanb Date: 2011-11-19 19:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c98235762b30 6818464: TEST_BUG: java/util/Timer/KillThread.java failing intermittently Reviewed-by: dholmes, alanb, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 8be37eae9598 Author: alanb Date: 2011-11-19 19:59 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8be37eae9598 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf Reviewed-by: dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/Args.java Changeset: 450c17e4808d Author: alanb Date: 2011-11-19 20:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/450c17e4808d 6860309: TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java Reviewed-by: alanb, dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java From jim.holmlund at sun.com Sat Nov 19 16:00:54 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Sun, 20 Nov 2011 00:00:54 +0000 Subject: hg: jdk8/tl/langtools: 7110611: compiler message file broken for javac -fullversion Message-ID: <20111120000059.A5396473FE@hg.openjdk.java.net> Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/07599bd780ca 7110611: compiler message file broken for javac -fullversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java From xuelei.fan at oracle.com Sun Nov 20 19:06:00 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Nov 2011 11:06:00 +0800 Subject: Code review request: 7113275, compatibility issue with MD2 trust anchor and old X509TrustManager Message-ID: <4EC9C018.1010309@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/7113275/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113275 Test MD2InTrustAnchor.java is used to test that MD2 in trust anchor is able to work with the default trust manager (X509ExtendedTrustManager). Test TrustTrustedCert.java is used to test that MD2 in trust anchor is able to work with the un-extended trust manager (X509TrustManager). Some customized trust manages developed in JDK 6 did not know the features in JDK 7, and may not check algorithm constraints. I think we need the addition algorithm constraint check for un-extended trust manager in order to ensure that the TM comply to security constraints defined by security property, jdk.certpath.disabledAlgorithms. The algorithm check of certification chain is light weight, so even the customized trust manager has already managed to check the algorithm constraints during certification path validation, the performance hurt is very limited. Thanks, Xuelei From xuelei.fan at oracle.com Sun Nov 20 23:30:43 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Nov 2011 15:30:43 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC713D8.5010209@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> <4EC66DDB.4060702@oracle.com> <4EC66F04.2070005@oracle.com> <4EC713D8.5010209@oracle.com> Message-ID: <4EC9FE23.2060508@oracle.com> new webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.02/ I run a few performance tests about the reflection in KeyLength.java. The result shows that the Method.invoke() does not hurt too much performance comparing to directly calling Object.method(). Most of the cycle is spent on searching for the method and implementation class. In the updated KeyLength.java, I use cached implement classes and methods. If the current key is a sub-class of one of the cached classes, the cached method will be used. As will improve the performance significantly. And there is not much performance hurt overall. Only KeyLength.java is updated in this webrev. Thanks, Xuelei On 11/19/2011 10:26 AM, Xuelei Fan wrote: >>> Performance is a big issue here. What do you think if >>> we change the get key length method of pkcs11.P11Key >>> and mscapi.Key for better performance? >> How do you want to change? > > I thought to expose the package private class and method. The update > looks like: > > package sun.security.pkcs11; > ... > - abstract class P11Key implements Key { > + abstract public class P11Key implements Key { > ... > - int keyLength() { > + public int keyLength() { > ... > } > > > It is similar for MSCAPI. Then we may be able to call the keyLength() > method directly. > > But as MSCPI is only available for Windows, we may run into compiling > problem on non-windows platforms. > > > Another solution is to define a new interface: > package sun.security.util; > public interface Measurable { > public int getLength(); > } > > And updated P11Key and MSCPI Key accordingly to implement the > Measureable interface: > package sun.security.pkcs11; > ... > - abstract class P11Key implements Key, Measurable { > + abstract class P11Key implements Key { > ... > - int keyLength() { > + public int getLength() { > ... > } > > It is similar for MSCAPI Key. > > Xuelei > > On 11/18/2011 10:43 PM, Weijun Wang wrote: >> >> >> On 11/18/2011 10:38 PM, Xuelei Fan wrote: >>> On 11/18/2011 10:16 PM, Weijun Wang wrote: >>>> >>>> On 11/18/2011 08:39 PM, Xuelei Fan wrote: >>>>> The VPN is awesomely bad today. >>>>> >>>>> The webrev in cr.openjdk is >>>>> http://cr.openjdk.java.net/~xuelei/7106773/webrev.01/ >>>>> >>>>> On 11/18/2011 7:39 PM, Weijun Wang wrote: >>>>>> Oh, there seems to be much more non-trivial code changes then the >>>>>> previous version of webrev. >>>>>> >>>>>> I now focus on the utility class KeyLength.java: >>>>>> >>>>>> In ReflectiveProvider, how about adding a "." at the end of package >>>>>> name? >>>>>> >>>>> It's safer. >>>>> >>>>>> Also, is the while loop really necessary in getKeyLengthMethod? Why >>>>>> not >>>>>> directly call getDeclaredMethod on the the baseClassName? If you >>>>>> want to >>>>>> make sure the current class is a subclass of the baseClassName, try >>>>>> isAssignableFrom. >>>>>> >>>>> It's a little strange of the implement of getKeyLengthMethod() because >>>>> of the following causes: >>>>> 1. Class.getDeclaredMethod() cannot return inherited methods. >>>>> >>>>> 2. Class.forName("sun.security.pkcs11.P11Key") is not reliable. >>>>> The current class loader is not always able to find the P11Key >>>>> class. >>>> >>>> Oh, In which case? >>>> >>> In the previous webrev, I found the case while running >>> test/sun/security/pkcs11/KeyStore/ClientAuth.java while call >>> Class.forName() with the current class loader. >>> >>>>> As you saw in the previous webrev, I specified the class loader >>>>> while >>>>> searching for the class: >>>>> Class.forName("sun.security.pkcs11.P11Key", true, >>>>> key.getClass().getClassLoader()); >>>>> >>>>> There is one assumption that every key will come from the same >>>>> class >>>>> loader during the JVM life. So we can cache the loaded P11Key class. >>>>> It's a little risky. >>>>> >>>>> And more, it's OK when there is only one PKCS11 provider. >>>>> However, >>>>> while we adding MSCAPI in, we will have to look through both PKCS11 >>>>> provider and MSCAPI provider in order to select the proper cached key >>>>> class. If we get a key from none of PKCS11 and MSCAPI, we will continue >>>>> calling the Class.forName() repeatedly until we are able to encounter >>>>> the PKCS11 key or MSCAPI key. It's very bad in performance. >>>>> >>>>> The calling in the getKeyLengthMethod() is lightweight, and we >>>>> don't >>>>> have to worry about the class loader any more. >>>> >>>> Calling getDeclaredMethod each time is a waste. How about just >>>> >>>> while (clazz != null) { >>>> if (clazz.getName().equals(baseClassName)) { >>>> // do sth >>>> break; >>>> } >>>> clazz = clazz.getSuperclass(); >>>> } >>>> >>>> Also, you're using methods in reflection. Is it faster to use fields? >>>> >>> I also concerns about the override of the target method, although there >>> is no such override at present. From some reports, it seems that fields >>> reflection cost more cycles than method reflection. >> >> Oh, I thought get a field is simpler. >> >>> >>> Performance is a big issue here. What do you think if we change the get >>> key length method of pkcs11.P11Key and mscapi.Key for better performance? >> >> How do you want to change? >> >> -Max >> >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>>> >>>>>> As for the test, I was thinking that you can add a unit test on the >>>>>> KeyLength class itself. >>>>>> >>>>> I may add some new and simple tests on KeyLength only. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 11/17/2011 11:14 PM, Xuelei Fan wrote: >>>>>>> Sean, could you also review the fix? I plan to backport the fix to >>>>>>> JDK >>>>>>> 7, so that the key size constraints for both JSSE and CertPath can >>>>>>> work >>>>>>> with PKCS11 and MSCPI. >>>>>>> >>>>>>> updated webrev: >>>>>>> http://javaweb.us.oracle.com/~xf138604/bugbios/7106773/webrev.01/ >>>>>>> >>>>>>> In the new webrev, I add a new KeyLength class under >>>>>>> sun.security.util. >>>>>>> I think it may be useful for other models. >>>>>>> >>>>>>> On 11/11/2011 2:33 PM, Weijun Wang wrote: >>>>>>>> SSLContextVersion.java: >>>>>>>> >>>>>>>> typo: suported -> supported >>>>>>>> >>>>>>> Updated. >>>>>>> >>>>>>>> DisabledAlgorithmConstraints.java: >>>>>>>> >>>>>>>> When can size == 0? Why it's not allowed? >>>>>>>> >>>>>>> It's a line of dummy code in case the get key size method return 0. >>>>>>> >>>>>>>> Yes, I think the reflection calls should be wrapped in doPriv >>>>>>>> >>>>>>>> Please also consider keys from MSCAPI >>>>>>>> >>>>>>> Support MSCAPI now. >>>>>>> >>>>>>>> Try looking at sun.misc.SharedSecrets and see if it's better >>>>>>>> for you. Probably not. That class is used to share non-public >>>>>>>> methods in public classes. Not the same case here. >>>>>>>> >>>>>>>> SignatureAndHashAlgorithm.java: >>>>>>>> >>>>>>>> Is it possible to combine expected and signingKey into a >>>>>>>> single >>>>>>>> signingKey? Of course that means it might need to be never >>>>>>>> null >>>>>>>> and all key alg call it in a consistent way. I wonder if this >>>>>>>> is OK for you. >>>>>>>> >>>>>>> It not always work. For example, the key algorithm may be "EC", >>>>>>> but the >>>>>>> expected algorithm may be "ECDSA". >>>>>>> >>>>>>>> The RSAKey interface seems not used anywhere. >>>>>>>> >>>>>>> Yes, removed. >>>>>>> >>>>>>>> How about changing >>>>>>>> >>>>>>>> 288 } // Otherwise, cannot determine the key size, >>>>>>>> prefer the >>>>>>>> most >>>>>>>> 289 // perferable hash algorithm. >>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> maxDigestLength = Integer.MAX_VALUE; >>>>>>>> >>>>>>>> then you don't need to assign -1 and check for< 0 later. >>>>>>>> >>>>>>> Good point. >>>>>>> >>>>>>>> I would be glad if lines 302-306 can be further indented 4 >>>>>>>> spaces >>>>>>>> >>>>>>>> The comment on lines 268-273 is confusing, because you did >>>>>>>> calculate >>>>>>>> maxDigestAlgorithm for 512 bits key later. >>>>>>>> >>>>>>>> Personally, I prefer comments on 274-281 and codes on 284-288 >>>>>>>> to be from a smaller keySize to bigger ones, but everything is >>>>>>>> OK. >>>>>>>> >>>>>>> Updated. >>>>>>> >>>>>>>> Test: >>>>>>>> >>>>>>>> I would like a unit test on >>>>>>>> DisabledAlgorithmConstraints::getKeySize. >>>>>>>> Hopefully the test can cover all SecretKey and PrivateKey from >>>>>>>> all >>>>>>>> providers with all keysizes. >>>>>>>> >>>>>>> Added some new tests for PKCS11 and MSCAPI. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> On 11/11/2011 01:09 PM, Xuelei Fan wrote: >>>>>>>>> Hi Weijun, >>>>>>>>> >>>>>>>>> Are you available to review my fix for CR 7106773? The fix in JSSE >>>>>>>>> part >>>>>>>>> is straightforward in that the call to >>>>>>>>> SignatureAndHashAlgorithm.getPreferableAlgorithm() needs an >>>>>>>>> additional >>>>>>>>> Key parameter for RSA key exchanges. The significant change is at >>>>>>>>> sun/security/util/DisabledAlgorithmConstraints.java. I modified the >>>>>>>>> code >>>>>>>>> in order to get the key size of the unextractable key in PKCS#11 >>>>>>>>> device. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>> >>>>> >>> > From weijun.wang at oracle.com Mon Nov 21 00:34:29 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Nov 2011 16:34:29 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4EC9FE23.2060508@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> <4EC66DDB.4060702@oracle.com> <4EC66F04.2070005@oracle.com> <4EC713D8.5010209@oracle.com> <4EC9FE23.2060508@oracle.com> Message-ID: <4ECA0D15.3040707@oracle.com> I removed most of the thread and keep some sections below: On 11/21/2011 03:30 PM, Xuelei Fan wrote: > new webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.02/ What is synchronized for? Why only on the for block? This won't prevent map iteration and insertion at the same time. > >> >> Another solution is to define a new interface: >> package sun.security.util; >> public interface Measurable { >> public int getLength(); >> } >> >> And updated P11Key and MSCPI Key accordingly to implement the >> Measureable interface: >> package sun.security.pkcs11; >> ... >> - abstract class P11Key implements Key, Measurable { >> + abstract class P11Key implements Key { >> ... >> - int keyLength() { >> + public int getLength() { >> ... >> } >> >> It is similar for MSCAPI Key. How about this approach? This looks very safe. >> >>>>> >>>>> Calling getDeclaredMethod each time is a waste. How about just >>>>> >>>>> while (clazz != null) { >>>>> if (clazz.getName().equals(baseClassName)) { >>>>> // do sth >>>>> break; >>>>> } >>>>> clazz = clazz.getSuperclass(); >>>>> } >>>>> >>>>> Also, you're using methods in reflection. Is it faster to use fields? >>>>> >>>> I also concerns about the override of the target method, although there >>>> is no such override at present. From some reports, it seems that fields >>>> reflection cost more cycles than method reflection. You mentioned "concerns about the override of the target method". Thanks Max From xuelei.fan at oracle.com Mon Nov 21 04:05:05 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Nov 2011 20:05:05 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4ECA0D15.3040707@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> <4EC66DDB.4060702@oracle.com> <4EC66F04.2070005@oracle.com> <4EC713D8.5010209@oracle.com> <4EC9FE23.2060508@oracle.com> <4ECA0D15.3040707@oracle.com> Message-ID: <4ECA3E71.7090707@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.03/ On 11/21/2011 4:34 PM, Weijun Wang wrote: > I removed most of the thread and keep some sections below: > > On 11/21/2011 03:30 PM, Xuelei Fan wrote: >> new webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.02/ > > What is synchronized for? Why only on the for block? This won't prevent > map iteration and insertion at the same time. > You're right. The SynchronizedMap is not necessary. Changed to use normal hash map, and synchronizing the map in both iteration and insertion block. >> >>> >>> Another solution is to define a new interface: >>> package sun.security.util; >>> public interface Measurable { >>> public int getLength(); >>> } >>> >>> And updated P11Key and MSCPI Key accordingly to implement the >>> Measureable interface: >>> package sun.security.pkcs11; >>> ... >>> - abstract class P11Key implements Key, Measurable { >>> + abstract class P11Key implements Key { >>> ... >>> - int keyLength() { >>> + public int getLength() { >>> ... >>> } >>> >>> It is similar for MSCAPI Key. > > How about this approach? This looks very safe. > I also prefer this approach, although it need more updates in PKCS11 and MSCPI source code. If you vote for this approach, I will try to implement it. Thanks, Xuelei >>> >>>>>> >>>>>> Calling getDeclaredMethod each time is a waste. How about just >>>>>> >>>>>> while (clazz != null) { >>>>>> if (clazz.getName().equals(baseClassName)) { >>>>>> // do sth >>>>>> break; >>>>>> } >>>>>> clazz = clazz.getSuperclass(); >>>>>> } >>>>>> >>>>>> Also, you're using methods in reflection. Is it faster to use fields? >>>>>> >>>>> I also concerns about the override of the target method, although >>>>> there >>>>> is no such override at present. From some reports, it seems that >>>>> fields >>>>> reflection cost more cycles than method reflection. > > You mentioned "concerns about the override of the target method". > > Thanks > Max From alan.bateman at oracle.com Mon Nov 21 04:54:18 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 21 Nov 2011 12:54:18 +0000 Subject: hg: jdk8/tl/jdk: 7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Message-ID: <20111121125440.9B5784740C@hg.openjdk.java.net> Changeset: 184578f3e8b9 Author: alanb Date: 2011-11-21 12:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184578f3e8b9 7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Reviewed-by: forax, chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/Stop.java From alan.bateman at oracle.com Mon Nov 21 05:00:41 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 21 Nov 2011 13:00:41 +0000 Subject: hg: jdk8/tl/jdk: 7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross thread variable declaration Message-ID: <20111121130051.0B6B34740D@hg.openjdk.java.net> Changeset: 2db942c7eb9c Author: alanb Date: 2011-11-21 12:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2db942c7eb9c 7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross thread variable declaration Reviewed-by: dholmes, alanb Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java From tomasg at primekey.se Wed Nov 2 02:37:34 2011 From: tomasg at primekey.se (Tomas Gustavsson) Date: Wed, 02 Nov 2011 09:37:34 -0000 Subject: Review 7053252: New regression test does not compile on windows-amd64 In-Reply-To: <4EAF2248.1050507@oracle.com> References: <4EAF10DE.4050506@oracle.com> <4EAF2248.1050507@oracle.com> Message-ID: <4EB10F5B.60500@primekey.se> Will there ever be a pkcs11 for windows-x64? Cheers, Tomas On 10/31/2011 11:33 PM, Valerie (Yu-Ching) Peng wrote: > Looks good to me. > Valerie > > On 10/31/11 14:19, Brad Wetmore wrote: >> >> Hi Valerie, >> >> http://cr.openjdk.java.net/~wetmore/7053252/ >> >> Review 7053252: New regression test does not compile on windows-amd64 >> >> As you know, there is a broken JDK test on windows-x64 under the >> jdk_security3 target (no pkcs11 library, thus the import fails on >> compile). Someone has to manually check this failure. (Obviously, it >> was me last time, thus the bug! ;) ) >> >> Removing the incorrect import in both jdk7u/jdk8. >> >> Brad >> >> > From paulo.ribeiro at multicert.com Tue Nov 8 03:16:24 2011 From: paulo.ribeiro at multicert.com (Paulo Ricardo Ribeiro) Date: Tue, 08 Nov 2011 11:16:24 +0000 Subject: Unable to wrap key using SunPKCS11 Provider Message-ID: <4EB90F88.1000109@multicert.com> Hello I'm trying to wrap a 3DES key, that is stored in a HSM, using the SunPKCS11 provider: | Cipher wrapper = Cipher.getInstance("DESede/CBC/NOPADDING", getProviderName()); wrapper.init(Cipher.WRAP_MODE, wrappingKey,*new* IvParameterSpec(iv)); cText = wrapper.wrap(wrappedKey); | The problem is that I'm obtaining the following exception: |java.security.InvalidAlgorithmParameterException: Unsupported mode: 3 at sun.security.pkcs11.P11Cipher.implInit(P11Cipher.java:316) at sun.security.pkcs11.P11Cipher.engineInit(P11Cipher.java:280) at javax.crypto.Cipher.init(DashoA13*..) at javax.crypto.Cipher.init(DashoA13*..) | After searching for the source code, I've found that the provider only supports the ENCRYPT_MODE and DECRYPT_MODE |// actual init() implementation *private* *void* implInit(*int* opmode, Key key,*byte*[] iv, SecureRandom random) *throws* InvalidKeyException, InvalidAlgorithmParameterException{ cancelOperation(); *switch* (opmode){ *case* Cipher.ENCRYPT_MODE: encrypt =*true*; *break*; *case* Cipher.DECRYPT_MODE: encrypt =*false*; *break*; *default*: *throw* *new* InvalidAlgorithmParameterException ("Unsupported mode:" + opmode); } (...) } | The full source is available at http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/security/pkcs11/P11Cipher.java.html So, I was wondering if is there a way to wrap a key, using the SunPKCS11 provider. -- *Paulo Ricardo Ribeiro* Departamento de Integra??o e Desenvolvimento *MULTICERT - Servi?os de Certifica??o Electr?nica, S.A.* www.multicert.com ??????????????????????????????????????????????????????????????????????? *Para obter direc??es para as nossas instala??es carregue aqui* *Porto:*Av. Sid?nio Pais, 379, Edif?cio B, Piso 1, Sala 5 ? 4100?468 Porto ? Portugal *T:*+351 223 391 810 | *F: *+351 223 391 811 ??????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111108/d95a5813/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: cibgfegi.png Type: image/png Size: 7530 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111108/d95a5813/cibgfegi.png From dennis.gu at oracle.com Mon Nov 21 06:49:02 2011 From: dennis.gu at oracle.com (Dennis Gu) Date: Mon, 21 Nov 2011 09:49:02 -0500 Subject: Code review request: 7113275, compatibility issue with MD2 trust anchor and old X509TrustManager - approved In-Reply-To: <4EC9C018.1010309@oracle.com> References: <4EC9C018.1010309@oracle.com> Message-ID: <4ECA64DE.1070601@oracle.com> Xuelei Fan wrote: >webrev: http://cr.openjdk.java.net/~xuelei/7113275/webrev.00/ >Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113275 > >Test MD2InTrustAnchor.java is used to test that MD2 in trust anchor is >able to work with the default trust manager (X509ExtendedTrustManager). > >Test TrustTrustedCert.java is used to test that MD2 in trust anchor is >able to work with the un-extended trust manager (X509TrustManager). > >Some customized trust manages developed in JDK 6 did not know the >features in JDK 7, and may not check algorithm constraints. I think we >need the addition algorithm constraint check for un-extended trust >manager in order to ensure that the TM comply to security constraints >defined by security property, jdk.certpath.disabledAlgorithms. > >The algorithm check of certification chain is light weight, so even the >customized trust manager has already managed to check the algorithm >constraints during certification path validation, the performance hurt >is very limited. > >Thanks, >Xuelei > > From frances.ho at oracle.com Mon Nov 21 11:11:06 2011 From: frances.ho at oracle.com (Frances Ho) Date: Mon, 21 Nov 2011 11:11:06 -0800 Subject: Review 7053252: New regression test does not compile on windows-amd64 In-Reply-To: <4EB10F5B.60500@primekey.se> References: <4EAF10DE.4050506@oracle.com> <4EAF2248.1050507@oracle.com> <4EB10F5B.60500@primekey.se> Message-ID: <4ECAA24A.4080105@oracle.com> Hi Tomas, New proposed features for JDK 8 will be posted on java.net (http://openjdk.java.net/jeps), please check there periodically for new additions. Thanks! _Frances On 11/2/2011 2:37 AM, Tomas Gustavsson wrote: > > Will there ever be a pkcs11 for windows-x64? > > Cheers, > Tomas > > > On 10/31/2011 11:33 PM, Valerie (Yu-Ching) Peng wrote: >> Looks good to me. >> Valerie >> >> On 10/31/11 14:19, Brad Wetmore wrote: >>> >>> Hi Valerie, >>> >>> http://cr.openjdk.java.net/~wetmore/7053252/ >>> >>> Review 7053252: New regression test does not compile on windows-amd64 >>> >>> As you know, there is a broken JDK test on windows-x64 under the >>> jdk_security3 target (no pkcs11 library, thus the import fails on >>> compile). Someone has to manually check this failure. (Obviously, it >>> was me last time, thus the bug! ;) ) >>> >>> Removing the incorrect import in both jdk7u/jdk8. >>> >>> Brad >>> >>> >> From valerie.peng at oracle.com Mon Nov 21 11:25:51 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 21 Nov 2011 11:25:51 -0800 Subject: Unable to wrap key using SunPKCS11 Provider In-Reply-To: <4EB90F88.1000109@multicert.com> References: <4EB90F88.1000109@multicert.com> Message-ID: <4ECAA5BF.4050403@oracle.com> The support for key wrapping and unwrapping is tracked under 4898471 "Support for key wrapping and unwrapping" I assume that the 3DES key is unextractable? If yes, I am afraid that this would require that 4898471 be fixed. I'll fix this in jdk7 update and later releases. Thanks, Valerie On 11/08/11 03:16, Paulo Ricardo Ribeiro wrote: > Hello > > I'm trying to wrap a 3DES key, that is stored in a HSM, using the > SunPKCS11 provider: > > | Cipher wrapper = Cipher.getInstance("DESede/CBC/NOPADDING", getProviderName()); > wrapper.init(Cipher.WRAP_MODE, wrappingKey, *new* IvParameterSpec(iv)); > cText = wrapper.wrap(wrappedKey); > | > > > The problem is that I'm obtaining the following exception: > |java.security.InvalidAlgorithmParameterException: Unsupported mode: 3 > at sun.security.pkcs11.P11Cipher.implInit(P11Cipher.java:316) > at sun.security.pkcs11.P11Cipher.engineInit(P11Cipher.java:280) > at javax.crypto.Cipher.init(DashoA13*..) > at javax.crypto.Cipher.init(DashoA13*..) > > | > > After searching for the source code, I've found that the provider only > supports the ENCRYPT_MODE and DECRYPT_MODE > > |// actual init() implementation > *private* *void* implInit(*int* opmode, Key key, *byte*[] iv, > SecureRandom random) > *throws* InvalidKeyException, InvalidAlgorithmParameterException { > cancelOperation(); > *switch* (opmode) { > *case* Cipher.ENCRYPT_MODE: > encrypt = *true*; > *break*; > *case* Cipher.DECRYPT_MODE: > encrypt = *false*; > *break*; > *default*: > *throw* *new* InvalidAlgorithmParameterException > ("Unsupported mode: " + opmode); > } > (...) > } > | > > The full source is available at > http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/security/pkcs11/P11Cipher.java.html > > So, I was wondering if is there a way to wrap a key, using the > SunPKCS11 provider. > > -- > > *Paulo Ricardo Ribeiro* > Departamento de Integra??o e Desenvolvimento > > *MULTICERT - Servi?os de Certifica??o Electr?nica, S.A.* > www.multicert.com > ??????????????????????????????????????????????????????????????????????? > *Para obter direc??es para as nossas instala??es carregue aqui* > > *Porto:* Av. Sid?nio Pais, 379, Edif?cio B, Piso 1, Sala 5 ? 4100?468 > Porto ? Portugal > *T:* +351 223 391 810 | *F: *+351 223 391 811 > ??????????????????????????????????????????????????????????????????????? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111121/5cf23cee/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7530 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111121/5cf23cee/attachment.png From valerie.peng at oracle.com Mon Nov 21 12:30:35 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 21 Nov 2011 12:30:35 -0800 Subject: JDK 8 Code Review Request: 7093090 Reduce synchronization in java.security.Policy.getPolicyNoCheck In-Reply-To: <4EC53D46.6040508@oracle.com> References: <4EC53D46.6040508@oracle.com> Message-ID: <4ECAB4EB.5080304@oracle.com> Sean, Your changes look good to me. Thanks, Valerie On 11/17/11 08:58, Sean Mullan wrote: > Hi Valerie, > > Could you review this one for me? > > http://cr.openjdk.java.net/~mullan/webrevs/7093090/webrev.00/ > > This one was tricky to fix, but I have confirmed that it does indeed fix the > thread contention issue with the customer that reported this. > > The fix involved adding an initialized flag to indicate when the system-wide > policy has been initialized and storing both the flag and the Policy object in > an AtomicReference. Then, I also used the double-check locking idiom to avoid > locking the Policy class when the Policy had already been initialized. > > Thanks, > Sean > From sean.mullan at oracle.com Mon Nov 21 13:59:33 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Nov 2011 16:59:33 -0500 Subject: Code review request: 7113275, compatibility issue with MD2 trust anchor and old X509TrustManager In-Reply-To: <4EC9C018.1010309@oracle.com> References: <4EC9C018.1010309@oracle.com> Message-ID: <4ECAC9C5.8050801@oracle.com> On 11/20/2011 10:06 PM, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net/~xuelei/7113275/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113275 > > Test MD2InTrustAnchor.java is used to test that MD2 in trust anchor is > able to work with the default trust manager (X509ExtendedTrustManager). > > Test TrustTrustedCert.java is used to test that MD2 in trust anchor is > able to work with the un-extended trust manager (X509TrustManager). > > Some customized trust manages developed in JDK 6 did not know the > features in JDK 7, and may not check algorithm constraints. I think we > need the addition algorithm constraint check for un-extended trust > manager in order to ensure that the TM comply to security constraints > defined by security property, jdk.certpath.disabledAlgorithms. > > The algorithm check of certification chain is light weight, so even the > customized trust manager has already managed to check the algorithm > constraints during certification path validation, the performance hurt > is very limited. I believe you could add an optimization that if the TrustManager is an instance of sun.security.ssl.X509TrustManagerImpl, then there is no need to perform the additional certpath constraint checks because the PKIX CertPathValidator will have already checked them. I think the checkAlgorithmConstraints method can be marked static. A nit on line 922, change to: checkedLength--; Cycling through every root certificate each time to find a match in the chain could be costly. Another potential optimization is to copy the root certs into a Map, where the key is simply the Certificate. The value can be null. Then you can just check if the last certificate is in the Map. But even better would be to add a method to TrustManager (or something like that) that returned the trusted Certificate that was used to anchor the chain that was just validated. This would be the most optimal solution. That might be a bit challenging given the API, but something to keep in mind if you enhance the API later on. --Sean From weijun.wang at oracle.com Mon Nov 21 16:41:16 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Nov 2011 08:41:16 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4ECA3E71.7090707@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> <4EC66DDB.4060702@oracle.com> <4EC66F04.2070005@oracle.com> <4EC713D8.5010209@oracle.com> <4EC9FE23.2060508@oracle.com> <4ECA0D15.3040707@oracle.com> <4ECA3E71.7090707@oracle.com> Message-ID: <4ECAEFAC.2090305@oracle.com> I really like this one. Thanks Max On 11/21/2011 08:05 PM, Xuelei Fan wrote: >> > How about this approach? This looks very safe. >> > > I also prefer this approach, although it need more updates in PKCS11 and > MSCPI source code. If you vote for this approach, I will try to > implement it. > From xuelei.fan at oracle.com Mon Nov 21 19:56:34 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 22 Nov 2011 11:56:34 +0800 Subject: Code review request: 7113275, compatibility issue with MD2 trust anchor and old X509TrustManager In-Reply-To: <4ECAC9C5.8050801@oracle.com> References: <4EC9C018.1010309@oracle.com> <4ECAC9C5.8050801@oracle.com> Message-ID: <4ECB1D72.8000203@oracle.com> updated webrev: http://cr.openjdk.java.net/~xuelei/7113275/webrev.01/ On 11/22/2011 5:59 AM, Sean Mullan wrote: > On 11/20/2011 10:06 PM, Xuelei Fan wrote: >> webrev: http://cr.openjdk.java.net/~xuelei/7113275/webrev.00/ >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113275 >> >> Test MD2InTrustAnchor.java is used to test that MD2 in trust anchor is >> able to work with the default trust manager (X509ExtendedTrustManager). >> >> Test TrustTrustedCert.java is used to test that MD2 in trust anchor is >> able to work with the un-extended trust manager (X509TrustManager). >> >> Some customized trust manages developed in JDK 6 did not know the >> features in JDK 7, and may not check algorithm constraints. I think we >> need the addition algorithm constraint check for un-extended trust >> manager in order to ensure that the TM comply to security constraints >> defined by security property, jdk.certpath.disabledAlgorithms. >> >> The algorithm check of certification chain is light weight, so even the >> customized trust manager has already managed to check the algorithm >> constraints during certification path validation, the performance hurt >> is very limited. > > I believe you could add an optimization that if the TrustManager is an > instance of sun.security.ssl.X509TrustManagerImpl, then there is no need > to perform the additional certpath constraint checks because the PKIX > CertPathValidator will have already checked them. > The sun.security.ssl.X509TrustManagerImpl has already been an extension of X509ExtendedTrustManager. If the TM is Oracle JDK's implementation, including the implementation in deploy workspace, the implementation should extend X509ExtendedTrustManager. And then the calling should not fall into the AbstractTrustManagerWrapper. > I think the checkAlgorithmConstraints method can be marked static. > The method calls none-static method getAcceptedIssuers(), or in the new webrev, it need to call the none-static class attribute. So I think it cannot be static. > A nit on line 922, change to: > > checkedLength--; > It's nice. > Cycling through every root certificate each time to find a match in the > chain could be costly. Another potential optimization is to copy the > root certs into a Map, where the key is simply the Certificate. The > value can be null. Then you can just check if the last certificate is in > the Map. > Good point. Instead of a Map, I use a HashSet in the new webrev. I think it should be the same on performance as your suggestion. > But even better would be to add a method to TrustManager (or something > like that) that returned the trusted Certificate that was used to anchor > the chain that was just validated. The current TrustManager are defined to be none-state. As means that it can work in multiple threads safely without synchronization. Above suggestion may not comply to the requirement. We will face new bottleneck if we need to support synchronized calling. However, it sounds like good if we update the existing method to return the trusted certificate: - public void checkClientTrusted() + public X509Certificate checkClientTrusted() It may be challenging to update the return type of existing APIs. Anyway, I will think of the possible enhancement later on. Thanks, Xuelei > This would be the most optimal > solution. That might be a bit challenging given the API, but something > to keep in mind if you enhance the API later on. > > --Sean From neil.richards at ngmr.net Tue Nov 22 01:07:40 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 22 Nov 2011 09:07:40 +0000 Subject: hg: jdk8/tl/jdk: 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo Message-ID: <20111122090802.E28404741F@hg.openjdk.java.net> Changeset: 81987765cb81 Author: ngmr Date: 2011-11-11 14:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81987765cb81 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo Reviewed-by: chegar, alanb, mduigou, ngmr Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h From neil.richards at ngmr.net Tue Nov 22 03:02:44 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 22 Nov 2011 11:02:44 +0000 Subject: hg: jdk8/tl/jdk: 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN) Message-ID: <20111122110306.6DB7647421@hg.openjdk.java.net> Changeset: ee2fa62fb09f Author: ngmr Date: 2011-11-22 09:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee2fa62fb09f 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN) Reviewed-by: chegar Contributed-by: Neil Richards ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c From sean.mullan at oracle.com Tue Nov 22 07:00:27 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 22 Nov 2011 15:00:27 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20111122150129.76BD647427@hg.openjdk.java.net> Changeset: 1945abeb82a0 Author: mullan Date: 2011-11-22 08:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1945abeb82a0 7093090: Reduce synchronization in java.security.Policy.getPolicyNoCheck Reviewed-by: valeriep ! src/share/classes/java/security/Policy.java Changeset: bb8f19b80557 Author: mullan Date: 2011-11-22 09:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb8f19b80557 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: b4d7020c2a40 Author: mullan Date: 2011-11-22 09:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4d7020c2a40 Merge From sean.mullan at oracle.com Tue Nov 22 10:40:34 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Nov 2011 13:40:34 -0500 Subject: Code review request: 7113275, compatibility issue with MD2 trust anchor and old X509TrustManager In-Reply-To: <4ECB1D72.8000203@oracle.com> References: <4EC9C018.1010309@oracle.com> <4ECAC9C5.8050801@oracle.com> <4ECB1D72.8000203@oracle.com> Message-ID: <4ECBECA2.1040602@oracle.com> On 11/21/11 10:56 PM, Xuelei Fan wrote: > updated webrev: http://cr.openjdk.java.net/~xuelei/7113275/webrev.01/ >> I believe you could add an optimization that if the TrustManager is an >> instance of sun.security.ssl.X509TrustManagerImpl, then there is no need >> to perform the additional certpath constraint checks because the PKIX >> CertPathValidator will have already checked them. >> > The sun.security.ssl.X509TrustManagerImpl has already been an extension > of X509ExtendedTrustManager. If the TM is Oracle JDK's implementation, > including the implementation in deploy workspace, the implementation > should extend X509ExtendedTrustManager. And then the calling should not > fall into the AbstractTrustManagerWrapper. Ok, sounds good. >> I think the checkAlgorithmConstraints method can be marked static. >> > The method calls none-static method getAcceptedIssuers(), or in the new > webrev, it need to call the none-static class attribute. So I think it > cannot be static. Ok. >> Cycling through every root certificate each time to find a match in the >> chain could be costly. Another potential optimization is to copy the >> root certs into a Map, where the key is simply the Certificate. The >> value can be null. Then you can just check if the last certificate is in >> the Map. >> > Good point. Instead of a Map, I use a HashSet in the new webrev. I think > it should be the same on performance as your suggestion. Right. >> But even better would be to add a method to TrustManager (or something >> like that) that returned the trusted Certificate that was used to anchor >> the chain that was just validated. > The current TrustManager are defined to be none-state. As means that it > can work in multiple threads safely without synchronization. Above > suggestion may not comply to the requirement. We will face new > bottleneck if we need to support synchronized calling. > > However, it sounds like good if we update the existing method to return > the trusted certificate: > - public void checkClientTrusted() > + public X509Certificate checkClientTrusted() > > It may be challenging to update the return type of existing APIs. > Anyway, I will think of the possible enhancement later on. I think a better approach would be to add check{Client,Server}Trusted methods that return a result. For example, something like (I believe that changing the X509Certificate[] parameter allows us to overload the method with a different return type): public TrustManagerResult checkClientTrusted(CertPath chain, String authType, Socket socket) ... public interface TrustManagerResult { public TrustAnchor getTrustAnchor(); } public interface CertPathTrustManagerResult extends TrustManagerResult { public CertPathValidatorResult getCertPathValidatorResult(); } --Sean From xuelei.fan at oracle.com Wed Nov 23 03:42:22 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 23 Nov 2011 11:42:22 +0000 Subject: hg: jdk8/tl/jdk: 7113275: compatibility issue with MD2 trust anchor and old X509TrustManager Message-ID: <20111123114243.2BCA647437@hg.openjdk.java.net> Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82151e860a64 7113275: compatibility issue with MD2 trust anchor and old X509TrustManager Summary: also reviewed by Dennis.Gu at oracle.com Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java From chris.hegarty at oracle.com Wed Nov 23 04:31:24 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Nov 2011 12:31:24 +0000 Subject: hg: jdk8/tl/jdk: 6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed , fastdebug LINUX Message-ID: <20111123123142.4948947439@hg.openjdk.java.net> Changeset: 7eb0debca9b3 Author: chegar Date: 2011-11-23 12:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7eb0debca9b3 6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX Reviewed-by: chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/NullThreadName.java From xuelei.fan at oracle.com Wed Nov 23 04:50:27 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 23 Nov 2011 20:50:27 +0800 Subject: Code review request: 7113275, compatibility issue with MD2 trust anchor and old X509TrustManager In-Reply-To: <4ECBECA2.1040602@oracle.com> References: <4EC9C018.1010309@oracle.com> <4ECAC9C5.8050801@oracle.com> <4ECB1D72.8000203@oracle.com> <4ECBECA2.1040602@oracle.com> Message-ID: <4ECCEC13.7050506@oracle.com> Thanks for the review. > I think a better approach would be to add check{Client,Server}Trusted methods > that return a result. For example, something like (I believe that changing the > X509Certificate[] parameter allows us to overload the method with a different > return type): > > public TrustManagerResult checkClientTrusted(CertPath chain, String authType, > Socket socket) ... > > public interface TrustManagerResult { > public TrustAnchor getTrustAnchor(); > } > > public interface CertPathTrustManagerResult extends TrustManagerResult { > public CertPathValidatorResult getCertPathValidatorResult(); > } > It looks a little overwhelm to create a new series of methods. Applications will have to comply to the new methods, as might be not what we are expecting. But it's really useful when the server sends a partial certification path, and the trust manager will build a full certification path. So return a full certification path, or the trust anchor is useful for application, such as java plugin. TLS extensions spec (RFC 6066) defines OCSP status request extension and client certificate URLs extension. It may be a good time to consider the enhancement while implementing the above two extensions, as may need to update the existing trust manager methods. Thanks, Xuelei From sean.coffey at oracle.com Wed Nov 23 06:54:51 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 23 Nov 2011 14:54:51 +0000 Subject: hg: jdk8/tl/jdk: 7102369: remove java.rmi.server.codebase property parsing from registyimpl; ... Message-ID: <20111123145508.EFCEA4743A@hg.openjdk.java.net> Changeset: d27f0b2f1476 Author: coffeys Date: 2011-11-23 14:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d27f0b2f1476 7102369: remove java.rmi.server.codebase property parsing from registyimpl 7094468: rmiregistry clean up Reviewed-by: smarks ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java + test/java/rmi/registry/readTest/readTest.java + test/java/rmi/registry/readTest/readTest.sh + test/java/rmi/registry/readTest/testPkg/Client.java + test/java/rmi/registry/readTest/testPkg/Hello.java + test/java/rmi/registry/readTest/testPkg/Server.java From sebastian.sickelmann at gmx.de Tue Nov 22 20:45:59 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 23 Nov 2011 05:45:59 +0100 Subject: Answer requested!!! was: Re: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4EABE0D5.5050802@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> <4E88C03A.90904@gmx.de> <4EA96FB4.7000502@gmx.de> <4EABE0D5.5050802@gmx.de> Message-ID: <4ECC7A87.1030604@gmx.de> It's been a long time ago. Had someone had the time to think about this: Am 29.10.2011 13:17, schrieb Sebastian Sickelmann: > Sorry i linked the wrong webrev for Solution 3. > > Am 27.10.2011 16:50, schrieb Sebastian Sickelmann: >> Some time ago (see below) i ask what would be the right solution to >> refactor >> exception initialization to? >> >> Solution 1: Disallow calls to initCause after creation, if there was an >> exception-cause-functionality in this class before it was introduced >> to Throwable. >> Solution 2: Disallow calls to initCause after creation with in ctor >> which has a cause parameter. >> Solution 3: Disallow calls to initCause after creation, if and only >> if there are ctors >> that allows us to specify the cause at creation time. >> >> >> If i investigated it right:: >> * Solution 1 is used by in the Exceptions in core-libs. >> * Exceptions that had no cause-chain prior to >> Throwable's-cause-chain uses Solution 2. >> * Personally i found Solution 3 is the most intuitive for the users >> >> javax/xml/security- Exceptions had cause-chaining prio to Throwable >> introduces them. jx/x/s-Exceptions are actually not refactored to >> solution 2 like the other exceptions in core-libs that had >> cause-chaining prior to Throwable. >> >> Before my change-request for jx/x/s-Exceptions i changed some in >> core-libs (InternalError and VirtualMachineError) to provide >> exception-chaining. These use Solution 2 like all other exceptions >> that provided exception-chaining after it where introduced by Throwable. >> >> My personal view of this is that i think it may be valueable to >> change all to Solution 3 or at least merge all Solutions to one >> Solution(maybe Solution 2) and get rid of Solution 1. >> I created a webrev[0] for jx/x/s-Exceptions that implements Solution >> 2 (this can be used for all those Exceptions that used Solution 1 too). >> And I created a webrev[1] for jx/x/s-Exceptions that implement >> Solution 3 for comparision. >> >> [0] >> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html >> > [1] > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html From maurizio.cimadamore at oracle.com Thu Nov 24 05:40:20 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 24 Nov 2011 13:40:20 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111124134026.77EE747443@hg.openjdk.java.net> Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c896d95e7469 7115046: Add AST node for lambda expressions Summary: Add tree nodes for representing lambda expressions and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: ec59a2ce9114 Author: mcimadamore Date: 2011-11-24 13:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec59a2ce9114 7115049: Add AST node for method references Summary: Add tree nodes for representing method/constructor references and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java From chris.hegarty at oracle.com Fri Nov 25 04:15:42 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 25 Nov 2011 12:15:42 +0000 Subject: hg: jdk8/tl/jdk: 7115150: java.net.HttpCookie code cleanup, style, formatting, typos Message-ID: <20111125121559.479E247465@hg.openjdk.java.net> Changeset: 387190e1f782 Author: chegar Date: 2011-11-25 10:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/387190e1f782 7115150: java.net.HttpCookie code cleanup, style, formatting, typos Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java From chris.hegarty at oracle.com Fri Nov 25 08:28:45 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 25 Nov 2011 16:28:45 +0000 Subject: hg: jdk8/tl/jdk: 7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor Message-ID: <20111125162909.5898247468@hg.openjdk.java.net> Changeset: e5ecbf555679 Author: chegar Date: 2011-11-25 13:46 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5ecbf555679 7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor Reviewed-by: chegar, alanb Contributed-by: sajia at taobao.com ! src/share/classes/sun/nio/ch/SocketAdaptor.java From xuelei.fan at oracle.com Sat Nov 26 04:43:46 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Nov 2011 20:43:46 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Message-ID: <4ED0DF02.8010406@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ No new regression test, the current test, test/sun/security/tools/keytool/printssl.sh, has already been able to test the update. Thanks, Xuelei From weijun.wang at oracle.com Sat Nov 26 05:59:23 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 26 Nov 2011 21:59:23 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED0DF02.8010406@oracle.com> References: <4ED0DF02.8010406@oracle.com> Message-ID: Hi Xuelei Why move the local variables to static fields? The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. -Max On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ > > No new regression test, the current test, > test/sun/security/tools/keytool/printssl.sh, has already been able to > test the update. > > Thanks, > Xuelei From weijun.wang at oracle.com Sat Nov 26 06:38:35 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 26 Nov 2011 22:38:35 +0800 Subject: code review request: 7115744: Do not call File::deleteOnExit in security tests References: <31116075.1322317859105.JavaMail.sbladm@swsblss4-new> Message-ID: <8214817F-EC68-45F3-8A5B-3BB0B9EFB41B@oracle.com> Hi Xuelei Please take a review: http://cr.openjdk.java.net/~weijun/7115744/webrev.00/ Most are krb5 tests, one for SSL. Thanks Max Begin forwarded message: > *Change Request ID*: 7115744 > *Synopsis*: Do not call File::deleteOnExit in security tests > > > === *Description* ============================================================ > File::deleteOnExit (for a temp file in the working directory) is not a good idea; > > 1. It's useless in agentvm/savevm mode because the file won't be deleted when the test finishes. > > 2. It's not necessary because jtreg will clean up the working directory for you. > > 3. If the test fails, maybe you want to keep the file for diagnosis. jtreg can retain it for you. From xuelei.fan at oracle.com Sat Nov 26 06:42:55 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Nov 2011 22:42:55 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: References: <4ED0DF02.8010406@oracle.com> Message-ID: <4ED0FAEF.3090206@oracle.com> On 11/26/2011 9:59 PM, Weijun Wang wrote: > Hi Xuelei > > Why move the local variables to static fields? > In order to improve the performance. SSLContext.init() is expensive. > The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. > We have synchronized the engineGetCertificates(), and this method is the only method to access the GetChainTrustManager object. As the attribute is declared as "final static", so it will be initialized once even in multiple threads. That's, the access to serverChain variable has been synchronized by synchronizing the engineGetCertificates method. Xuelei > -Max > > On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: > >> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >> >> No new regression test, the current test, >> test/sun/security/tools/keytool/printssl.sh, has already been able to >> test the update. >> >> Thanks, >> Xuelei > From xuelei.fan at oracle.com Sat Nov 26 06:48:59 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Nov 2011 22:48:59 +0800 Subject: code review request: 7115744: Do not call File::deleteOnExit in security tests In-Reply-To: <8214817F-EC68-45F3-8A5B-3BB0B9EFB41B@oracle.com> References: <31116075.1322317859105.JavaMail.sbladm@swsblss4-new> <8214817F-EC68-45F3-8A5B-3BB0B9EFB41B@oracle.com> Message-ID: <4ED0FC5B.6070605@oracle.com> Looks fine to me. As you did not update the copyright years, I think you will only push the changes to JDK 8. It's OK to me in case you don't want putback to JDK 7. Otherwise, I would suggest you update the copyright years. Xuelei On 11/26/2011 10:38 PM, Weijun Wang wrote: > Hi Xuelei > > Please take a review: > > http://cr.openjdk.java.net/~weijun/7115744/webrev.00/ > > Most are krb5 tests, one for SSL. > > Thanks > Max > > > Begin forwarded message: > >> *Change Request ID*: 7115744 >> *Synopsis*: Do not call File::deleteOnExit in security tests >> >> >> === *Description* ============================================================ >> File::deleteOnExit (for a temp file in the working directory) is not a good idea; >> >> 1. It's useless in agentvm/savevm mode because the file won't be deleted when the test finishes. >> >> 2. It's not necessary because jtreg will clean up the working directory for you. >> >> 3. If the test fails, maybe you want to keep the file for diagnosis. jtreg can retain it for you. > From xuelei.fan at oracle.com Sat Nov 26 06:58:19 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Nov 2011 22:58:19 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED0FAEF.3090206@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> Message-ID: <4ED0FE8B.5030506@oracle.com> I was wondering why we synchronized the getInstance() and engineGetCertificates(). It seems that we only need to synchronize the serverChain variable. I will update the synchronization if no objection. Thanks, Xuelei On 11/26/2011 10:42 PM, Xuelei Fan wrote: > On 11/26/2011 9:59 PM, Weijun Wang wrote: >> Hi Xuelei >> >> Why move the local variables to static fields? >> > In order to improve the performance. SSLContext.init() is expensive. > >> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >> > We have synchronized the engineGetCertificates(), and this method is the > only method to access the GetChainTrustManager object. As the attribute > is declared as "final static", so it will be initialized once even in > multiple threads. > > That's, the access to serverChain variable has been synchronized by > synchronizing the engineGetCertificates method. > > Xuelei > >> -Max >> >> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >> >>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>> >>> No new regression test, the current test, >>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>> test the update. >>> >>> Thanks, >>> Xuelei >> > From weijun.wang at oracle.com Sat Nov 26 07:16:18 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 26 Nov 2011 23:16:18 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED0FE8B.5030506@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> Message-ID: On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: > I was wondering why we synchronized the getInstance() and > engineGetCertificates(). It seems that we only need to synchronize the > serverChain variable. > > I will update the synchronization if no objection. > > Thanks, > Xuelei > > On 11/26/2011 10:42 PM, Xuelei Fan wrote: >> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>> Hi Xuelei >>> >>> Why move the local variables to static fields? >>> >> In order to improve the performance. SSLContext.init() is expensive. >> >>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>> >> We have synchronized the engineGetCertificates(), and this method is the >> only method to access the GetChainTrustManager object. As the attribute >> is declared as "final static", so it will be initialized once even in >> multiple threads. But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. Max >> >> That's, the access to serverChain variable has been synchronized by >> synchronizing the engineGetCertificates method. >> >> Xuelei >> >>> -Max >>> >>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>> >>>> No new regression test, the current test, >>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>> test the update. >>>> >>>> Thanks, >>>> Xuelei >>> >> > From xuelei.fan at oracle.com Sat Nov 26 07:25:36 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Nov 2011 23:25:36 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> Message-ID: <4ED104F0.3090604@oracle.com> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ You're right on the synchronization issue. In the new webrev, I also remove the "synchronized" keyword on method. Instead, a synchronization on the static attribute is used. Thanks, Xuelei On 11/26/2011 11:16 PM, Weijun Wang wrote: > > On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: > >> I was wondering why we synchronized the getInstance() and >> engineGetCertificates(). It seems that we only need to synchronize the >> serverChain variable. >> >> I will update the synchronization if no objection. >> >> Thanks, >> Xuelei >> >> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>> Hi Xuelei >>>> >>>> Why move the local variables to static fields? >>>> >>> In order to improve the performance. SSLContext.init() is expensive. >>> >>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>> >>> We have synchronized the engineGetCertificates(), and this method is the >>> only method to access the GetChainTrustManager object. As the attribute >>> is declared as "final static", so it will be initialized once even in >>> multiple threads. > > But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. > > Max > >>> >>> That's, the access to serverChain variable has been synchronized by >>> synchronizing the engineGetCertificates method. >>> >>> Xuelei >>> >>>> -Max >>>> >>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>> >>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>> >>>>> No new regression test, the current test, >>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>> test the update. >>>>> >>>>> Thanks, >>>>> Xuelei >>>> >>> >> From weijun.wang at oracle.com Sat Nov 26 08:23:48 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 27 Nov 2011 00:23:48 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED104F0.3090604@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> Message-ID: <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> There is one thing I'm not sure about: In which case(s), the GeneralSecurityException will be thrown? Is it possible that the exception is thrown sometimes but not always? Also, the old code has the exception as a clause of the CertStoreException. Can you also include it? Max On Nov 26, 2011, at 11:25 PM, Xuelei Fan wrote: > new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ > > You're right on the synchronization issue. In the new webrev, I also > remove the "synchronized" keyword on method. Instead, a synchronization > on the static attribute is used. > > Thanks, > Xuelei > > On 11/26/2011 11:16 PM, Weijun Wang wrote: >> >> On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: >> >>> I was wondering why we synchronized the getInstance() and >>> engineGetCertificates(). It seems that we only need to synchronize the >>> serverChain variable. >>> >>> I will update the synchronization if no objection. >>> >>> Thanks, >>> Xuelei >>> >>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>> Hi Xuelei >>>>> >>>>> Why move the local variables to static fields? >>>>> >>>> In order to improve the performance. SSLContext.init() is expensive. >>>> >>>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>>> >>>> We have synchronized the engineGetCertificates(), and this method is the >>>> only method to access the GetChainTrustManager object. As the attribute >>>> is declared as "final static", so it will be initialized once even in >>>> multiple threads. >> >> But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. >> >> Max >> >>>> >>>> That's, the access to serverChain variable has been synchronized by >>>> synchronizing the engineGetCertificates method. >>>> >>>> Xuelei >>>> >>>>> -Max >>>>> >>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>> >>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>> >>>>>> No new regression test, the current test, >>>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>>> test the update. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>> >>>> >>> > From Xuelei.Fan at Oracle.Com Sat Nov 26 17:05:56 2011 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sun, 27 Nov 2011 09:05:56 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> Message-ID: <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> Sent from my iPad On Nov 27, 2011, at 12:23 AM, Weijun Wang wrote: > There is one thing I'm not sure about: > > In which case(s), the GeneralSecurityException will be thrown? SSLContext initialization. > Is it possible that the exception is thrown sometimes but not always? Also, the old code has the exception as a clause of the CertStoreException. Can you also include it? > It is reorged in line 100 and 101, the cause is described as unable to initialize the ssl context. Xuelei > Max > > > > On Nov 26, 2011, at 11:25 PM, Xuelei Fan wrote: > >> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ >> >> You're right on the synchronization issue. In the new webrev, I also >> remove the "synchronized" keyword on method. Instead, a synchronization >> on the static attribute is used. >> >> Thanks, >> Xuelei >> >> On 11/26/2011 11:16 PM, Weijun Wang wrote: >>> >>> On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: >>> >>>> I was wondering why we synchronized the getInstance() and >>>> engineGetCertificates(). It seems that we only need to synchronize the >>>> serverChain variable. >>>> >>>> I will update the synchronization if no objection. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>>> Hi Xuelei >>>>>> >>>>>> Why move the local variables to static fields? >>>>>> >>>>> In order to improve the performance. SSLContext.init() is expensive. >>>>> >>>>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>>>> >>>>> We have synchronized the engineGetCertificates(), and this method is the >>>>> only method to access the GetChainTrustManager object. As the attribute >>>>> is declared as "final static", so it will be initialized once even in >>>>> multiple threads. >>> >>> But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. >>> >>> Max >>> >>>>> >>>>> That's, the access to serverChain variable has been synchronized by >>>>> synchronizing the engineGetCertificates method. >>>>> >>>>> Xuelei >>>>> >>>>>> -Max >>>>>> >>>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>>> >>>>>>> No new regression test, the current test, >>>>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>>>> test the update. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>> >>>>> >>>> >> From weijun.wang at oracle.com Sat Nov 26 17:49:32 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 27 Nov 2011 09:49:32 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> Message-ID: <4ED1972C.5090809@oracle.com> >> Is it possible that the exception is thrown sometimes but not always? If it always fails, there is no problem failing once at the beginning. Otherwise, if there is a chance it goes fine again after calling some codes, maybe it's better to try call it each time? Max On 11/27/2011 09:05 AM, Xuelei Fan wrote: > > > Sent from my iPad > > On Nov 27, 2011, at 12:23 AM, Weijun Wang wrote: > >> There is one thing I'm not sure about: >> >> In which case(s), the GeneralSecurityException will be thrown? > SSLContext initialization. > >> Is it possible that the exception is thrown sometimes but not always? Also, the old code has the exception as a clause of the CertStoreException. Can you also include it? >> > It is reorged in line 100 and 101, the cause is described as unable to initialize the ssl context. > > Xuelei > >> Max >> >> >> >> On Nov 26, 2011, at 11:25 PM, Xuelei Fan wrote: >> >>> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ >>> >>> You're right on the synchronization issue. In the new webrev, I also >>> remove the "synchronized" keyword on method. Instead, a synchronization >>> on the static attribute is used. >>> >>> Thanks, >>> Xuelei >>> >>> On 11/26/2011 11:16 PM, Weijun Wang wrote: >>>> >>>> On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: >>>> >>>>> I was wondering why we synchronized the getInstance() and >>>>> engineGetCertificates(). It seems that we only need to synchronize the >>>>> serverChain variable. >>>>> >>>>> I will update the synchronization if no objection. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>>>> Hi Xuelei >>>>>>> >>>>>>> Why move the local variables to static fields? >>>>>>> >>>>>> In order to improve the performance. SSLContext.init() is expensive. >>>>>> >>>>>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>>>>> >>>>>> We have synchronized the engineGetCertificates(), and this method is the >>>>>> only method to access the GetChainTrustManager object. As the attribute >>>>>> is declared as "final static", so it will be initialized once even in >>>>>> multiple threads. >>>> >>>> But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. >>>> >>>> Max >>>> >>>>>> >>>>>> That's, the access to serverChain variable has been synchronized by >>>>>> synchronizing the engineGetCertificates method. >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> -Max >>>>>>> >>>>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>>>> >>>>>>>> No new regression test, the current test, >>>>>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>>>>> test the update. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>> >>>>>> >>>>> >>> From Xuelei.Fan at Oracle.Com Sat Nov 26 18:15:48 2011 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sun, 27 Nov 2011 10:15:48 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED1972C.5090809@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> Message-ID: <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> Sent from my iPad On Nov 27, 2011, at 9:49 AM, Weijun Wang wrote: > >> Is it possible that the exception is thrown sometimes but not always? > > If it always fails, there is no problem failing once at the beginning. Otherwise, if there is a chance it goes fine again after calling some codes, maybe it's better to try call it each time? > I don't think it the case will happen, otherwise there must be a potential bug. Indeed, the exception is unlikely to happen once JSSE boot up. Xuelei > Max > > On 11/27/2011 09:05 AM, Xuelei Fan wrote: >> >> >> Sent from my iPad >> >> On Nov 27, 2011, at 12:23 AM, Weijun Wang wrote: >> >>> There is one thing I'm not sure about: >>> >>> In which case(s), the GeneralSecurityException will be thrown? >> SSLContext initializatio >> >>> Is it possible that the exception is thrown sometimes but not always? Also, the old code has the exception as a clause of the CertStoreException. Can you also include it? >>> >> It is reorged in line 100 and 101, the cause is described as unable to initialize the ssl context. >> >> Xuelei >> >>> Max >>> >>> >>> >>> On Nov 26, 2011, at 11:25 PM, Xuelei Fan wrote: >>> >>>> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ >>>> >>>> You're right on the synchronization issue. In the new webrev, I also >>>> remove the "synchronized" keyword on method. Instead, a synchronization >>>> on the static attribute is used. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/26/2011 11:16 PM, Weijun Wang wrote: >>>>> >>>>> On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: >>>>> >>>>>> I was wondering why we synchronized the getInstance() and >>>>>> engineGetCertificates(). It seems that we only need to synchronize the >>>>>> serverChain variable. >>>>>> >>>>>> I will update the synchronization if no objection. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>>>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>>>>> Hi Xuelei >>>>>>>> >>>>>>>> Why move the local variables to static fields? >>>>>>>> >>>>>>> In order to improve the performance. SSLContext.init() is expensive. >>>>>>> >>>>>>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>>>>>> >>>>>>> We have synchronized the engineGetCertificates(), and this method is the >>>>>>> only method to access the GetChainTrustManager object. As the attribute >>>>>>> is declared as "final static", so it will be initialized once even in >>>>>>> multiple threads. >>>>> >>>>> But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. >>>>> >>>>> Max >>>>> >>>>>>> >>>>>>> That's, the access to serverChain variable has been synchronized by >>>>>>> synchronizing the engineGetCertificates method. >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>>> -Max >>>>>>>> >>>>>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>>>>> >>>>>>>>> No new regression test, the current test, >>>>>>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>>>>>> test the update. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>> >>>>>>> >>>>>> >>>> From weijun.wang at oracle.com Sun Nov 27 01:01:20 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 27 Nov 2011 17:01:20 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> Message-ID: <4ED1FC60.5080203@oracle.com> Anyway, I find this a little unsafe. One can add a new SSL security provider at run time, and then run this method, and the new provider can be loaded. In my opinion, this is more important than performance. Thanks Max On 11/27/2011 10:15 AM, Xuelei Fan wrote: > > > Sent from my iPad > > On Nov 27, 2011, at 9:49 AM, Weijun Wang wrote: > >>>> Is it possible that the exception is thrown sometimes but not always? >> >> If it always fails, there is no problem failing once at the beginning. Otherwise, if there is a chance it goes fine again after calling some codes, maybe it's better to try call it each time? >> > I don't think it the case will happen, otherwise there must be a potential bug. Indeed, the exception is unlikely to happen once JSSE boot up. > > Xuelei > > >> Max >> >> On 11/27/2011 09:05 AM, Xuelei Fan wrote: >>> >>> >>> Sent from my iPad >>> >>> On Nov 27, 2011, at 12:23 AM, Weijun Wang wrote: >>> >>>> There is one thing I'm not sure about: >>>> >>>> In which case(s), the GeneralSecurityException will be thrown? >>> SSLContext initializatio >>> >>>> Is it possible that the exception is thrown sometimes but not always? Also, the old code has the exception as a clause of the CertStoreException. Can you also include it? >>>> >>> It is reorged in line 100 and 101, the cause is described as unable to initialize the ssl context. >>> >>> Xuelei >>> >>>> Max >>>> >>>> >>>> >>>> On Nov 26, 2011, at 11:25 PM, Xuelei Fan wrote: >>>> >>>>> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ >>>>> >>>>> You're right on the synchronization issue. In the new webrev, I also >>>>> remove the "synchronized" keyword on method. Instead, a synchronization >>>>> on the static attribute is used. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 11/26/2011 11:16 PM, Weijun Wang wrote: >>>>>> >>>>>> On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: >>>>>> >>>>>>> I was wondering why we synchronized the getInstance() and >>>>>>> engineGetCertificates(). It seems that we only need to synchronize the >>>>>>> serverChain variable. >>>>>>> >>>>>>> I will update the synchronization if no objection. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>>>>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>>>>>> Hi Xuelei >>>>>>>>> >>>>>>>>> Why move the local variables to static fields? >>>>>>>>> >>>>>>>> In order to improve the performance. SSLContext.init() is expensive. >>>>>>>> >>>>>>>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>>>>>>> >>>>>>>> We have synchronized the engineGetCertificates(), and this method is the >>>>>>>> only method to access the GetChainTrustManager object. As the attribute >>>>>>>> is declared as "final static", so it will be initialized once even in >>>>>>>> multiple threads. >>>>>> >>>>>> But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. >>>>>> >>>>>> Max >>>>>> >>>>>>>> >>>>>>>> That's, the access to serverChain variable has been synchronized by >>>>>>>> synchronizing the engineGetCertificates method. >>>>>>>> >>>>>>>> Xuelei >>>>>>>> >>>>>>>>> -Max >>>>>>>>> >>>>>>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>>>>>> >>>>>>>>>> No new regression test, the current test, >>>>>>>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>>>>>>> test the update. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>> >>>>>>>> >>>>>>> >>>>> From Xuelei.Fan at Oracle.Com Sun Nov 27 01:48:46 2011 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sun, 27 Nov 2011 17:48:46 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED1FC60.5080203@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> Message-ID: <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> Sent from my iPad On Nov 27, 2011, at 5:01 PM, Weijun Wang wrote: > Anyway, I find this a little unsafe. One can add a new SSL security provider at run time, and then run this method, and the new provider can be loaded. > I did not follow your ideas. The new provider is loaded, and what's the worries then? Xuelei > In my opinion, this is more important than performance. > > Thanks > Max > > > On 11/27/2011 10:15 AM, Xuelei Fan wrote: >> >> >> Sent from my iPad >> >> On Nov 27, 2011, at 9:49 AM, Weijun Wang wrote: >> >>>>> Is it possible that the exception is thrown sometimes but not always? >>> >>> If it always fails, there is no problem failing once at the beginning. Otherwise, if there is a chance it goes fine again after calling some codes, maybe it's better to try call it each time? >>> >> I don't think it the case will happen, otherwise there must be a potential bug. Indeed, the exception is unlikely to happen once JSSE boot up. >> >> Xuelei >> >> >>> Max >>> >>> On 11/27/2011 09:05 AM, Xuelei Fan wrote: >>>> >>>> >>>> Sent from my iPad >>>> >>>> On Nov 27, 2011, at 12:23 AM, Weijun Wang wrote: >>>> >>>>> There is one thing I'm not sure about: >>>>> >>>>> In which case(s), the GeneralSecurityException will be thrown? >>>> SSLContext initializatio >>>> >>>>> Is it possible that the exception is thrown sometimes but not always? Also, the old code has the exception as a clause of the CertStoreException. Can you also include it? >>>>> >>>> It is reorged in line 100 and 101, the cause is described as unable to initialize the ssl context. >>>> >>>> Xuelei >>>> >>>>> Max >>>>> >>>>> >>>>> >>>>> On Nov 26, 2011, at 11:25 PM, Xuelei Fan wrote: >>>>> >>>>>> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ >>>>>> >>>>>> You're right on the synchronization issue. In the new webrev, I also >>>>>> remove the "synchronized" keyword on method. Instead, a synchronization >>>>>> on the static attribute is used. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 11/26/2011 11:16 PM, Weijun Wang wrote: >>>>>>> >>>>>>> On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: >>>>>>> >>>>>>>> I was wondering why we synchronized the getInstance() and >>>>>>>> engineGetCertificates(). It seems that we only need to synchronize the >>>>>>>> serverChain variable. >>>>>>>> >>>>>>>> I will update the synchronization if no objection. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>>>>>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>>>>>>> Hi Xuelei >>>>>>>>>> >>>>>>>>>> Why move the local variables to static fields? >>>>>>>>>> >>>>>>>>> In order to improve the performance. SSLContext.init() is expensive. >>>>>>>>> >>>>>>>>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>>>>>>>> >>>>>>>>> We have synchronized the engineGetCertificates(), and this method is the >>>>>>>>> only method to access the GetChainTrustManager object. As the attribute >>>>>>>>> is declared as "final static", so it will be initialized once even in >>>>>>>>> multiple threads. >>>>>>> >>>>>>> But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. >>>>>>> >>>>>>> Max >>>>>>> >>>>>>>>> >>>>>>>>> That's, the access to serverChain variable has been synchronized by >>>>>>>>> synchronizing the engineGetCertificates method. >>>>>>>>> >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>>> -Max >>>>>>>>>> >>>>>>>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>>>>>>> >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> No new regression test, the current test, >>>>>>>>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>>>>>>>> test the update. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> From weijun.wang at oracle.com Sun Nov 27 03:07:33 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 27 Nov 2011 19:07:33 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> Message-ID: <4ED219F5.3020500@oracle.com> On 11/27/2011 05:48 PM, Xuelei Fan wrote: > > > Sent from my iPad > > On Nov 27, 2011, at 5:01 PM, Weijun Wang wrote: > >> Anyway, I find this a little unsafe. One can add a new SSL security provider at run time, and then run this method, and the new provider can be loaded. >> > I did not follow your ideas. The new provider is loaded, and what's the worries then? Typo, I meant "cannot". 1. Run this method, the default SSL provider loaded 2. Add a new SSL security provider 3. Run this method again, still the old provider. Max > > Xuelei > >> In my opinion, this is more important than performance. >> >> Thanks >> Max >> >> >> On 11/27/2011 10:15 AM, Xuelei Fan wrote: >>> >>> >>> Sent from my iPad >>> >>> On Nov 27, 2011, at 9:49 AM, Weijun Wang wrote: >>> >>>>>> Is it possible that the exception is thrown sometimes but not always? >>>> >>>> If it always fails, there is no problem failing once at the beginning. Otherwise, if there is a chance it goes fine again after calling some codes, maybe it's better to try call it each time? >>>> >>> I don't think it the case will happen, otherwise there must be a potential bug. Indeed, the exception is unlikely to happen once JSSE boot up. >>> >>> Xuelei >>> >>> >>>> Max >>>> >>>> On 11/27/2011 09:05 AM, Xuelei Fan wrote: >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>> On Nov 27, 2011, at 12:23 AM, Weijun Wang wrote: >>>>> >>>>>> There is one thing I'm not sure about: >>>>>> >>>>>> In which case(s), the GeneralSecurityException will be thrown? >>>>> SSLContext initializatio >>>>> >>>>>> Is it possible that the exception is thrown sometimes but not always? Also, the old code has the exception as a clause of the CertStoreException. Can you also include it? >>>>>> >>>>> It is reorged in line 100 and 101, the cause is described as unable to initialize the ssl context. >>>>> >>>>> Xuelei >>>>> >>>>>> Max >>>>>> >>>>>> >>>>>> >>>>>> On Nov 26, 2011, at 11:25 PM, Xuelei Fan wrote: >>>>>> >>>>>>> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ >>>>>>> >>>>>>> You're right on the synchronization issue. In the new webrev, I also >>>>>>> remove the "synchronized" keyword on method. Instead, a synchronization >>>>>>> on the static attribute is used. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 11/26/2011 11:16 PM, Weijun Wang wrote: >>>>>>>> >>>>>>>> On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote: >>>>>>>> >>>>>>>>> I was wondering why we synchronized the getInstance() and >>>>>>>>> engineGetCertificates(). It seems that we only need to synchronize the >>>>>>>>> serverChain variable. >>>>>>>>> >>>>>>>>> I will update the synchronization if no objection. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>>>>>>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>>>>>>>> Hi Xuelei >>>>>>>>>>> >>>>>>>>>>> Why move the local variables to static fields? >>>>>>>>>>> >>>>>>>>>> In order to improve the performance. SSLContext.init() is expensive. >>>>>>>>>> >>>>>>>>>>> The engineGetCertificates method is only synchronized on this but not the whole class, so there is a chance that the method is called by multiple threads at the same time. This means if you only use one static GetChainTrustManager field, its serverChain field can be modified by different threads. >>>>>>>>>>> >>>>>>>>>> We have synchronized the engineGetCertificates(), and this method is the >>>>>>>>>> only method to access the GetChainTrustManager object. As the attribute >>>>>>>>>> is declared as "final static", so it will be initialized once even in >>>>>>>>>> multiple threads. >>>>>>>> >>>>>>>> But this method is only synchronized on the instance, not the class. You can create two SSLServerCertStore objects can call this method at the same time. >>>>>>>> >>>>>>>> Max >>>>>>>> >>>>>>>>>> >>>>>>>>>> That's, the access to serverChain variable has been synchronized by >>>>>>>>>> synchronizing the engineGetCertificates method. >>>>>>>>>> >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>>> -Max >>>>>>>>>>> >>>>>>>>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>>>>>>>> >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> No new regression test, the current test, >>>>>>>>>>>> test/sun/security/tools/keytool/printssl.sh, has already been able to >>>>>>>>>>>> test the update. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Xuelei >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> From xuelei.fan at oracle.com Sun Nov 27 06:31:45 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 27 Nov 2011 22:31:45 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED219F5.3020500@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> <4ED219F5.3020500@oracle.com> Message-ID: <4ED249D1.1020809@oracle.com> On 11/27/2011 7:07 PM, Weijun Wang wrote: > > > On 11/27/2011 05:48 PM, Xuelei Fan wrote: >> >> >> Sent from my iPad >> >> On Nov 27, 2011, at 5:01 PM, Weijun Wang wrote: >> >>> Anyway, I find this a little unsafe. One can add a new SSL security >>> provider at run time, and then run this method, and the new provider >>> can be loaded. >>> >> I did not follow your ideas. The new provider is loaded, and what's >> the worries then? > > Typo, I meant "cannot". > > 1. Run this method, the default SSL provider loaded > 2. Add a new SSL security provider > 3. Run this method again, still the old provider. > Got it. But this class is very special in that the security provider may be useless. It is a little complicated. I will call you tomorrow to explain more. I think we still have space to improve the stability and performance based on the latest update. Thanks, Xuelei > Max > >> >> Xuelei >> >>> In my opinion, this is more important than performance. >>> >>> Thanks >>> Max >>> >>> >>> On 11/27/2011 10:15 AM, Xuelei Fan wrote: >>>> >>>> >>>> Sent from my iPad >>>> >>>> On Nov 27, 2011, at 9:49 AM, Weijun Wang >>>> wrote: >>>> >>>>>>> Is it possible that the exception is thrown sometimes but not >>>>>>> always? >>>>> >>>>> If it always fails, there is no problem failing once at the >>>>> beginning. Otherwise, if there is a chance it goes fine again after >>>>> calling some codes, maybe it's better to try call it each time? >>>>> >>>> I don't think it the case will happen, otherwise there must be a >>>> potential bug. Indeed, the exception is unlikely to happen once >>>> JSSE boot up. >>>> >>>> Xuelei >>>> >>>> >>>>> Max >>>>> >>>>> On 11/27/2011 09:05 AM, Xuelei Fan wrote: >>>>>> >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> On Nov 27, 2011, at 12:23 AM, Weijun >>>>>> Wang wrote: >>>>>> >>>>>>> There is one thing I'm not sure about: >>>>>>> >>>>>>> In which case(s), the GeneralSecurityException will be thrown? >>>>>> SSLContext initializatio >>>>>> >>>>>>> Is it possible that the exception is thrown sometimes but not >>>>>>> always? Also, the old code has the exception as a clause of the >>>>>>> CertStoreException. Can you also include it? >>>>>>> >>>>>> It is reorged in line 100 and 101, the cause is described as >>>>>> unable to initialize the ssl context. >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 26, 2011, at 11:25 PM, Xuelei >>>>>>> Fan wrote: >>>>>>> >>>>>>>> new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/ >>>>>>>> >>>>>>>> You're right on the synchronization issue. In the new webrev, I >>>>>>>> also >>>>>>>> remove the "synchronized" keyword on method. Instead, a >>>>>>>> synchronization >>>>>>>> on the static attribute is used. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 11/26/2011 11:16 PM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> On Nov 26, 2011, at 10:58 PM, Xuelei >>>>>>>>> Fan wrote: >>>>>>>>> >>>>>>>>>> I was wondering why we synchronized the getInstance() and >>>>>>>>>> engineGetCertificates(). It seems that we only need to >>>>>>>>>> synchronize the >>>>>>>>>> serverChain variable. >>>>>>>>>> >>>>>>>>>> I will update the synchronization if no objection. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> On 11/26/2011 10:42 PM, Xuelei Fan wrote: >>>>>>>>>>> On 11/26/2011 9:59 PM, Weijun Wang wrote: >>>>>>>>>>>> Hi Xuelei >>>>>>>>>>>> >>>>>>>>>>>> Why move the local variables to static fields? >>>>>>>>>>>> >>>>>>>>>>> In order to improve the performance. SSLContext.init() is >>>>>>>>>>> expensive. >>>>>>>>>>> >>>>>>>>>>>> The engineGetCertificates method is only synchronized on >>>>>>>>>>>> this but not the whole class, so there is a chance that the >>>>>>>>>>>> method is called by multiple threads at the same time. This >>>>>>>>>>>> means if you only use one static GetChainTrustManager field, >>>>>>>>>>>> its serverChain field can be modified by different threads. >>>>>>>>>>>> >>>>>>>>>>> We have synchronized the engineGetCertificates(), and this >>>>>>>>>>> method is the >>>>>>>>>>> only method to access the GetChainTrustManager object. As the >>>>>>>>>>> attribute >>>>>>>>>>> is declared as "final static", so it will be initialized once >>>>>>>>>>> even in >>>>>>>>>>> multiple threads. >>>>>>>>> >>>>>>>>> But this method is only synchronized on the instance, not the >>>>>>>>> class. You can create two SSLServerCertStore objects can call >>>>>>>>> this method at the same time. >>>>>>>>> >>>>>>>>> Max >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That's, the access to serverChain variable has been >>>>>>>>>>> synchronized by >>>>>>>>>>> synchronizing the engineGetCertificates method. >>>>>>>>>>> >>>>>>>>>>> Xuelei >>>>>>>>>>> >>>>>>>>>>>> -Max >>>>>>>>>>>> >>>>>>>>>>>> On Nov 26, 2011, at 8:43 PM, Xuelei Fan wrote: >>>>>>>>>>>> >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> No new regression test, the current test, >>>>>>>>>>>>> test/sun/security/tools/keytool/printssl.sh, has already >>>>>>>>>>>>> been able to >>>>>>>>>>>>> test the update. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Xuelei >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> From xuelei.fan at oracle.com Sun Nov 27 19:27:09 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 28 Nov 2011 11:27:09 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED249D1.1020809@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> <4ED219F5.3020500@oracle.com> <4ED249D1.1020809@oracle.com> Message-ID: <4ED2FF8D.5070003@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/ I think the class is special in that in the class the client is not really want to establish a HTTPS/TLS connection with the server. The purpose of the class is to get the server certificate. It does not matter whether the TLS connection is negotiated or not. So the class only need a parser that can read the server certificate during the TLS handshaking. The "security" functions (for example, encryption decryption digest, etc.) do not make sense. In such situation, we really don't mind what's the underlying providers. Does it make sense? I make a update, so that even the TLS handshaking failed or other IO exceptions, once we are able to get the server certificate, we will use it. Thanks, Xuelei On 11/27/2011 10:31 PM, Xuelei Fan wrote: > On 11/27/2011 7:07 PM, Weijun Wang wrote: >> >> >> On 11/27/2011 05:48 PM, Xuelei Fan wrote: >>> >>> >>> Sent from my iPad >>> >>> On Nov 27, 2011, at 5:01 PM, Weijun Wang wrote: >>> >>>> Anyway, I find this a little unsafe. One can add a new SSL security >>>> provider at run time, and then run this method, and the new provider >>>> can be loaded. >>>> >>> I did not follow your ideas. The new provider is loaded, and what's >>> the worries then? >> >> Typo, I meant "cannot". >> >> 1. Run this method, the default SSL provider loaded >> 2. Add a new SSL security provider >> 3. Run this method again, still the old provider. >> > Got it. But this class is very special in that the security provider may > be useless. > > It is a little complicated. I will call you tomorrow to explain more. I > think we still have space to improve the stability and performance based > on the latest update. > > Thanks, > Xuelei From weijun.wang at oracle.com Sun Nov 27 20:34:32 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 28 Nov 2011 12:34:32 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED2FF8D.5070003@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> <4ED219F5.3020500@oracle.com> <4ED249D1.1020809@oracle.com> <4ED2FF8D.5070003@oracle.com> Message-ID: <4ED30F58.40203@oracle.com> On 11/28/2011 11:27 AM, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/ > > I think the class is special in that in the class the client is not > really want to establish a HTTPS/TLS connection with the server. The > purpose of the class is to get the server certificate. It does not > matter whether the TLS connection is negotiated or not. So the class > only need a parser that can read the server certificate during the TLS > handshaking. The "security" functions (for example, encryption > decryption digest, etc.) do not make sense. In such situation, we really > don't mind what's the underlying providers. > > Does it make sense? Yes. But I really don't think you need to change this behavior. If this class is not used by anyone else except KeyTool, there is no difference between a static field and a local variable. I really don't like static fields. > > I make a update, so that even the TLS handshaking failed or other IO > exceptions, once we are able to get the server certificate, we will use it. This is good, and you can add a comment on this. Thanks Max > > Thanks, > Xuelei > > > On 11/27/2011 10:31 PM, Xuelei Fan wrote: >> On 11/27/2011 7:07 PM, Weijun Wang wrote: >>> >>> >>> On 11/27/2011 05:48 PM, Xuelei Fan wrote: >>>> >>>> >>>> Sent from my iPad >>>> >>>> On Nov 27, 2011, at 5:01 PM, Weijun Wang wrote: >>>> >>>>> Anyway, I find this a little unsafe. One can add a new SSL security >>>>> provider at run time, and then run this method, and the new provider >>>>> can be loaded. >>>>> >>>> I did not follow your ideas. The new provider is loaded, and what's >>>> the worries then? >>> >>> Typo, I meant "cannot". >>> >>> 1. Run this method, the default SSL provider loaded >>> 2. Add a new SSL security provider >>> 3. Run this method again, still the old provider. >>> >> Got it. But this class is very special in that the security provider may >> be useless. >> >> It is a little complicated. I will call you tomorrow to explain more. I >> think we still have space to improve the stability and performance based >> on the latest update. >> >> Thanks, >> Xuelei From xuelei.fan at oracle.com Sun Nov 27 20:48:01 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 28 Nov 2011 12:48:01 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED30F58.40203@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> <4ED219F5.3020500@oracle.com> <4ED249D1.1020809@oracle.com> <4ED2FF8D.5070003@oracle.com> <4ED30F58.40203@oracle.com> Message-ID: <4ED31281.3070807@oracle.com> On 11/28/2011 12:34 PM, Weijun Wang wrote: > > On 11/28/2011 11:27 AM, Xuelei Fan wrote: >> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/ >> >> I think the class is special in that in the class the client is not >> really want to establish a HTTPS/TLS connection with the server. The >> purpose of the class is to get the server certificate. It does not >> matter whether the TLS connection is negotiated or not. So the class >> only need a parser that can read the server certificate during the TLS >> handshaking. The "security" functions (for example, encryption >> decryption digest, etc.) do not make sense. In such situation, we really >> don't mind what's the underlying providers. >> >> Does it make sense? > > Yes. > > But I really don't think you need to change this behavior. If this class > is not used by anyone else except KeyTool, there is no difference > between a static field and a local variable. I really don't like static > fields. > I think it is only used by KeyTool at present. But I really hate to see multiple SSLContext instances and TM/TM instances in an application, it is designed to be immutable. I have no special preference about static fields and local variables. If the local variable is always the same across the class life cycle, I prefer static field; otherwise, I prefer local variable. >> >> I make a update, so that even the TLS handshaking failed or other IO >> exceptions, once we are able to get the server certificate, we will >> use it. > > This is good, and you can add a comment on this. > There is a two-line comment in the update. Thanks, Xuelei > Thanks > Max > >> >> Thanks, >> Xuelei >> >> >> On 11/27/2011 10:31 PM, Xuelei Fan wrote: >>> On 11/27/2011 7:07 PM, Weijun Wang wrote: >>>> >>>> >>>> On 11/27/2011 05:48 PM, Xuelei Fan wrote: >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>> On Nov 27, 2011, at 5:01 PM, Weijun Wang >>>>> wrote: >>>>> >>>>>> Anyway, I find this a little unsafe. One can add a new SSL security >>>>>> provider at run time, and then run this method, and the new provider >>>>>> can be loaded. >>>>>> >>>>> I did not follow your ideas. The new provider is loaded, and what's >>>>> the worries then? >>>> >>>> Typo, I meant "cannot". >>>> >>>> 1. Run this method, the default SSL provider loaded >>>> 2. Add a new SSL security provider >>>> 3. Run this method again, still the old provider. >>>> >>> Got it. But this class is very special in that the security provider may >>> be useless. >>> >>> It is a little complicated. I will call you tomorrow to explain more. I >>> think we still have space to improve the stability and performance based >>> on the latest update. >>> >>> Thanks, >>> Xuelei From weijun.wang at oracle.com Sun Nov 27 21:52:27 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 28 Nov 2011 13:52:27 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED31281.3070807@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> <4ED219F5.3020500@oracle.com> <4ED249D1.1020809@oracle.com> <4ED2FF8D.5070003@oracle.com> <4ED30F58.40203@oracle.com> <4ED31281.3070807@oracle.com> Message-ID: <4ED3219B.4060702@oracle.com> OK. Let's stop arguing. The code is fine. Something else: you said the original SSLServerCertStore class "is a little bit out of date". Do you think it's possible that someone else might code in the same way? In other words, is it only "out of date" or the implementation was wrong even in a JDK 1.4.2 view? Thanks Max On 11/28/2011 12:48 PM, Xuelei Fan wrote: > On 11/28/2011 12:34 PM, Weijun Wang wrote: >> >> On 11/28/2011 11:27 AM, Xuelei Fan wrote: >>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/ >>> >>> I think the class is special in that in the class the client is not >>> really want to establish a HTTPS/TLS connection with the server. The >>> purpose of the class is to get the server certificate. It does not >>> matter whether the TLS connection is negotiated or not. So the class >>> only need a parser that can read the server certificate during the TLS >>> handshaking. The "security" functions (for example, encryption >>> decryption digest, etc.) do not make sense. In such situation, we really >>> don't mind what's the underlying providers. >>> >>> Does it make sense? >> >> Yes. >> >> But I really don't think you need to change this behavior. If this class >> is not used by anyone else except KeyTool, there is no difference >> between a static field and a local variable. I really don't like static >> fields. >> > I think it is only used by KeyTool at present. But I really hate to see > multiple SSLContext instances and TM/TM instances in an application, it > is designed to be immutable. > > I have no special preference about static fields and local variables. If > the local variable is always the same across the class life cycle, I > prefer static field; otherwise, I prefer local variable. > >>> >>> I make a update, so that even the TLS handshaking failed or other IO >>> exceptions, once we are able to get the server certificate, we will >>> use it. >> >> This is good, and you can add a comment on this. >> > There is a two-line comment in the update. > > Thanks, > Xuelei > >> Thanks >> Max >> >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 11/27/2011 10:31 PM, Xuelei Fan wrote: >>>> On 11/27/2011 7:07 PM, Weijun Wang wrote: >>>>> >>>>> >>>>> On 11/27/2011 05:48 PM, Xuelei Fan wrote: >>>>>> >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> On Nov 27, 2011, at 5:01 PM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>>> Anyway, I find this a little unsafe. One can add a new SSL security >>>>>>> provider at run time, and then run this method, and the new provider >>>>>>> can be loaded. >>>>>>> >>>>>> I did not follow your ideas. The new provider is loaded, and what's >>>>>> the worries then? >>>>> >>>>> Typo, I meant "cannot". >>>>> >>>>> 1. Run this method, the default SSL provider loaded >>>>> 2. Add a new SSL security provider >>>>> 3. Run this method again, still the old provider. >>>>> >>>> Got it. But this class is very special in that the security provider may >>>> be useless. >>>> >>>> It is a little complicated. I will call you tomorrow to explain more. I >>>> think we still have space to improve the stability and performance based >>>> on the latest update. >>>> >>>> Thanks, >>>> Xuelei > From Xuelei.Fan at Oracle.Com Sun Nov 27 22:16:11 2011 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 28 Nov 2011 14:16:11 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: <4ED3219B.4060702@oracle.com> References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> <4ED219F5.3020500@oracle.com> <4ED249D1.1020809@oracle.com> <4ED2FF8D.5070003@oracle.com> <4ED30F58.40203@oracle.com> <4ED31281.3070807@oracle.com> <4ED3219B.4060702@oracle.com> Message-ID: Sent from my iPad On Nov 28, 2011, at 1:52 PM, Weijun Wang wrote: > OK. Let's stop arguing. The code is fine. > > Something else: you said the original SSLServerCertStore class "is a little bit out of date". Do you think it's possible that someone else might code in the same way? In other words, is it only "out of date" or the implementation was wrong even in a JDK 1.4.2 view? > In JDK 7 and later, all oracle providers need to implement x509extendedTrustManager rather than X509TM when a TM is needed. This class did not extends X509ExtendedTM, that's why I think it is out of date. To fix the bug, it's enough if I only extend the X509ExtendedTM. And I try to find make more improve except the TM extensions. The implement of getAcceptedIssuers() is wrong. But as the old code does not call the method, so the issue is not exposed in JDK 6 and previous releases. If someone else code in the same way, of course it is possible, but it's not comply to the spec. We cannot ensure the implement will work when it does not comply to the spec. I think the SSLServerCertStore is new in JDK 7. Did we really have the code since 1.4.2? Xuelei > Thanks > Max > > > On 11/28/2011 12:48 PM, Xuelei Fan wrote: >> On 11/28/2011 12:34 PM, Weijun Wang wrote: >>> >>> On 11/28/2011 11:27 AM, Xuelei Fan wrote: >>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/ >>>> >>>> I think the class is special in that in the class the client is not >>>> really want to establish a HTTPS/TLS connection with the server. The >>>> purpose of the class is to get the server certificate. It does not >>>> matter whether the TLS connection is negotiated or not. So the class >>>> only need a parser that can read the server certificate during the TLS >>>> handshaking. The "security" functions (for example, encryption >>>> decryption digest, etc.) do not make sense. In such situation, we really >>>> don't mind what's the underlying providers. >>>> >>>> Does it make sense? >>> >>> Yes. >>> >>> But I really don't think you need to change this behavior. If this class >>> is not used by anyone else except KeyTool, there is no difference >>> between a static field and a local variable. I really don't like static >>> fields. >>> >> I think it is only used by KeyTool at present. But I really hate to see >> multiple SSLContext instances and TM/TM instances in an application, it >> is designed to be immutable. >> >> I have no special preference about static fields and local variables. If >> the local variable is always the same across the class life cycle, I >> prefer static field; otherwise, I prefer local variable. >> >>>> >>>> I make a update, so that even the TLS handshaking failed or other IO >>>> exceptions, once we are able to get the server certificate, we will >>>> use it. >>> >>> This is good, and you can add a comment on this. >>> >> There is a two-line comment in the update. >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 11/27/2011 10:31 PM, Xuelei Fan wrote: >>>>> On 11/27/2011 7:07 PM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> On 11/27/2011 05:48 PM, Xuelei Fan wrote: >>>>>>> >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On Nov 27, 2011, at 5:01 PM, Weijun Wang >>>>>>> wrote: >>>>>>> >>>>>>>> Anyway, I find this a little unsafe. One can add a new SSL security >>>>>>>> provider at run time, and then run this method, and the new provider >>>>>>>> can be loaded. >>>>>>>> >>>>>>> I did not follow your ideas. The new provider is loaded, and what's >>>>>>> the worries then? >>>>>> >>>>>> Typo, I meant "cannot". >>>>>> >>>>>> 1. Run this method, the default SSL provider loaded >>>>>> 2. Add a new SSL security provider >>>>>> 3. Run this method again, still the old provider. >>>>>> >>>>> Got it. But this class is very special in that the security provider may >>>>> be useless. >>>>> >>>>> It is a little complicated. I will call you tomorrow to explain more. I >>>>> think we still have space to improve the stability and performance based >>>>> on the latest update. >>>>> >>>>> Thanks, >>>>> Xuelei >> From weijun.wang at oracle.com Sun Nov 27 22:34:45 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 28 Nov 2011 14:34:45 +0800 Subject: Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works In-Reply-To: References: <4ED0DF02.8010406@oracle.com> <4ED0FAEF.3090206@oracle.com> <4ED0FE8B.5030506@oracle.com> <4ED104F0.3090604@oracle.com> <6586A8F2-FB8D-4800-A5E4-1A63503DD922@oracle.com> <03C98F30-244A-4656-9B47-4676AA83E81B@Oracle.Com> <4ED1972C.5090809@oracle.com> <825B9B5E-2E60-45EB-AFD0-05222717AB32@Oracle.Com> <4ED1FC60.5080203@oracle.com> <3FBDE9F7-B16F-4E46-9A28-641EF808E319@Oracle.Com> <4ED219F5.3020500@oracle.com> <4ED249D1.1020809@oracle.com> <4ED2FF8D.5070003@oracle.com> <4ED30F58.40203@oracle.com> <4ED31281.3070807@oracle.com> <4ED3219B.4060702@oracle.com> Message-ID: <4ED32B85.4030701@oracle.com> On 11/28/2011 02:16 PM, Xuelei Fan wrote: > > > Sent from my iPad > > On Nov 28, 2011, at 1:52 PM, Weijun Wang wrote: > >> OK. Let's stop arguing. The code is fine. >> >> Something else: you said the original SSLServerCertStore class "is a little bit out of date". Do you think it's possible that someone else might code in the same way? In other words, is it only "out of date" or the implementation was wrong even in a JDK 1.4.2 view? >> > In JDK 7 and later, all oracle providers need to implement x509extendedTrustManager rather than X509TM when a TM is needed. This class did not extends X509ExtendedTM, that's why I think it is out of date. To fix the bug, it's enough if I only extend the X509ExtendedTM. > > And I try to find make more improve except the TM extensions. The implement of getAcceptedIssuers() is wrong. But as the old code does not call the method, so the issue is not exposed in JDK 6 and previous releases. > > If someone else code in the same way, of course it is possible, but it's not comply to the spec. We cannot ensure the implement will work when it does not comply to the spec. > > I think the SSLServerCertStore is new in JDK 7. Did we really have the code since 1.4.2? Of course not. I just think maybe someone else had written similar code before JDK 7 and didn't realize they need to update it. -Max > > Xuelei > >> Thanks >> Max >> >> >> On 11/28/2011 12:48 PM, Xuelei Fan wrote: >>> On 11/28/2011 12:34 PM, Weijun Wang wrote: >>>> >>>> On 11/28/2011 11:27 AM, Xuelei Fan wrote: >>>>> webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/ >>>>> >>>>> I think the class is special in that in the class the client is not >>>>> really want to establish a HTTPS/TLS connection with the server. The >>>>> purpose of the class is to get the server certificate. It does not >>>>> matter whether the TLS connection is negotiated or not. So the class >>>>> only need a parser that can read the server certificate during the TLS >>>>> handshaking. The "security" functions (for example, encryption >>>>> decryption digest, etc.) do not make sense. In such situation, we really >>>>> don't mind what's the underlying providers. >>>>> >>>>> Does it make sense? >>>> >>>> Yes. >>>> >>>> But I really don't think you need to change this behavior. If this class >>>> is not used by anyone else except KeyTool, there is no difference >>>> between a static field and a local variable. I really don't like static >>>> fields. >>>> >>> I think it is only used by KeyTool at present. But I really hate to see >>> multiple SSLContext instances and TM/TM instances in an application, it >>> is designed to be immutable. >>> >>> I have no special preference about static fields and local variables. If >>> the local variable is always the same across the class life cycle, I >>> prefer static field; otherwise, I prefer local variable. >>> >>>>> >>>>> I make a update, so that even the TLS handshaking failed or other IO >>>>> exceptions, once we are able to get the server certificate, we will >>>>> use it. >>>> >>>> This is good, and you can add a comment on this. >>>> >>> There is a two-line comment in the update. >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>> On 11/27/2011 10:31 PM, Xuelei Fan wrote: >>>>>> On 11/27/2011 7:07 PM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> On 11/27/2011 05:48 PM, Xuelei Fan wrote: >>>>>>>> >>>>>>>> >>>>>>>> Sent from my iPad >>>>>>>> >>>>>>>> On Nov 27, 2011, at 5:01 PM, Weijun Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Anyway, I find this a little unsafe. One can add a new SSL security >>>>>>>>> provider at run time, and then run this method, and the new provider >>>>>>>>> can be loaded. >>>>>>>>> >>>>>>>> I did not follow your ideas. The new provider is loaded, and what's >>>>>>>> the worries then? >>>>>>> >>>>>>> Typo, I meant "cannot". >>>>>>> >>>>>>> 1. Run this method, the default SSL provider loaded >>>>>>> 2. Add a new SSL security provider >>>>>>> 3. Run this method again, still the old provider. >>>>>>> >>>>>> Got it. But this class is very special in that the security provider may >>>>>> be useless. >>>>>> >>>>>> It is a little complicated. I will call you tomorrow to explain more. I >>>>>> think we still have space to improve the stability and performance based >>>>>> on the latest update. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>> From weijun.wang at oracle.com Mon Nov 28 02:17:55 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 28 Nov 2011 10:17:55 +0000 Subject: hg: jdk8/tl/jdk: 7115744: Do not call File::deleteOnExit in security tests Message-ID: <20111128101848.4C3E547472@hg.openjdk.java.net> Changeset: 022540b11147 Author: weijun Date: 2011-11-28 18:16 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/022540b11147 7115744: Do not call File::deleteOnExit in security tests Reviewed-by: xuelei ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegateXRealm.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java From xuelei.fan at oracle.com Mon Nov 28 02:36:23 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 28 Nov 2011 10:36:23 +0000 Subject: hg: jdk8/tl/jdk: 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Message-ID: <20111128103649.4785447474@hg.openjdk.java.net> Changeset: d1928ae4e0a2 Author: xuelei Date: 2011-11-28 02:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1928ae4e0a2 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java From neil.richards at ngmr.net Mon Nov 28 03:02:08 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Mon, 28 Nov 2011 11:02:08 +0000 Subject: hg: jdk8/tl/jdk: 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Message-ID: <20111128110219.E7A3847475@hg.openjdk.java.net> Changeset: 955aae8c1106 Author: ngmr Date: 2011-11-24 11:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/955aae8c1106 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From neil.richards at ngmr.net Mon Nov 28 03:35:41 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Mon, 28 Nov 2011 11:35:41 +0000 Subject: hg: jdk8/tl/jdk: 7094995: Trailing daemon thread causes continuous GC in agentvm mode Message-ID: <20111128113600.0806D47476@hg.openjdk.java.net> Changeset: 6fbd69f8e3ab Author: ngmr Date: 2011-11-18 09:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6fbd69f8e3ab 7094995: Trailing daemon thread causes continuous GC in agentvm mode Summary: Shutdown GcInducingThread once test (successfully) finishes Reviewed-by: alanb, chegar, dholmes, darcy Contributed-by: Neil Richards ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java From maurizio.cimadamore at oracle.com Mon Nov 28 08:28:28 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 28 Nov 2011 16:28:28 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111128162835.25DAC4747A@hg.openjdk.java.net> Changeset: 9448fe783fd2 Author: mcimadamore Date: 2011-11-28 15:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9448fe783fd2 7115050: Add parser support for lambda expressions Summary: Add support for parsing lambda expressions to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/LambdaNotSupported.java + test/tools/javac/diags/examples/NotAStatement.java ! test/tools/javac/generics/rare/6665356/T6665356.out + test/tools/javac/lambda/LambdaParserTest.java Changeset: 3343b22e2761 Author: mcimadamore Date: 2011-11-28 16:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3343b22e2761 7115052: Add parser support for method references Summary: Add support for parsing method references to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/MethodReferencesNotSupported.java + test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out From mstjohns at comcast.net Mon Nov 28 10:30:45 2011 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 28 Nov 2011 13:30:45 -0500 Subject: Algorithm Names - registry? Message-ID: <20111128183050.8DAA76BF3@mail.openjdk.java.net> One of the items that seems terribly out of date is the "Standard Names" list. Also, sometimes its difficult to tell which algorithm - specifically - the name applies to. I'm wondering if it isn't time to create something like a Wiki for name registration and - for example - let the folks building the various JCE providers add or propose names. I mention this because I'm finding it tiresome looking through the BouncyCastle source code each time I need to find an algorithm name not on the list. I would suggest as data elements: Primary name, Optional secondary names; Object Identifier (if any); Applicable JCE class (e.g. Cipher, MessageDigest, etc), Primary standard (e.g. RFCXXXX, ISOXXXX - section yy, option zzz); Alternate standards (for example ECDSA is referenced in SECG, NIST, ANSI etc); clarifying comments (e.g. "Use IvAlgorithmParameter with this"). Continuing this thought - the Javacard algorithm identifiers could also be included in this table. Mike From david.holmes at oracle.com Mon Nov 28 21:27:43 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 29 Nov 2011 05:27:43 +0000 Subject: hg: jdk8/tl/jdk: 7109092: Wrong computation results with double at armsflt Message-ID: <20111129052802.D0F0647488@hg.openjdk.java.net> Changeset: cf47846165f4 Author: dholmes Date: 2011-11-29 00:26 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf47846165f4 7109092: Wrong computation results with double at armsflt Summary: need to link to custom soft-float library with required FP accuracy Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk From sebastian.sickelmann at gmx.de Tue Nov 29 06:33:52 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 29 Nov 2011 15:33:52 +0100 Subject: Last Change for comment on 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException Message-ID: <4ED4ED50.4050102@gmx.de> Hi, I started some cleanup work a while ago and we got into short discussions while cleaning-up javax.xml.crypto. Unfortunately i got no relay for a long time. Tried to get some comments on 2011-10-27 [1] and 2011-11-23 [2] but nobody reacted. Maybe i have done something wrong, maybe i have bothered some of you with my requests for comments, maybe i lost some email that was send to me(which i tripple checked), but if the cleanup exception-chains is not worth any discussion, then say it and i stop and work on other things. Don't get me wrong, i want to contribute and the cleanup was a nice starting job but I don't have to do this cleanup work. I suggested it and i want to "stay to my words", and i don't like open issues in my inbox. So let me know if someone is interested in the cleanups and willing to discuss some bigger changes or i will delete this task from my inbox. -- Sebastian [core-libs-dev] [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/008023.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008355.html [security-dev] [1] http://mail.openjdk.java.net/pipermail/security-dev/2011-October/003972.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2011-November/004105.html From sean.mullan at oracle.com Tue Nov 29 06:55:57 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Nov 2011 09:55:57 -0500 Subject: Last Change for comment on 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4ED4ED50.4050102@gmx.de> References: <4ED4ED50.4050102@gmx.de> Message-ID: <4ED4F27D.1040707@oracle.com> Sorry, I have been very busy with some other things in the past few weeks, but I will try to find some time to look at your latest webrev this week. --Sean On 11/29/11 9:33 AM, Sebastian Sickelmann wrote: > Hi, > > I started some cleanup work a while ago and we got into short > discussions while cleaning-up javax.xml.crypto. > > Unfortunately i got no relay for a long time. Tried to get some comments > on 2011-10-27 [1] and 2011-11-23 [2] but nobody reacted. > > Maybe i have done something wrong, maybe i have bothered some of you > with my requests for comments, maybe i lost some email that was send to > me(which i tripple checked), but if the cleanup exception-chains is not > worth any discussion, then say it and i stop and work on other things. > > Don't get me wrong, i want to contribute and the cleanup was a nice > starting job but I don't have to do this cleanup work. > I suggested it and i want to "stay to my words", and i don't like open > issues in my inbox. > > So let me know if someone is interested in the cleanups and willing to > discuss some bigger changes or i will delete this task from my inbox. > > -- Sebastian > > [core-libs-dev] > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/008023.html > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008355.html > [security-dev] > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2011-October/003972.html > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2011-November/004105.html From xueming.shen at oracle.com Tue Nov 29 11:38:26 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 29 Nov 2011 19:38:26 +0000 Subject: hg: jdk8/tl/jdk: 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Message-ID: <20111129193836.8F7FA4749D@hg.openjdk.java.net> Changeset: a47de985fec9 Author: sherman Date: 2011-11-29 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a47de985fec9 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Summary: updated to zlib-1.2.5 Reviewed-by: alanb ! make/common/Defs.gmk ! make/java/zip/FILES_c.gmk ! make/sun/splashscreen/FILES_c.gmk - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h + src/share/native/java/util/zip/zlib-1.2.5/ChangeLog + src/share/native/java/util/zip/zlib-1.2.5/README + src/share/native/java/util/zip/zlib-1.2.5/compress.c + src/share/native/java/util/zip/zlib-1.2.5/crc32.h + src/share/native/java/util/zip/zlib-1.2.5/deflate.c + src/share/native/java/util/zip/zlib-1.2.5/deflate.h + src/share/native/java/util/zip/zlib-1.2.5/gzclose.c + src/share/native/java/util/zip/zlib-1.2.5/gzguts.h + src/share/native/java/util/zip/zlib-1.2.5/gzlib.c + src/share/native/java/util/zip/zlib-1.2.5/gzread.c + src/share/native/java/util/zip/zlib-1.2.5/gzwrite.c + src/share/native/java/util/zip/zlib-1.2.5/infback.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.h + src/share/native/java/util/zip/zlib-1.2.5/inffixed.h + src/share/native/java/util/zip/zlib-1.2.5/inflate.c + src/share/native/java/util/zip/zlib-1.2.5/inflate.h + src/share/native/java/util/zip/zlib-1.2.5/inftrees.c + src/share/native/java/util/zip/zlib-1.2.5/inftrees.h + src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.5/trees.c + src/share/native/java/util/zip/zlib-1.2.5/trees.h + src/share/native/java/util/zip/zlib-1.2.5/uncompr.c + src/share/native/java/util/zip/zlib-1.2.5/zadler32.c + src/share/native/java/util/zip/zlib-1.2.5/zconf.h + src/share/native/java/util/zip/zlib-1.2.5/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.5/zlib.h + src/share/native/java/util/zip/zlib-1.2.5/zutil.c + src/share/native/java/util/zip/zlib-1.2.5/zutil.h + test/java/util/zip/DeInflate.java From xueming.shen at oracle.com Tue Nov 29 13:04:41 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 29 Nov 2011 21:04:41 +0000 Subject: hg: jdk8/tl/jdk: 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Message-ID: <20111129210451.713F64749F@hg.openjdk.java.net> Changeset: 07e359b01d8a Author: sherman Date: 2011-11-29 13:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07e359b01d8a 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Summary: added methods Adler32/CRC32.update(ByteBuffer) Reviewed-by: alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c + test/java/util/zip/TimeChecksum.java From lana.steuck at oracle.com Tue Nov 29 13:52:23 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 29 Nov 2011 21:52:23 +0000 Subject: hg: jdk8/tl/hotspot: 42 new changesets Message-ID: <20111129215350.DABB2474A0@hg.openjdk.java.net> Changeset: 869804b759e7 Author: jcoomes Date: 2011-11-04 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/869804b759e7 7108553: Bump the hs23 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5bda8dae4e14 Author: never Date: 2011-10-23 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5bda8dae4e14 7103784: enable some flags by default Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 754110e02bd5 Author: never Date: 2011-10-23 12:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/754110e02bd5 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: kvn, iveresov ! src/share/vm/asm/codeBuffer.cpp Changeset: 42783d1414b2 Author: never Date: 2011-10-23 23:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42783d1414b2 Merge - make/templates/bsd-header Changeset: b20d64f83668 Author: twisti Date: 2011-10-24 07:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b20d64f83668 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: kvn, never, jrose ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 12d38ffcba2a Author: twisti Date: 2011-10-25 00:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12d38ffcba2a 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: iveresov, never ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2ec638646e86 Author: twisti Date: 2011-10-25 04:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ec638646e86 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sharedRuntime.cpp Changeset: a6eef545f1a2 Author: never Date: 2011-10-25 08:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6eef545f1a2 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid ! src/share/vm/opto/addnode.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/interfaceSupport.hpp Changeset: e69a66a1457b Author: kvn Date: 2011-10-25 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e69a66a1457b 7059039: EA: don't change non-escaping state of NULL pointer Summary: NULL pointers do not escape but escape state propagation may change it leading to worser results. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: d8cb48376797 Author: kvn Date: 2011-10-26 06:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8cb48376797 7097546: Optimize use of CMOVE instructions Summary: Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.hpp Changeset: cec1757a0134 Author: twisti Date: 2011-10-27 04:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cec1757a0134 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/runtime.cpp Changeset: e0658a9b3f87 Author: kvn Date: 2011-10-27 09:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0658a9b3f87 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Summary: Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Reviewed-by: never, twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp Changeset: 34535d2cb362 Author: iveresov Date: 2011-10-27 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34535d2cb362 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Summary: Initialize printable_bci of instruction when passed to Canonicalizer Reviewed-by: kvn, never ! src/share/vm/c1/c1_Canonicalizer.hpp Changeset: f350490a45fd Author: kvn Date: 2011-10-27 18:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f350490a45fd 7105611: Set::print() is broken Summary: Reimplemented class VSetI_ to restore Set::print(). Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp Changeset: eba044a722a4 Author: never Date: 2011-10-28 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eba044a722a4 7103261: crash with jittester on sparc Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + test/compiler/7103261/Test7103261.java Changeset: e3b0dcc327b9 Author: twisti Date: 2011-10-31 03:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3b0dcc327b9 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/opto/machnode.cpp Changeset: 71699e9d8673 Author: kvn Date: 2011-10-31 15:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71699e9d8673 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Summary: Use -Xss224k instead of -Xss128k. Reviewed-by: never ! test/compiler/6865265/StackOverflowBug.java Changeset: e342a5110bed Author: twisti Date: 2011-11-03 01:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e342a5110bed 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: kvn ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 448691f285a5 Author: twisti Date: 2011-11-03 04:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/448691f285a5 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp Changeset: 1feb272af3a7 Author: never Date: 2011-11-04 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1feb272af3a7 6636110: unaligned stackpointer leads to crash during deoptimization Reviewed-by: never, kvn Contributed-by: Andreas Schoesser ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 59e515ee9354 Author: kvn Date: 2011-11-07 14:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59e515ee9354 7059047: EA: can't find initializing store with several CheckCastPP Summary: Split adjust_escape_state() method into two methods to find initializing stores. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 44ce519bc3d1 Author: never Date: 2011-11-08 10:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/44ce519bc3d1 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: c9a03402fe56 Author: never Date: 2011-11-08 17:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9a03402fe56 7105305: assert check_method_context proper context Reviewed-by: jrose, kvn ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: e3e363b2bf19 Author: never Date: 2011-11-08 20:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3e363b2bf19 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 83d0b5cd1438 Author: twisti Date: 2011-11-09 00:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83d0b5cd1438 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: jrose, kvn, never ! src/share/vm/opto/callGenerator.cpp Changeset: 7e0e43cf86d6 Author: kvn Date: 2011-11-09 06:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e0e43cf86d6 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Summary: zero array when compiled code is deoptimized. Reviewed-by: never, twisti ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 670a74b863fc Author: kvn Date: 2011-11-09 07:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/670a74b863fc 7107042: assert(no_dead_loop) failed: dead loop detected Summary: Use dead nodes elimination code in PhaseIdealLoop before executing EA. Reviewed-by: never, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/globals.hpp Changeset: 78bef05801ca Author: twisti Date: 2011-11-10 04:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78bef05801ca Merge - src/share/vm/precompiled.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3c7d67df8d07 Author: dholmes Date: 2011-11-10 06:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c7d67df8d07 7108264: Fix for 7104173 is insufficient Summary: Disable PrintVMOptions by default for all builds Reviewed-by: dsamersoff, twisti ! src/share/vm/runtime/globals.hpp Changeset: f9a80a035a4a Author: coleenp Date: 2011-11-15 12:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9a80a035a4a Merge ! src/share/vm/runtime/globals.hpp Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59519b7d7b9d Merge Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile Changeset: ed80554efa25 Author: brutisso Date: 2011-11-02 08:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed80554efa25 7106751: G1: gc/gctests/nativeGC03 crashes VM with SIGSEGV Summary: _cset_rs_update_cl[] was indexed with values beyond what it is set up to handle. Reviewed-by: ysr, jmasa, johnc ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 8aae2050e83e Author: tonyp Date: 2011-11-07 22:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8aae2050e83e 7092309: G1: introduce old region set Summary: Keep track of all the old regions in the heap with a heap region set. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 53074c2c4600 Author: tonyp Date: 2011-11-08 00:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53074c2c4600 7099849: G1: include heap region information in hs_err files Reviewed-by: johnc, brutisso, poonam ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ab5107bee78c Author: brutisso Date: 2011-11-09 23:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab5107bee78c 7110190: GCCause::to_string missing case for _adaptive_size_policy Summary: Added case for _adaptive_size_policy Reviewed-by: johnc, ysr ! src/share/vm/gc_interface/gcCause.cpp Changeset: aa4c21b00f7f Author: brutisso Date: 2011-11-15 20:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa4c21b00f7f 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Summary: Reduce what arrayOopDesc::max_array_length() returns to avoid int overflow Reviewed-by: kvn, dholmes, tonyp ! src/share/vm/oops/arrayOop.hpp Changeset: 2ceafe3ceb65 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ceafe3ceb65 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: b1754f3fbbd8 Author: tonyp Date: 2011-11-17 13:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1754f3fbbd8 Merge Changeset: 6c2a55d4902f Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c2a55d4902f Merge Changeset: fde2a39ed7f3 Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fde2a39ed7f3 Added tag hs23-b06 for changeset 6c2a55d4902f ! .hgtags From lana.steuck at oracle.com Tue Nov 29 13:52:55 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 29 Nov 2011 21:52:55 +0000 Subject: hg: jdk8/tl/jdk: 9 new changesets Message-ID: <20111129215424.D1670474A1@hg.openjdk.java.net> Changeset: 2a147f854257 Author: twisti Date: 2011-11-02 02:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a147f854257 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/CallSiteTest.java Changeset: 5c34ed65176e Author: twisti Date: 2011-11-09 00:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c34ed65176e 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: iveresov, alanb, jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/ProblemList.txt ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: bdb2d63c176c Author: jcoomes Date: 2011-11-18 16:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdb2d63c176c Merge ! test/ProblemList.txt Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89952dc5be8e 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h Reviewed-by: prr, bae Contributed-by: littlee at linux.vnet.ibm.com ! src/share/native/sun/awt/medialib/mlib_types.h Changeset: 60331bbcf4ad Author: lana Date: 2011-11-18 16:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60331bbcf4ad Merge Changeset: 855675a4235b Author: lana Date: 2011-11-23 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/855675a4235b Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 3c248d0e2c48 Author: lana Date: 2011-11-28 15:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c248d0e2c48 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: c5313d712ab0 Author: lana Date: 2011-11-29 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3edcdff37e1 Merge From bradford.wetmore at oracle.com Tue Nov 29 17:20:16 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 29 Nov 2011 17:20:16 -0800 Subject: Algorithm Names - registry? In-Reply-To: <20111128183050.8DAA76BF3@mail.openjdk.java.net> References: <20111128183050.8DAA76BF3@mail.openjdk.java.net> Message-ID: <4ED584D0.40505@oracle.com> I'm just one person, but I'm completely open to discussing on security-dev potential names/values to add. I do have strong hesitations about just opening it up to anyone to add something (i.e. a wiki), allowing them to reserve names with no discussion. (I'm thinking what a mess it could be if there was no IETF-IANA.) The JDK 7 edition is at: http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html The current doc does have most of the items you're suggesting, but maybe not as structured. A reformatting might be helpful. I would also hesitate including optional secondary names, as the point of a standard name is to settle on one name that can be used across implementations. Having three possible aliases like for SHA1 (SHA-1, SHA1, SHA) just makes things confusing for end users. Hadn't really thought about adding Javacard algids here. I know outside Oracle this shouldn't matter, but they're a completely different group. My $.02. Brad On 11/28/2011 10:30 AM, Michael StJohns wrote: > One of the items that seems terribly out of date is the "Standard Names" list. Also, sometimes its difficult to tell which algorithm - specifically - the name applies to. > > I'm wondering if it isn't time to create something like a Wiki for name registration and - for example - let the folks building the various JCE providers add or propose names. I mention this because I'm finding it tiresome looking through the BouncyCastle source code each time I need to find an algorithm name not on the list. > > I would suggest as data elements: > > Primary name, Optional secondary names; Object Identifier (if any); Applicable JCE class (e.g. Cipher, MessageDigest, etc), Primary standard (e.g. RFCXXXX, ISOXXXX - section yy, option zzz); Alternate standards (for example ECDSA is referenced in SECG, NIST, ANSI etc); clarifying comments (e.g. "Use IvAlgorithmParameter with this"). > > > Continuing this thought - the Javacard algorithm identifiers could also be included in this table. > > Mike > From alan.bateman at oracle.com Wed Nov 30 07:26:40 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 30 Nov 2011 15:26:40 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111130152715.55301474B0@hg.openjdk.java.net> Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4749df4f04f1 7030624: size_t usages in src/windows/native/java/io/io_util_md.c need to be re-visited Reviewed-by: lancea, chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h Changeset: 7795c41ed54c Author: alanb Date: 2011-11-30 12:42 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7795c41ed54c 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) Reviewed-by: lancea, chegar, smarks ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java From stuart.marks at oracle.com Wed Nov 30 13:12:23 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 30 Nov 2011 21:12:23 +0000 Subject: hg: jdk8/tl/jdk: 7116322: enhance javac make rule with a little bit of instrumentation Message-ID: <20111130211232.E8AE1474C4@hg.openjdk.java.net> Changeset: 43a630f11af6 Author: smarks Date: 2011-11-30 13:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43a630f11af6 7116322: enhance javac make rule with a little bit of instrumentation Reviewed-by: dholmes, ohair ! make/common/Rules.gmk From mstjohns at comcast.net Wed Nov 30 18:34:48 2011 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 30 Nov 2011 21:34:48 -0500 Subject: Algorithm Names - registry? In-Reply-To: <4ED584D0.40505@oracle.com> References: <20111128183050.8DAA76BF3@mail.openjdk.java.net> <4ED584D0.40505@oracle.com> Message-ID: <20111201023456.A241C616A@mail.openjdk.java.net> The web page you pointed me at is a bit more up to date than what I was looking at. To be honest, I couldn't find a path there from the public web pages - but that may be just me. What I'm finding when playing with things like ZigBee, smart cards and other similar technologies is that there are some specific crypto modes, algorithms and functions that are implemented in various providers, but for which I need to go looking in the source code to find the specific incantation (name). For example - BC uses ISO9797ALG3MACWITHISO7816-4PADDING as the tag for the MAC that's used for a number of functions in the SCP02 GlobalPlatform protocol. There are a number of algorithms documented in the javacard jdk that have no standard names in the JCE (for example the Korean SEED algorithm). There are also variants on named algorithms that don't have a standard name - for example the extension of AES key wrap that allows wrapping of variable length data (RFC5649). Let's not even get into the whole host of GOST algorithms as well as the various candidate SHA3 algorithms. Maybe there's two parts to this - the first a standard way of deriving a name from the base standard (_[_alg shortname[_algvariation]][/algoption]) => MAC_ISO9797_ALG3_MODE3/7816-4Padding. It would take a number of worked examples to figure out if this were feasible. That sets the standard for externally created names. And then and only then a second part which takes the proposed names and adds them to the registry. I hadn't contemplating letting just anyone write into the registry, but I was looking for something a bit more dynamic than the current system. By the way - why are CCM and GCM ciphers rather than cipher modes in the table? They can be applied to any block cipher (i think with a specific block length). Mike At 08:20 PM 11/29/2011, Brad Wetmore wrote: >I'm just one person, but I'm completely open to discussing on security-dev potential names/values to add. I do have strong hesitations about just opening it up to anyone to add something (i.e. a wiki), allowing them to reserve names with no discussion. (I'm thinking what a mess it could be if there was no IETF-IANA.) > >The JDK 7 edition is at: > >http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html > >The current doc does have most of the items you're suggesting, but maybe not as structured. A reformatting might be helpful. > >I would also hesitate including optional secondary names, as the point of a standard name is to settle on one name that can be used across implementations. Having three possible aliases like for SHA1 (SHA-1, SHA1, SHA) just makes things confusing for end users. > >Hadn't really thought about adding Javacard algids here. I know outside Oracle this shouldn't matter, but they're a completely different group. > >My $.02. > >Brad > > > > >On 11/28/2011 10:30 AM, Michael StJohns wrote: >>One of the items that seems terribly out of date is the "Standard Names" list. Also, sometimes its difficult to tell which algorithm - specifically - the name applies to. >> >>I'm wondering if it isn't time to create something like a Wiki for name registration and - for example - let the folks building the various JCE providers add or propose names. I mention this because I'm finding it tiresome looking through the BouncyCastle source code each time I need to find an algorithm name not on the list. >> >>I would suggest as data elements: >> >>Primary name, Optional secondary names; Object Identifier (if any); Applicable JCE class (e.g. Cipher, MessageDigest, etc), Primary standard (e.g. RFCXXXX, ISOXXXX - section yy, option zzz); Alternate standards (for example ECDSA is referenced in SECG, NIST, ANSI etc); clarifying comments (e.g. "Use IvAlgorithmParameter with this"). >> >> >>Continuing this thought - the Javacard algorithm identifiers could also be included in this table. >> >>Mike From weijun.wang at oracle.com Wed Nov 30 19:35:29 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 01 Dec 2011 11:35:29 +0800 Subject: code review request: 7115524: Regression: keytool -printcert -sslserver failure In-Reply-To: References: <03DF622B-D49A-40D7-9581-4AF32747C9BB@Oracle.Com> <3ABE0759-F871-41D8-A3D0-66896AD4B2F8@oracle.com> Message-ID: <4ED6F601.8070404@oracle.com> Hi Xuelei Please review the code changes for 7u4: http://cr.openjdk.java.net/~weijun/7115524/7u4/webrev.00/ I've changed the synopsis because there is no SSLServerCertStore in 7u4. Thanks Max -------------------------------------------------- 7115524: Regression: keytool -printcert -sslserver failure Description: In 7u4, there is no sun.security.provider.certpath.ssl.SSLServerCertStore. That's because the class was extracted from a KeyTool method in JDK 8 (6953295). However, the same coding error still exists inside the KeyTool method. The synopis for this subCR is updated to reflect the fact. From bradford.wetmore at oracle.com Wed Nov 30 23:13:27 2011 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 30 Nov 2011 23:13:27 -0800 Subject: Algorithm Names - registry? In-Reply-To: <201112010234.pB12YtUf016974@rcsinet12.oracle.com> References: <20111128183050.8DAA76BF3@mail.openjdk.java.net> <4ED584D0.40505@oracle.com> <201112010234.pB12YtUf016974@rcsinet12.oracle.com> Message-ID: <4ED72917.1000606@oracle.com> On 11/30/2011 6:34 PM, Michael StJohns wrote: > By the way - why are CCM and GCM ciphers rather than cipher modes in the table? They can be applied to any block cipher (i think with a specific block length). Good grief. I apparently didn't review the tech writers work on that one. I'll get that fixed ASAP. Good catch. I'll look into the rest of the comments later, it's 11:30pm :). Thanks for the response. Brad > Mike > > > At 08:20 PM 11/29/2011, Brad Wetmore wrote: >> I'm just one person, but I'm completely open to discussing on security-dev potential names/values to add. I do have strong hesitations about just opening it up to anyone to add something (i.e. a wiki), allowing them to reserve names with no discussion. (I'm thinking what a mess it could be if there was no IETF-IANA.) >> >> The JDK 7 edition is at: >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html >> >> The current doc does have most of the items you're suggesting, but maybe not as structured. A reformatting might be helpful. >> >> I would also hesitate including optional secondary names, as the point of a standard name is to settle on one name that can be used across implementations. Having three possible aliases like for SHA1 (SHA-1, SHA1, SHA) just makes things confusing for end users. >> >> Hadn't really thought about adding Javacard algids here. I know outside Oracle this shouldn't matter, but they're a completely different group. >> >> My $.02. >> >> Brad >> >> >> >> >> On 11/28/2011 10:30 AM, Michael StJohns wrote: >>> One of the items that seems terribly out of date is the "Standard Names" list. Also, sometimes its difficult to tell which algorithm - specifically - the name applies to. >>> >>> I'm wondering if it isn't time to create something like a Wiki for name registration and - for example - let the folks building the various JCE providers add or propose names. I mention this because I'm finding it tiresome looking through the BouncyCastle source code each time I need to find an algorithm name not on the list. >>> >>> I would suggest as data elements: >>> >>> Primary name, Optional secondary names; Object Identifier (if any); Applicable JCE class (e.g. Cipher, MessageDigest, etc), Primary standard (e.g. RFCXXXX, ISOXXXX - section yy, option zzz); Alternate standards (for example ECDSA is referenced in SECG, NIST, ANSI etc); clarifying comments (e.g. "Use IvAlgorithmParameter with this"). >>> >>> >>> Continuing this thought - the Javacard algorithm identifiers could also be included in this table. >>> >>> Mike > > From paulo.ribeiro at multicert.com Tue Nov 22 01:11:47 2011 From: paulo.ribeiro at multicert.com (Paulo Ricardo Ribeiro) Date: Tue, 22 Nov 2011 09:11:47 +0000 Subject: Unable to wrap key using SunPKCS11 Provider In-Reply-To: <4ECAA5BF.4050403@oracle.com> References: <4EB90F88.1000109@multicert.com> <4ECAA5BF.4050403@oracle.com> Message-ID: <4ECB6753.5000608@multicert.com> Hello again the key, on the HSM is flagged as "Extractable", but, since the only way to actually extract it is by wrapping it, for now it is impossible to do it. For now I'll have to use the vendor's "Proprietary API", but I'm glad to hear that this issue will be solved in jdk7 update. Thanks for your time, Paulo Ricardo On 21-11-2011 19:25, Valerie (Yu-Ching) Peng wrote: > > The support for key wrapping and unwrapping is tracked under > 4898471 "Support for key wrapping and unwrapping" > > I assume that the 3DES key is unextractable? If yes, I am afraid that > this would require that 4898471 be fixed. > I'll fix this in jdk7 update and later releases. > Thanks, > Valerie > > On 11/08/11 03:16, Paulo Ricardo Ribeiro wrote: >> Hello >> >> I'm trying to wrap a 3DES key, that is stored in a HSM, using the >> SunPKCS11 provider: >> >> | Cipher wrapper = Cipher.getInstance("DESede/CBC/NOPADDING", getProviderName()); >> wrapper.init(Cipher.WRAP_MODE, wrappingKey,*new* IvParameterSpec(iv)); >> cText = wrapper.wrap(wrappedKey); >> | >> >> >> The problem is that I'm obtaining the following exception: >> |java.security.InvalidAlgorithmParameterException: Unsupported mode: 3 >> at sun.security.pkcs11.P11Cipher.implInit(P11Cipher.java:316) >> at sun.security.pkcs11.P11Cipher.engineInit(P11Cipher.java:280) >> at javax.crypto.Cipher.init(DashoA13*..) >> at javax.crypto.Cipher.init(DashoA13*..) >> >> | >> >> After searching for the source code, I've found that the provider >> only supports the ENCRYPT_MODE and DECRYPT_MODE >> >> |// actual init() implementation >> *private* *void* implInit(*int* opmode, Key key,*byte*[] iv, >> SecureRandom random) >> *throws* InvalidKeyException, InvalidAlgorithmParameterException{ >> cancelOperation(); >> *switch* (opmode){ >> *case* Cipher.ENCRYPT_MODE: >> encrypt =*true*; >> *break*; >> *case* Cipher.DECRYPT_MODE: >> encrypt =*false*; >> *break*; >> *default*: >> *throw* *new* InvalidAlgorithmParameterException >> ("Unsupported mode:" + opmode); >> } >> (...) >> } >> | >> >> The full source is available at >> http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/security/pkcs11/P11Cipher.java.html >> >> So, I was wondering if is there a way to wrap a key, using the >> SunPKCS11 provider. >> >> -- >> >> *Paulo Ricardo Ribeiro* >> Departamento de Integra??o e Desenvolvimento >> >> *MULTICERT - Servi?os de Certifica??o Electr?nica, S.A.* >> www.multicert.com >> ??????????????????????????????????????????????????????????????????????? >> *Para obter direc??es para as nossas instala??es carregue aqui* >> >> *Porto:*Av. Sid?nio Pais, 379, Edif?cio B, Piso 1, Sala 5 ? 4100?468 >> Porto ? Portugal >> *T:*+351 223 391 810 | *F: *+351 223 391 811 >> ??????????????????????????????????????????????????????????????????????? >> > -- *Paulo Ricardo Ribeiro* Departamento de Integra??o e Desenvolvimento *MULTICERT - Servi?os de Certifica??o Electr?nica, S.A.* www.multicert.com ??????????????????????????????????????????????????????????????????????? *Para obter direc??es para as nossas instala??es carregue aqui* *Porto:*Av. Sid?nio Pais, 379, Edif?cio B, Piso 1, Sala 5 ? 4100?468 Porto ? Portugal *T:*+351 223 391 810 | *F: *+351 223 391 811 *M:*+351 925 770 081 | *Email:*paulo.ribeiro at multicert.com ??????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111122/63c39900/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7530 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111122/63c39900/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: gafaicdi.png Type: image/png Size: 7530 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111122/63c39900/gafaicdi.png -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3482 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111122/63c39900/smime.p7s