From mstjohns at comcast.net Thu Apr 1 00:51:47 2010 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 31 Mar 2010 20:51:47 -0400 Subject: [security-dev 01751]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BB2F93E.4070300@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> Message-ID: <20100401005145.4B1A6686B@mail.openjdk.java.net> This may actually be a bug in the PKCS11 provider. KeyPairGenerator should be generating a "Session" key pair. When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. Let me look at the code and see what's going on and make further comments tomorrow. Mike At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >Hi, > >Sorry if I misunderstood you. That is actually exactly how we do it, > >1. Use KeyPairGenerator with P11 provider to generate key pair. >2. Create a keystore with the P11 provier. >3. Generate a self signed certificate. >4. keystore.setKeyEntry(myalias, privateKey, null, cert). > >The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >1. Private key - no alias >2. Public key - no alias >3. Certificate - myalias > >The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. > >If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. > >So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. > >Cheers, >Tomas > > >On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>Why do you assume that the key is generated in software? >>You use the KeyGenerator API to generate a key, this key can be >>generated on the HSM if you have SunPKCS11 provider configured to be the >>most preferred provider. This key should actually just encapsulate the >>native key handle (not the actual value/encoding) which you can then >>pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>impl would then take this key object (with the native key handle) and >>create a persistent copy on the HSM with the specified alias. >> >>Regards, >>Valerie >> >>On 03/29/10 22:57, Tomas Gustavsson wrote: >>>Hi, thanks for the answer. >>> >>>Generating a key in software and trying to store it on the HSM violates >>>the whole idea of using an HSM. Which is to generate and maintain the >>>keys in the HSM at all times. >>>Most high security policies *requires* that the keys are generated by >>>the HSM, inside the HSM. >>>I also doubt that it would work to store software generated keys using >>>the keytool API. Many HSMs even forbid this, at least when running in >>>strict FIPS mode. >>> >>>Regards, >>>Tomas >>> >>>Valerie Peng wrote: >>> >>>>Have you tried saving that key through the KeyStore API which allows you >>>>to specify an alias? >>>>Thanks, >>>>Valerie >>>> >>>>On 03/26/10 00:05, Tomas Gustavsson wrote: >>>> >>>>>Slightly off topic. >>>>>Something I would like to see is API support for setting aliases when >>>>>using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>not allow changing an alias of private keys after they have been >>>>>generated. Since the key pair generator sets a blank alias when using >>>>>PKCS#11, HSM key pairs are left with no alias. >>>>> >>>>>You can set an alias by providing it using pkcs11 attributes through >>>>>the provider, but that alias is provider global (for all generated key >>>>>pairs) which is not very usable. >>>>> >>>>>Regards, >>>>>Tomas >>>>> >>>>>On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>> >>>>>>Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>are constructed using the attributes values associated with the >>>>>>keys/certs. Thus, this is probably due to some problem with the native >>>>>>library which generated the keys/certs. >>>>>>Valerie >>>>>> >>>>>>On 03/18/10 19:03, Weijun Wang wrote: >>>>>> >>>>>>>Hi Valerie >>>>>>> >>>>>>>As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>> >>>>>>>Is this something we should fix on the Java side? >>>>>>> >>>>>>>Thanks >>>>>>>Max >>>>>>> >>> From valerie.peng at oracle.com Thu Apr 1 01:00:15 2010 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 31 Mar 2010 18:00:15 -0700 Subject: [security-dev 01752]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> Message-ID: <4BB3F01F.6080504@oracle.com> If the default PKCS11 config is used, I'd expect that KeyPairGenerator to generate a "session" key and then SunPKCS11 keystore impl will do a C_CopyObject(...) w/ the desired alias. Is a custom PKCS11 config file used here? If yes, perhaps it specifies that token key be generated for key generation? Valerie On 03/31/10 17:51, Michael StJohns wrote: > KeyPairGenerator should be generating a "Session" key pair. > > When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. > > Let me look at the code and see what's going on and make further comments tomorrow. > > Mike > > > At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: > > >> Hi, >> >> Sorry if I misunderstood you. That is actually exactly how we do it, >> >> 1. Use KeyPairGenerator with P11 provider to generate key pair. >> 2. Create a keystore with the P11 provier. >> 3. Generate a self signed certificate. >> 4. keystore.setKeyEntry(myalias, privateKey, null, cert). >> >> The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >> 1. Private key - no alias >> 2. Public key - no alias >> 3. Certificate - myalias >> >> The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >> This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >> >> If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >> >> So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >> >> Cheers, >> Tomas >> >> >> On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >> >>> Why do you assume that the key is generated in software? >>> You use the KeyGenerator API to generate a key, this key can be >>> generated on the HSM if you have SunPKCS11 provider configured to be the >>> most preferred provider. This key should actually just encapsulate the >>> native key handle (not the actual value/encoding) which you can then >>> pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>> impl would then take this key object (with the native key handle) and >>> create a persistent copy on the HSM with the specified alias. >>> >>> Regards, >>> Valerie >>> >>> On 03/29/10 22:57, Tomas Gustavsson wrote: >>> >>>> Hi, thanks for the answer. >>>> >>>> Generating a key in software and trying to store it on the HSM violates >>>> the whole idea of using an HSM. Which is to generate and maintain the >>>> keys in the HSM at all times. >>>> Most high security policies *requires* that the keys are generated by >>>> the HSM, inside the HSM. >>>> I also doubt that it would work to store software generated keys using >>>> the keytool API. Many HSMs even forbid this, at least when running in >>>> strict FIPS mode. >>>> >>>> Regards, >>>> Tomas >>>> >>>> Valerie Peng wrote: >>>> >>>> >>>>> Have you tried saving that key through the KeyStore API which allows you >>>>> to specify an alias? >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>> >>>>> >>>>>> Slightly off topic. >>>>>> Something I would like to see is API support for setting aliases when >>>>>> using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>> not allow changing an alias of private keys after they have been >>>>>> generated. Since the key pair generator sets a blank alias when using >>>>>> PKCS#11, HSM key pairs are left with no alias. >>>>>> >>>>>> You can set an alias by providing it using pkcs11 attributes through >>>>>> the provider, but that alias is provider global (for all generated key >>>>>> pairs) which is not very usable. >>>>>> >>>>>> Regards, >>>>>> Tomas >>>>>> >>>>>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>> >>>>>> >>>>>>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>> are constructed using the attributes values associated with the >>>>>>> keys/certs. Thus, this is probably due to some problem with the native >>>>>>> library which generated the keys/certs. >>>>>>> Valerie >>>>>>> >>>>>>> On 03/18/10 19:03, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Valerie >>>>>>>> >>>>>>>> As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>> >>>>>>>> Is this something we should fix on the Java side? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xueming.shen at sun.com Sun Apr 4 01:41:07 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Sun, 04 Apr 2010 01:41:07 +0000 Subject: [security-dev 01753]: hg: jdk7/tl/jdk: 4947220: (process)Runtime.exec() cannot invoke applications with unicode parameters(win) Message-ID: <20100404014206.ADA4E44084@hg.openjdk.java.net> Changeset: 1105276dbd6a Author: sherman Date: 2010-04-03 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1105276dbd6a 4947220: (process)Runtime.exec() cannot invoke applications with unicode parameters(win) Summary: to use CreateProcessW on Windowns platform Reviewed-by: martin ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/lang/java_props_md.c ! test/java/lang/ProcessBuilder/Basic.java From abhijit.saha at sun.com Mon Apr 5 22:49:57 2010 From: abhijit.saha at sun.com (abhijit.saha at sun.com) Date: Mon, 05 Apr 2010 22:49:57 +0000 Subject: [security-dev 01754]: hg: jdk7/tl/hotspot: 6 new changesets Message-ID: <20100405225025.EE1B544332@hg.openjdk.java.net> Changeset: b5d78a3b8843 Author: kvn Date: 2009-12-03 14:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b5d78a3b8843 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes Summary: Use size_t type cast to widen int values in typeArrayKlass::copy_array(). Reviewed-by: never, jcoomes ! src/share/vm/oops/typeArrayKlass.cpp + test/compiler/6892265/Test.java Changeset: ae4032fb0a5b Author: kvn Date: 2010-01-21 10:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ae4032fb0a5b 6894807: No ClassCastException for HashAttributeSet constructors if run with -Xcomp Summary: Return interface klass type if it is exact. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/type.cpp Changeset: 0c3f888b7636 Author: acorn Date: 2010-01-19 16:03 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0c3f888b7636 6626217: Fixed loader constraint array handling Summary: Loader constraints track array elements, not arrays themselves. Reviewed-by: dcubed, kevinw ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3d531bbe5917 Author: acorn Date: 2010-01-28 13:59 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3d531bbe5917 Merge Changeset: f5dd08ad65df Author: acorn Date: 2010-03-15 15:51 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f5dd08ad65df 6932480: Fix crash in CompilerThread/Parser. Unloaded array klass? Summary: Restore code deleted in 6626217 Reviewed-by: asaha, kevinw ! src/share/vm/ci/ciEnv.cpp Changeset: 09ac706c2623 Author: asaha Date: 2010-03-24 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09ac706c2623 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp - src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp ! src/share/vm/opto/type.cpp From abhijit.saha at sun.com Mon Apr 5 23:17:13 2010 From: abhijit.saha at sun.com (abhijit.saha at sun.com) Date: Mon, 05 Apr 2010 23:17:13 +0000 Subject: [security-dev 01755]: hg: jdk7/tl/jdk: 30 new changesets Message-ID: <20100405232703.B483D4433B@hg.openjdk.java.net> Changeset: d3309aae68ef Author: dl Date: 2009-10-06 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3309aae68ef 6888149: AtomicReferenceArray causes SIGSEGV -> SEGV_MAPERR error Summary: Avoid integer overflow by using long arithmetic Reviewed-by: martin, dholmes ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java Changeset: 08f57141c305 Author: asaha Date: 2009-11-20 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/08f57141c305 Merge - test/sun/tools/native2ascii/test2 Changeset: b1e8f41ed755 Author: chegar Date: 2009-11-23 12:40 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b1e8f41ed755 6639665: ThreadGroup finalizer allows creation of false root ThreadGroups Reviewed-by: alanb, hawtin ! src/share/classes/java/lang/ThreadGroup.java Changeset: e943f6b0b0e9 Author: alanb Date: 2009-11-25 10:02 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e943f6b0b0e9 6736390: File TOCTOU deserialization vulnerability Reviewed-by: hawtin ! src/share/classes/java/io/File.java Changeset: ff9c2f53594e Author: sherman Date: 2009-11-25 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff9c2f53594e 6745393: Inflater/Deflater clone issue Summary: To use explicit lobk object. Reviewed-by: alanb ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c Changeset: d893f890b4dd Author: sherman Date: 2009-11-25 12:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d893f890b4dd 6904925: Changeset for 6745393 for jdk7 ssr forest was incomplete Summary: To add, commit and push back the ZStreamRef.java Reviewed-by: alanb + src/share/classes/java/util/zip/ZStreamRef.java Changeset: df3091222715 Author: mchung Date: 2009-11-25 09:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df3091222715 6893947: Deserialization of RMIConnectionImpl objects should enforce stricter checks [ZDI-CAN-588] Summary: narrow the doPrivileged block to only set context ClassLoader Reviewed-by: hawtin, emcmanus ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: bc309e9233ce Author: mchung Date: 2009-11-25 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc309e9233ce Merge Changeset: 621edf6b03fc Author: mchung Date: 2009-11-25 16:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/621edf6b03fc Merge Changeset: 338c8775f0a3 Author: asaha Date: 2009-11-26 07:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/338c8775f0a3 Merge Changeset: f0b63b6d9709 Author: asaha Date: 2009-12-01 08:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f0b63b6d9709 Merge - test/tools/launcher/SolarisDataModel.sh - test/tools/launcher/SolarisRunpath.sh - test/tools/launcher/libraryCaller.c - test/tools/launcher/libraryCaller.h - test/tools/launcher/libraryCaller.java Changeset: 121fa73c7185 Author: michaelm Date: 2009-12-02 12:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/121fa73c7185 6893954: Subclasses of InetAddress may incorrectly interpret network addresses Summary: runtime type checks and deserialization check Reviewed-by: chegar, alanb, jccollet ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/Socket.java ! src/share/classes/sun/nio/ch/Net.java Changeset: edaa7e2efd63 Author: asaha Date: 2009-12-04 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/edaa7e2efd63 Merge - make/tools/CharsetMapping/DoubleByte-X.java - make/tools/CharsetMapping/SingleByte-X.java - src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java - test/java/util/Formatter/Basic-X.java Changeset: 3598d6eb087c Author: xuelei Date: 2009-12-07 21:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3598d6eb087c 6898739: TLS renegotiation issue Summary: the interim fix disables TLS/SSL renegotiation Reviewed-by: mullan, chegar, wetmore ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java Changeset: 91a4840fa9b4 Author: mullan Date: 2009-12-08 15:58 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/91a4840fa9b4 6633872: Policy/PolicyFile leak dynamic ProtectionDomains. Reviewed-by: hawtin ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/ProtectionDomain.java + src/share/classes/sun/misc/JavaSecurityProtectionDomainAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/provider/PolicyFile.java Changeset: 7a60d100ffa5 Author: mullan Date: 2009-12-18 09:09 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7a60d100ffa5 6904162: Add new VeriSign root CA certificates to JRE and remove some old/unused ones Reviewed-by: asaha - test/lib/security/cacerts/VerifyCACerts.java Changeset: 3dabb7d5be98 Author: malenkov Date: 2009-12-22 17:56 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3dabb7d5be98 6904691: Java Applet Trusted Methods Chaining Privilege Escalation Vulnerability Reviewed-by: hawtin, peterz ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/Statement.java ! test/java/beans/EventHandler/Test6277246.java ! test/java/beans/EventHandler/Test6277266.java Changeset: c80b6350de63 Author: michaelm Date: 2010-01-12 12:13 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c80b6350de63 6910590: Application can modify command array, in ProcessBuilder Summary: clone array returned by List.toArray() Reviewed-by: chegar, alanb ! src/share/classes/java/lang/ProcessBuilder.java Changeset: 0667ab707c48 Author: bae Date: 2010-02-17 12:49 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0667ab707c48 6914866: Sun JRE ImagingLib arbitrary code execution vulnerability Reviewed-by: prr, hawtin ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: 494aea51f26f Author: bae Date: 2010-02-17 13:10 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/494aea51f26f 6914823: Java AWT Library Invalid Index Vulnerability Reviewed-by: flar, hawtin ! src/share/classes/sun/awt/image/ImageRepresentation.java Changeset: 45ead4a2c48b Author: bae Date: 2010-02-17 13:32 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45ead4a2c48b 6909597: Sun Java Runtime Environment JPEGImageReader stepX Integer Overflow Vulnerability Reviewed-by: igor ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 1ff19af7b735 Author: bae Date: 2010-02-19 22:30 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ff19af7b735 6899653: Sun Java Runtime CMM readMabCurveData Buffer Overflow Vulnerability Reviewed-by: prr, hawtin ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c Changeset: cda01c4b091c Author: ksrini Date: 2010-02-22 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cda01c4b091c 6902299: Java JAR "unpack200" must verify input parameters Summary: Added several checks for addition of values before memory allocation Reviewed-by: asaha ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: 7a6b3cc68e92 Author: denis Date: 2010-02-26 03:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7a6b3cc68e92 6887703: Unsigned applet can retrieve the dragged information before drop action occur Reviewed-by: uta ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: c5c6f8fa92ae Author: denis Date: 2010-03-06 03:37 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c5c6f8fa92ae 6932659: JTreg test files were missed in push of 6887703 Reviewed-by: uta ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java Changeset: 2805db6e6ff6 Author: asaha Date: 2010-03-24 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2805db6e6ff6 Merge - make/java/redist/FILES.gmk - make/java/text/FILES_java.gmk - make/sun/nio/FILES_java.gmk ! src/share/classes/java/beans/Statement.java ! src/share/classes/java/util/zip/Deflater.java - src/share/classes/javax/swing/plaf/synth/DefaultMenuLayout.java - src/share/classes/sun/awt/ComponentAccessor.java - src/share/classes/sun/awt/WindowAccessor.java - src/share/classes/sun/dyn/util/BytecodeSignature.java - src/share/classes/sun/security/provider/IdentityDatabase.java ! src/share/classes/sun/security/provider/PolicyFile.java - src/share/classes/sun/security/provider/SystemIdentity.java - src/share/classes/sun/security/provider/SystemSigner.java - src/share/classes/sun/security/x509/X500Signer.java - src/share/classes/sun/security/x509/X509Cert.java - src/share/classes/sun/swing/plaf/synth/SynthUI.java - src/share/classes/sun/tools/jar/JarVerifierStream.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java - test/java/net/Socket/FDClose.java Changeset: 1dccfa00dc64 Author: asaha Date: 2010-03-24 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1dccfa00dc64 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 6ec14b5ede77 Author: asaha Date: 2010-03-25 07:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6ec14b5ede77 Merge Changeset: 3ef9b3446677 Author: asaha Date: 2010-03-29 07:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3ef9b3446677 Merge Changeset: a9fdd143a58e Author: asaha Date: 2010-04-05 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a9fdd143a58e Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java From christopher.hegarty at sun.com Tue Apr 6 12:54:25 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 06 Apr 2010 12:54:25 +0000 Subject: [security-dev 01756]: hg: jdk7/tl/jdk: 6648001: Cancelling HTTP authentication causes subsequent deadlocks Message-ID: <20100406125524.CE3BB44401@hg.openjdk.java.net> Changeset: 69002275e0e2 Author: chegar Date: 2010-04-06 13:47 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69002275e0e2 6648001: Cancelling HTTP authentication causes subsequent deadlocks Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/Authenticator/Deadlock.java From christopher.hegarty at sun.com Tue Apr 6 14:50:51 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 06 Apr 2010 14:50:51 +0000 Subject: [security-dev 01757]: hg: jdk7/tl/jdk: 6921111: NullPointerException in PlainDatagramSocketImpl.socketSetOption Message-ID: <20100406145132.DB24C44413@hg.openjdk.java.net> Changeset: 495ba30cf02f Author: chegar Date: 2010-04-06 15:44 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/495ba30cf02f 6921111: NullPointerException in PlainDatagramSocketImpl.socketSetOption Reviewed-by: alanb ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c From xueming.shen at sun.com Tue Apr 6 22:52:51 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Tue, 06 Apr 2010 22:52:51 +0000 Subject: [security-dev 01758]: hg: jdk7/tl/jdk: 6717164: FilterInputStream.skip incorrectly inherits wording specifying how the InputStream.skip works Message-ID: <20100406225348.066E744421@hg.openjdk.java.net> Changeset: 0b7f10901f30 Author: sherman Date: 2010-04-06 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0b7f10901f30 6717164: FilterInputStream.skip incorrectly inherits wording specifying how the InputStream.skip works Summary: restoring the javadoc Reviewed-by: alanb ! src/share/classes/java/io/FilterInputStream.java From martinrb at google.com Wed Apr 7 20:08:28 2010 From: martinrb at google.com (martinrb at google.com) Date: Wed, 07 Apr 2010 20:08:28 +0000 Subject: [security-dev 01759]: hg: jdk7/tl/jdk: 6941130: Semaphore should throw if number of permits overflows or underflows Message-ID: <20100407200947.A579D44445@hg.openjdk.java.net> Changeset: fc7c38b2584c Author: martin Date: 2010-04-07 12:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fc7c38b2584c 6941130: Semaphore should throw if number of permits overflows or underflows Summary: Check if release could make number of permits negative Reviewed-by: dl, dholmes ! src/share/classes/java/util/concurrent/Semaphore.java + test/java/util/concurrent/Semaphore/PermitOverflow.java From sean.mullan at oracle.com Fri Apr 9 13:18:58 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 09 Apr 2010 09:18:58 -0400 Subject: [security-dev 01760]: Quick code review for 6909281 Message-ID: <4BBF2942.7000203@oracle.com> Hi Andrew, Could I get a quick code review for 6909281 which also needs to be fixed in JDK 7: http://cr.openjdk.java.net/~mullan/6909281/webrev/ Thanks, Sean From ahughes at redhat.com Fri Apr 9 13:31:29 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 14:31:29 +0100 Subject: [security-dev 01761]: Re: Quick code review for 6909281 In-Reply-To: <4BBF2942.7000203@oracle.com> References: <4BBF2942.7000203@oracle.com> Message-ID: On 9 April 2010 14:18, Sean Mullan wrote: > Hi Andrew, > > Could I get a quick code review for 6909281 which also needs to be fixed in > JDK 7: > > http://cr.openjdk.java.net/~mullan/6909281/webrev/ > > Thanks, > Sean > Sure. Looks good to me. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From boris.dusek at gmail.com Fri Apr 9 14:19:30 2010 From: boris.dusek at gmail.com (=?UTF-8?B?Qm9yaXMgRHXFoWVr?=) Date: Fri, 9 Apr 2010 16:19:30 +0200 Subject: [security-dev 01762]: Re: 6522064: Keystore aliases from MS CryptoAPI have bad encoding In-Reply-To: References: Message-ID: Hello, no one responded to my request for comments and possibly enlightment below, so I guess the right thing to do is that I just implement my proposed changes in a manner that I myself find "final" and submit the patch to the bugzilla directly, where the rest of the discussion will take place? Thanks, Boris 2010/3/30 Boris Du?ek : > Hello, > this is my first time contributing to Java or Sun (Oracle), so please > forgive me if I am doing something wrong. > > I am writing because I met an issue with JSignPdf app and my testing > certificates, which contain non-ASCII characters in my name (and so in CN > field) [1]. So I found it's bug 6522064, and after a bit of hesitation, >..... (snip) > Please let me know your comments and suggestions. > Thanks, > Boris Du?ek From ahughes at redhat.com Fri Apr 9 14:53:15 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 15:53:15 +0100 Subject: [security-dev 01763]: Re: 6522064: Keystore aliases from MS CryptoAPI have bad encoding In-Reply-To: References: Message-ID: 2010/4/9 Boris Du?ek : > Hello, > > no one responded to my request for comments and possibly enlightment > below, so I guess the right thing to do is that I just implement my > proposed changes in a manner that I myself find "final" and submit the > patch to the bugzilla directly, where the rest of the discussion will > take place? > This list does tend to be very quiet. The best way to elicit some kind of response is to post a 'webrev' containing your changes: 1. Check out the tl forest of OpenJDK7: hg fclone http://hg.openjdk.java.net/jdk7/tl 2. Apply the patch to that tree and test it works 3. Use the webrev tool (http://blogs.sun.com/jcc/entry/webrev_script_updated) to generate a webrev. 4. Upload that somewhere. If you have issues with generating the webrev or posting it, then just post the output of hg diff as a patch to the list and I can turn it into a webrev for you easily enough. > Thanks, > Boris > > 2010/3/30 Boris Du?ek : >> Hello, >> this is my first time contributing to Java or Sun (Oracle), so please >> forgive me if I am doing something wrong. >> >> I am writing because I met an issue with JSignPdf app and my testing >> certificates, which contain non-ASCII characters in my name (and so in CN >> field) [1]. So I found it's bug 6522064, and after a bit of hesitation, >>..... (snip) >> Please let me know your comments and suggestions. >> Thanks, >> Boris Du?ek > Hope that helps, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Fri Apr 9 14:53:43 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 15:53:43 +0100 Subject: [security-dev 01764]: Re: 6522064: Keystore aliases from MS CryptoAPI have bad encoding In-Reply-To: References: Message-ID: 2010/4/9 Andrew John Hughes : > 2010/4/9 Boris Du?ek : >> Hello, >> >> no one responded to my request for comments and possibly enlightment >> below, so I guess the right thing to do is that I just implement my >> proposed changes in a manner that I myself find "final" and submit the >> patch to the bugzilla directly, where the rest of the discussion will >> take place? >> > > This list does tend to be very quiet. ?The best way to elicit some > kind of response is to post a 'webrev' containing your changes: > > 1. ?Check out the tl forest of OpenJDK7: hg fclone > http://hg.openjdk.java.net/jdk7/tl > 2. ?Apply the patch to that tree and test it works > 3. ?Use the webrev tool > (http://blogs.sun.com/jcc/entry/webrev_script_updated) to generate a > webrev. > 4. ?Upload that somewhere. > > If you have issues with generating the webrev or posting it, then just > post the output of hg diff as a patch to the list and I can turn it > into a webrev for you easily enough. > >> Thanks, >> Boris >> >> 2010/3/30 Boris Du?ek : >>> Hello, >>> this is my first time contributing to Java or Sun (Oracle), so please >>> forgive me if I am doing something wrong. >>> >>> I am writing because I met an issue with JSignPdf app and my testing >>> certificates, which contain non-ASCII characters in my name (and so in CN >>> field) [1]. So I found it's bug 6522064, and after a bit of hesitation, >>>..... (snip) >>> Please let me know your comments and suggestions. >>> Thanks, >>> Boris Du?ek >> > > Hope that helps, > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Also, including a reproducer testcase is a good idea so the effectiveness of the bug fix can be tested. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From boris.dusek at gmail.com Fri Apr 9 15:00:21 2010 From: boris.dusek at gmail.com (=?UTF-8?B?Qm9yaXMgRHXFoWVr?=) Date: Fri, 9 Apr 2010 17:00:21 +0200 Subject: [security-dev 01765]: Re: 6522064: Keystore aliases from MS CryptoAPI have bad encoding In-Reply-To: References: Message-ID: Thank you Andrew, I will try to post a webrev. Best regards, Boris >>> Hello, >>> >>> no one responded to my request for comments and possibly enlightment >> This list does tend to be very quiet. The best way to elicit some >> kind of response is to post a 'webrev' containing your changes: From bradford.wetmore at oracle.com Fri Apr 9 16:15:41 2010 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 09 Apr 2010 09:15:41 -0700 Subject: [security-dev 01766]: Re: 6522064: Keystore aliases from MS CryptoAPI have bad encoding In-Reply-To: References: Message-ID: <4BBF52AD.7030406@oracle.com> >> no one responded to my request for comments The person responsible for MSCAPI is currently on vacation. I think he's back next week, but not sure. Brad On 4/9/2010 7:53 AM, Andrew John Hughes wrote: > 2010/4/9 Boris Du?ek : >> Hello, >> >> no one responded to my request for comments and possibly enlightment >> below, so I guess the right thing to do is that I just implement my >> proposed changes in a manner that I myself find "final" and submit the >> patch to the bugzilla directly, where the rest of the discussion will >> take place? >> > > This list does tend to be very quiet. The best way to elicit some > kind of response is to post a 'webrev' containing your changes: > > 1. Check out the tl forest of OpenJDK7: hg fclone > http://hg.openjdk.java.net/jdk7/tl > 2. Apply the patch to that tree and test it works > 3. Use the webrev tool > (http://blogs.sun.com/jcc/entry/webrev_script_updated) to generate a > webrev. > 4. Upload that somewhere. > > If you have issues with generating the webrev or posting it, then just > post the output of hg diff as a patch to the list and I can turn it > into a webrev for you easily enough. > >> Thanks, >> Boris >> >> 2010/3/30 Boris Du?ek : >>> Hello, >>> this is my first time contributing to Java or Sun (Oracle), so please >>> forgive me if I am doing something wrong. >>> >>> I am writing because I met an issue with JSignPdf app and my testing >>> certificates, which contain non-ASCII characters in my name (and so in CN >>> field) [1]. So I found it's bug 6522064, and after a bit of hesitation, >>> ..... (snip) >>> Please let me know your comments and suggestions. >>> Thanks, >>> Boris Du?ek >> > > Hope that helps, From sean.mullan at sun.com Fri Apr 9 14:28:07 2010 From: sean.mullan at sun.com (sean.mullan at sun.com) Date: Fri, 09 Apr 2010 14:28:07 +0000 Subject: [security-dev 01767]: hg: jdk7/tl/jdk: 6909281: 6u19 b99(pit):Error loading first applet in browser session( both FF && IE, windows ): NPE is thrown Message-ID: <20100409142906.C3952444B1@hg.openjdk.java.net> Changeset: 710c4493902f Author: mullan Date: 2010-04-09 07:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/710c4493902f 6909281: 6u19 b99(pit):Error loading first applet in browser session( both FF && IE, windows ): NPE is thrown Summary: Fix for 6633872 causes NPE due to uninitialised ProtectionDomain class Reviewed-by: andrew ! src/share/classes/sun/misc/SharedSecrets.java From boris.dusek at gmail.com Fri Apr 9 16:19:49 2010 From: boris.dusek at gmail.com (=?UTF-8?B?Qm9yaXMgRHXFoWVr?=) Date: Fri, 9 Apr 2010 18:19:49 +0200 Subject: [security-dev 01768]: Re: 6522064: Keystore aliases from MS CryptoAPI have bad encoding In-Reply-To: <4BBF52AD.7030406@oracle.com> References: <4BBF52AD.7030406@oracle.com> Message-ID: >>> no one responded to my request for comments > > The person responsible for MSCAPI is currently on vacation. ?I think > he's back next week, but not sure. Well, I was thinking that might be one posibility :-) thanks for the info. Boris From bradford.wetmore at oracle.com Fri Apr 9 16:27:13 2010 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 09 Apr 2010 09:27:13 -0700 Subject: Subject lines in security-dev. In-Reply-To: <4B5F4D78.9000700@sun.com> References: <4B5F4D78.9000700@sun.com> Message-ID: <4BBF5561.5000806@oracle.com> I got zero responses on my previous email [1], so the prefix has been removed from the security-dev mailing list: Subject: [security-dev 01800]: The Real subject. Brad [1] http://mail.openjdk.java.net/pipermail/security-dev/2010-January/001562.html On 1/26/2010 12:15 PM, Brad Wetmore wrote: > > Looking for opinions as to whether the current subject line format of > the security-dev at o.j.n emails is useful: > > Subject: [security-dev 01800]: The Real subject. > > I note a lot of the client (e.g. sounds, swing) lists have just the list > name, and a lot of the server lists (e.g. tl, hotspot) don't have > either. security-dev is the only one doing both the list name and the > message number. It's not as useful as I originally thought when I > configured it, but I could be talked into it either way. > > If you have an opinion, especially for keeping it the same, let me know > privately, no need to clutter everyone's email. But I'm thinking I may > just remove the topic/number. If I see a clear/obvious preference for > keeping one or both, I'll certainly take that into consideration. > > Thanks, > Brad > security-dev admin > > > From jonathan.gibbons at sun.com Fri Apr 9 22:42:07 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 09 Apr 2010 22:42:07 +0000 Subject: hg: jdk7/tl/langtools: 6942649: add hidden option to identify location and version of javac classes Message-ID: <20100409224217.EEF8E444C2@hg.openjdk.java.net> Changeset: 96072ad00783 Author: jjg Date: 2010-04-09 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/96072ad00783 6942649: add hidden option to identify location and version of javac classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javac/T6942649.java From xuelei.fan at sun.com Sat Apr 10 01:21:42 2010 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Sat, 10 Apr 2010 01:21:42 +0000 Subject: hg: jdk7/tl/jdk: 6941936: Broken pipe error of test case DNSIdentities.java Message-ID: <20100410012232.76A4C444C5@hg.openjdk.java.net> Changeset: 89f4ec9e4b33 Author: xuelei Date: 2010-04-10 09:13 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/89f4ec9e4b33 6941936: Broken pipe error of test case DNSIdentities.java Reviewed-by: chegar ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java From ahughes at redhat.com Mon Apr 12 15:49:03 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 12 Apr 2010 16:49:03 +0100 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider Message-ID: Hi, I'm trying to debug an issue with the NSS provider crashing on a number of JTreg tests. See http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469 I found a couple of issues in doing so: * The stack trace is incomplete as a couple of exceptions are thrown using only the message without including the cause * The NSS wrapper can't handle a couple of newer NSS error codes This patch: http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch fixes both issues and extends: java.security.cert.CertificateParsingException: java.io.IOException: subject key, Could not create EC public key at sun.security.x509.X509CertInfo.(X509CertInfo.java:171) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) at sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:550) at sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:434) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:444) at ReadCertificates.readCertificates(ReadCertificates.java:51) at ReadCertificates.main(ReadCertificates.java:86) at PKCS11Test.premain(PKCS11Test.java:79) at PKCS11Test.testDefault(PKCS11Test.java:113) at PKCS11Test.main(PKCS11Test.java:86) at ReadCertificates.main(ReadCertificates.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595) at java.lang.Thread.run(Thread.java:636) Caused by: java.io.IOException: subject key, Could not create EC public key at sun.security.x509.X509Key.parse(X509Key.java:174) at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) ... 17 more with: Caused by: java.security.InvalidKeyException: Could not create EC public key at sun.security.x509.X509Key.buildX509Key(X509Key.java:227) at sun.security.x509.X509Key.parse(X509Key.java:170) ... 20 more Caused by: java.security.spec.InvalidKeySpecException: Could not create EC public key at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:154) at java.security.KeyFactory.generatePublic(KeyFactory.java:321) at sun.security.x509.X509Key.buildX509Key(X509Key.java:223) ... 21 more Caused by: java.security.InvalidKeyException: Could not create EC public key at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:117) at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:152) ... 23 more Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) at sun.security.pkcs11.P11ECKeyFactory.generatePublic(P11ECKeyFactory.java:229) at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:103) ... 24 more allowing the native NSS error to be seen. Ok to push to tl? If so, can I have a bug ID for this change? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From xueming.shen at sun.com Mon Apr 12 18:07:51 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Mon, 12 Apr 2010 18:07:51 +0000 Subject: hg: jdk7/tl/jdk: 6942707: nwe Big5.map for HKSCS2008 missed 5 codepoints Message-ID: <20100412180821.4F91D444F4@hg.openjdk.java.net> Changeset: 507cd94489e7 Author: sherman Date: 2010-04-12 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/507cd94489e7 6942707: nwe Big5.map for HKSCS2008 missed 5 codepoints Summary: updated the Big5.map table to add 5 entries Reviewed-by: okutsu - make/tools/CharsetMapping/Big5.c2b ! make/tools/CharsetMapping/Big5.map From yu-ching.peng at sun.com Mon Apr 12 23:03:03 2010 From: yu-ching.peng at sun.com (yu-ching.peng at sun.com) Date: Mon, 12 Apr 2010 23:03:03 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100412230342.80E38444F8@hg.openjdk.java.net> Changeset: 6b641c576e77 Author: valeriep Date: 2010-04-07 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6b641c576e77 6918573: sun.security.pkcs11.P11RSACipher.finalize() is a scalability blocker Summary: Removed the finalize() methods and use PhantomReference in Session to do auto clean up. Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/Session.java ! src/share/classes/sun/security/pkcs11/SessionManager.java Changeset: a45217204978 Author: valeriep Date: 2010-04-12 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a45217204978 Merge - make/tools/CharsetMapping/Big5.c2b From Weijun.Wang at Sun.COM Tue Apr 13 02:47:24 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Tue, 13 Apr 2010 10:47:24 +0800 Subject: CR 6939248/7 Created, P4 java/classes_secu Jarsigner can't extract Extended Key Usage from Timestamp Reply currectly In-Reply-To: <8463034.1271055879078.JavaMail.sbladm@swsblss3-new> References: <8463034.1271055879078.JavaMail.sbladm@swsblss3-new> Message-ID: <7B246239-52AA-437C-971A-05B86C2D30CF@Sun.COM> Hi Xuelei and Sean Please take a review on the fix for OpenJDK: http://cr.openjdk.java.net/~weijun/6939248/webrev.00 Note that I've added some check: 1. response cert null check 2. extension isCritical check About the test: 1. Since keytool can now generate extensions, binary keystore is changed to scripts and now moved from closed test to open 2. -J-Djava.security.egd=file:/dev/./urandom is added to jarsigner so that it does not hang on linux Thanks Max > *Synopsis*: Jarsigner can't extract Extended Key Usage from Timestamp Reply currectly > > *Change Request ID*: 6939248/7 > > === *Description* ============================================================ > PKCS #7 block includes a set of certificates and several signerinfos. To locate the certificate for a given signer, one should first look for a reference in the signerinfo, and then try to locate one in the certificates set. > > Currently, jarsigner, when validating certificate for a timestamping service, simply looks for a non-CA cert inside the certificate set. This is not correct. > > *** (#1 of 1): 2010-04-12 07:04:14 GMT+00:00 weijun.wang at sun.com From Xuelei.Fan at Sun.COM Tue Apr 13 03:13:54 2010 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Tue, 13 Apr 2010 11:13:54 +0800 Subject: CR 6939248/7 Created, P4 java/classes_secu Jarsigner can't extract Extended Key Usage from Timestamp Reply currectly In-Reply-To: <7B246239-52AA-437C-971A-05B86C2D30CF@Sun.COM> References: <8463034.1271055879078.JavaMail.sbladm@swsblss3-new> <7B246239-52AA-437C-971A-05B86C2D30CF@Sun.COM> Message-ID: <4BC3E172.5050102@Sun.COM> Looks fine to me. Xuelei On 4/13/2010 10:47 AM, Weijun Wang wrote: > Hi Xuelei and Sean > > Please take a review on the fix for OpenJDK: > > http://cr.openjdk.java.net/~weijun/6939248/webrev.00 > > Note that I've added some check: > > 1. response cert null check > 2. extension isCritical check > > About the test: > > 1. Since keytool can now generate extensions, binary keystore is changed to scripts and now moved from closed test to open > 2. -J-Djava.security.egd=file:/dev/./urandom is added to jarsigner so that it does not hang on linux > > Thanks > Max > >> *Synopsis*: Jarsigner can't extract Extended Key Usage from Timestamp Reply currectly >> >> *Change Request ID*: 6939248/7 >> >> === *Description* ============================================================ >> PKCS #7 block includes a set of certificates and several signerinfos. To locate the certificate for a given signer, one should first look for a reference in the signerinfo, and then try to locate one in the certificates set. >> >> Currently, jarsigner, when validating certificate for a timestamping service, simply looks for a non-CA cert inside the certificate set. This is not correct. >> >> *** (#1 of 1): 2010-04-12 07:04:14 GMT+00:00 weijun.wang at sun.com > From chris.hegarty at oracle.com Tue Apr 13 11:03:16 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 13 Apr 2010 11:03:16 +0000 Subject: hg: jdk7/tl/jdk: 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String Message-ID: <20100413110423.C693744528@hg.openjdk.java.net> Changeset: 1672f0212f02 Author: chegar Date: 2010-04-13 12:02 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1672f0212f02 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String Reviewed-by: alanb, michaelm, andrew ! src/share/classes/java/net/NetworkInterface.java From maurizio.cimadamore at sun.com Wed Apr 14 11:41:19 2010 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 14 Apr 2010 11:41:19 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100414114128.E2D2A4454C@hg.openjdk.java.net> Changeset: 396b117c1743 Author: mcimadamore Date: 2010-04-14 12:23 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/396b117c1743 6939618: Revert 'simple' diamond implementation Summary: backout changeset for 6840638 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/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java - test/tools/javac/generics/diamond/neg/Neg01.java - test/tools/javac/generics/diamond/neg/Neg01.out - test/tools/javac/generics/diamond/neg/Neg02.java - test/tools/javac/generics/diamond/neg/Neg02.out - test/tools/javac/generics/diamond/neg/Neg03.java - test/tools/javac/generics/diamond/neg/Neg03.out - test/tools/javac/generics/diamond/neg/Neg04.java - test/tools/javac/generics/diamond/neg/Neg04.out - test/tools/javac/generics/diamond/neg/Neg05.java - test/tools/javac/generics/diamond/neg/Neg05.out - test/tools/javac/generics/diamond/pos/Pos01.java - test/tools/javac/generics/diamond/pos/Pos02.java - test/tools/javac/generics/diamond/pos/Pos03.java - test/tools/javac/generics/diamond/pos/Pos04.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java Changeset: 9d9d08922405 Author: mcimadamore Date: 2010-04-14 12:31 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9d9d08922405 6939620: Switch to 'complex' diamond inference scheme Summary: Implement new inference scheme for diamond operator that takes into account type of actual arguments supplied to constructor Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/Resolve.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/6840059/T6840059.out + test/tools/javac/generics/diamond/neg/Neg01.java + test/tools/javac/generics/diamond/neg/Neg01.out + test/tools/javac/generics/diamond/neg/Neg02.java + test/tools/javac/generics/diamond/neg/Neg02.out + test/tools/javac/generics/diamond/neg/Neg03.java + test/tools/javac/generics/diamond/neg/Neg03.out + test/tools/javac/generics/diamond/neg/Neg04.java + test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/generics/diamond/neg/Neg05.java + test/tools/javac/generics/diamond/neg/Neg05.out + test/tools/javac/generics/diamond/neg/Neg06.java + test/tools/javac/generics/diamond/neg/Neg06.out + test/tools/javac/generics/diamond/neg/Neg07.java + test/tools/javac/generics/diamond/neg/Neg07.out + test/tools/javac/generics/diamond/neg/Neg08.java + test/tools/javac/generics/diamond/neg/Neg08.out + test/tools/javac/generics/diamond/neg/Neg09.java + test/tools/javac/generics/diamond/neg/Neg09.out + test/tools/javac/generics/diamond/neg/Neg10.java + test/tools/javac/generics/diamond/neg/Neg10.out + test/tools/javac/generics/diamond/neg/Neg11.java + test/tools/javac/generics/diamond/neg/Neg11.out + test/tools/javac/generics/diamond/pos/Pos01.java + test/tools/javac/generics/diamond/pos/Pos02.java + test/tools/javac/generics/diamond/pos/Pos03.java + test/tools/javac/generics/diamond/pos/Pos04.java + test/tools/javac/generics/diamond/pos/Pos05.java From bradford.wetmore at oracle.com Thu Apr 15 06:49:14 2010 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 14 Apr 2010 23:49:14 -0700 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider In-Reply-To: References: Message-ID: <4BC6B6EA.2090303@oracle.com> Valerie, did you want to look at this, or I can work with Andrew on getting this in. It's pretty straightforward. Brad On 4/12/2010 8:49 AM, Andrew John Hughes wrote: > Hi, > > I'm trying to debug an issue with the NSS provider crashing on a > number of JTreg tests. See > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469 > > I found a couple of issues in doing so: > > * The stack trace is incomplete as a couple of exceptions are thrown > using only the message without including the cause > * The NSS wrapper can't handle a couple of newer NSS error codes > > This patch: > > http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch > > fixes both issues and extends: > > java.security.cert.CertificateParsingException: java.io.IOException: subject > key, Could not create EC public key > at sun.security.x509.X509CertInfo.(X509CertInfo.java:171) > at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) > at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > at sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:550) > at sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:434) > at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:444) > at ReadCertificates.readCertificates(ReadCertificates.java:51) > at ReadCertificates.main(ReadCertificates.java:86) > at PKCS11Test.premain(PKCS11Test.java:79) > at PKCS11Test.testDefault(PKCS11Test.java:113) > at PKCS11Test.main(PKCS11Test.java:86) > at ReadCertificates.main(ReadCertificates.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595) > at java.lang.Thread.run(Thread.java:636) > Caused by: java.io.IOException: subject key, Could not create EC public key > at sun.security.x509.X509Key.parse(X509Key.java:174) > at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) > at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) > at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) > ... 17 more > > with: > > Caused by: java.security.InvalidKeyException: Could not create EC public key > at sun.security.x509.X509Key.buildX509Key(X509Key.java:227) > at sun.security.x509.X509Key.parse(X509Key.java:170) > ... 20 more > Caused by: java.security.spec.InvalidKeySpecException: Could not create EC > public key > at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:154) > at java.security.KeyFactory.generatePublic(KeyFactory.java:321) > at sun.security.x509.X509Key.buildX509Key(X509Key.java:223) > ... 21 more > Caused by: java.security.InvalidKeyException: Could not create EC public key > at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:117) > at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:152) > ... 23 more > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: > CKR_DOMAIN_PARAMS_INVALID > at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) > at sun.security.pkcs11.P11ECKeyFactory.generatePublic(P11ECKeyFactory.java:229) > at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:103) > ... 24 more > > allowing the native NSS error to be seen. > > Ok to push to tl? If so, can I have a bug ID for this change? > > Thanks, From chris.hegarty at oracle.com Thu Apr 15 09:05:23 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Apr 2010 10:05:23 +0100 Subject: Code Review 6943219: test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java fail in linux Message-ID: <4BC6D6D3.8010908@oracle.com> Hi Andrew, These tests have canned certs with 'localhost' as a subject alternative name in the client certificate. This fails client authentication on the accepted server socket if the platform returns anything other than 'localhost' for the remote address. This can happen on Linux which typically has an entry localhost.localdomain in the /etc/hosts file. The fix is to disable client hostname checking on the server side, since these tests were added specifically to verify the hostname checking on the client side. Note, this does not indicate a bug in the client hostname checking on the server side, just that the canned certs in this particular test does not fully support it. Webrev: http://cr.openjdk.java.net/~chegar/6943219/webrev.00/webrev/ -Chris. From Xuelei.Fan at Sun.COM Thu Apr 15 10:53:35 2010 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Thu, 15 Apr 2010 18:53:35 +0800 Subject: Code Review 6943219: test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java fail in linux In-Reply-To: <4BC6D6D3.8010908@oracle.com> References: <4BC6D6D3.8010908@oracle.com> Message-ID: <4BC6F02F.8070305@Sun.COM> Looks fine to me. Thanks, Andrew On 4/15/2010 5:05 PM, Chris Hegarty wrote: > Hi Andrew, > > These tests have canned certs with 'localhost' as a subject alternative > name in the client certificate. This fails client authentication on the > accepted server socket if the platform returns anything other than > 'localhost' for the remote address. This can happen on Linux which > typically has an entry localhost.localdomain in the /etc/hosts file. > > The fix is to disable client hostname checking on the server side, since > these tests were added specifically to verify the hostname checking on > the client side. Note, this does not indicate a bug in the client > hostname checking on the server side, just that the canned certs in this > particular test does not fully support it. > > Webrev: > http://cr.openjdk.java.net/~chegar/6943219/webrev.00/webrev/ > > -Chris. From ahughes at redhat.com Thu Apr 15 12:53:55 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 15 Apr 2010 13:53:55 +0100 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider In-Reply-To: <4BC6B6EA.2090303@oracle.com> References: <4BC6B6EA.2090303@oracle.com> Message-ID: On 15 April 2010 07:49, Bradford Wetmore wrote: > Valerie, did you want to look at this, or I can work with Andrew on > getting this in. ?It's pretty straightforward. > Just to clarify; I have push access so I just need approval and a bug ID to commit the change. > Brad > > > On 4/12/2010 8:49 AM, Andrew John Hughes wrote: >> Hi, >> >> I'm trying to debug an issue with the NSS provider crashing on a >> number of JTreg tests. ?See >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469 >> >> I found a couple of issues in doing so: >> >> * The stack trace is incomplete as a couple of exceptions are thrown >> using only the message without including the cause >> * The NSS wrapper can't handle a couple of newer NSS error codes >> >> This patch: >> >> http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch >> >> fixes both issues and extends: >> >> java.security.cert.CertificateParsingException: java.io.IOException: subject >> key, Could not create EC public key >> ? ? ? ? at sun.security.x509.X509CertInfo.(X509CertInfo.java:171) >> ? ? ? ? at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) >> ? ? ? ? at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) >> ? ? ? ? at sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:550) >> ? ? ? ? at sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:434) >> ? ? ? ? at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:444) >> ? ? ? ? at ReadCertificates.readCertificates(ReadCertificates.java:51) >> ? ? ? ? at ReadCertificates.main(ReadCertificates.java:86) >> ? ? ? ? at PKCS11Test.premain(PKCS11Test.java:79) >> ? ? ? ? at PKCS11Test.testDefault(PKCS11Test.java:113) >> ? ? ? ? at PKCS11Test.main(PKCS11Test.java:86) >> ? ? ? ? at ReadCertificates.main(ReadCertificates.java:57) >> ? ? ? ? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> ? ? ? ? at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> ? ? ? ? at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> ? ? ? ? at java.lang.reflect.Method.invoke(Method.java:616) >> ? ? ? ? at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595) >> ? ? ? ? at java.lang.Thread.run(Thread.java:636) >> Caused by: java.io.IOException: subject key, Could not create EC public key >> ? ? ? ? at sun.security.x509.X509Key.parse(X509Key.java:174) >> ? ? ? ? at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) >> ? ? ? ? at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) >> ? ? ? ? at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) >> ? ? ? ? ... 17 more >> >> with: >> >> Caused by: java.security.InvalidKeyException: Could not create EC public key >> ? ? ? ? at sun.security.x509.X509Key.buildX509Key(X509Key.java:227) >> ? ? ? ? at sun.security.x509.X509Key.parse(X509Key.java:170) >> ? ? ? ? ... 20 more >> Caused by: java.security.spec.InvalidKeySpecException: Could not create EC >> public key >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:154) >> ? ? ? ? at java.security.KeyFactory.generatePublic(KeyFactory.java:321) >> ? ? ? ? at sun.security.x509.X509Key.buildX509Key(X509Key.java:223) >> ? ? ? ? ... 21 more >> Caused by: java.security.InvalidKeyException: Could not create EC public key >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:117) >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:152) >> ? ? ? ? ... 23 more >> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: >> CKR_DOMAIN_PARAMS_INVALID >> ? ? ? ? at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.generatePublic(P11ECKeyFactory.java:229) >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:103) >> ? ? ? ? ... 24 more >> >> allowing the native NSS error to be seen. >> >> Ok to push to tl? If so, can I have a bug ID for this change? >> >> Thanks, > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From chris.hegarty at oracle.com Thu Apr 15 15:39:19 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 15 Apr 2010 15:39:19 +0000 Subject: hg: jdk7/tl/jdk: 6943219: test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java fail in linux Message-ID: <20100415154114.C888544575@hg.openjdk.java.net> Changeset: ed61accf772e Author: chegar Date: 2010-04-15 16:37 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ed61accf772e 6943219: test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java fail in linux Reviewed-by: andrew ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java From valerie.peng at oracle.com Thu Apr 15 19:01:49 2010 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 15 Apr 2010 12:01:49 -0700 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider In-Reply-To: <4BC6B6EA.2090303@oracle.com> References: <4BC6B6EA.2090303@oracle.com> Message-ID: <4BC7629D.2020900@oracle.com> I've looked at the changes and they look fine to me. If you can work w/ Andrew to get this in, e.g. bug id, integration, etc., that'd be good. Thanks, Valerie On 04/14/10 23:49, Bradford Wetmore wrote: > Valerie, did you want to look at this, or I can work with Andrew on > getting this in. It's pretty straightforward. > > Brad > > > On 4/12/2010 8:49 AM, Andrew John Hughes wrote: > >> Hi, >> >> I'm trying to debug an issue with the NSS provider crashing on a >> number of JTreg tests. See >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469 >> >> I found a couple of issues in doing so: >> >> * The stack trace is incomplete as a couple of exceptions are thrown >> using only the message without including the cause >> * The NSS wrapper can't handle a couple of newer NSS error codes >> >> This patch: >> >> http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch >> >> fixes both issues and extends: >> >> java.security.cert.CertificateParsingException: java.io.IOException: subject >> key, Could not create EC public key >> at sun.security.x509.X509CertInfo.(X509CertInfo.java:171) >> at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) >> at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) >> at sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:550) >> at sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:434) >> at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:444) >> at ReadCertificates.readCertificates(ReadCertificates.java:51) >> at ReadCertificates.main(ReadCertificates.java:86) >> at PKCS11Test.premain(PKCS11Test.java:79) >> at PKCS11Test.testDefault(PKCS11Test.java:113) >> at PKCS11Test.main(PKCS11Test.java:86) >> at ReadCertificates.main(ReadCertificates.java:57) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:616) >> at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595) >> at java.lang.Thread.run(Thread.java:636) >> Caused by: java.io.IOException: subject key, Could not create EC public key >> at sun.security.x509.X509Key.parse(X509Key.java:174) >> at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) >> at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) >> at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) >> ... 17 more >> >> with: >> >> Caused by: java.security.InvalidKeyException: Could not create EC public key >> at sun.security.x509.X509Key.buildX509Key(X509Key.java:227) >> at sun.security.x509.X509Key.parse(X509Key.java:170) >> ... 20 more >> Caused by: java.security.spec.InvalidKeySpecException: Could not create EC >> public key >> at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:154) >> at java.security.KeyFactory.generatePublic(KeyFactory.java:321) >> at sun.security.x509.X509Key.buildX509Key(X509Key.java:223) >> ... 21 more >> Caused by: java.security.InvalidKeyException: Could not create EC public key >> at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:117) >> at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:152) >> ... 23 more >> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: >> CKR_DOMAIN_PARAMS_INVALID >> at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) >> at sun.security.pkcs11.P11ECKeyFactory.generatePublic(P11ECKeyFactory.java:229) >> at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:103) >> ... 24 more >> >> allowing the native NSS error to be seen. >> >> Ok to push to tl? If so, can I have a bug ID for this change? >> >> Thanks, >> From bradford.wetmore at oracle.com Thu Apr 15 19:06:31 2010 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 15 Apr 2010 12:06:31 -0700 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider In-Reply-To: <4BC7629D.2020900@oracle.com> References: <4BC6B6EA.2090303@oracle.com> <4BC7629D.2020900@oracle.com> Message-ID: <4BC763B7.7030809@oracle.com> Sure. I'm finally coming up for air before I dive back into some longer term projects, so I can take care of this. Brad On 4/15/2010 12:01 PM, Valerie (Yu-Ching) Peng wrote: > > I've looked at the changes and they look fine to me. If you can work w/ > Andrew to get this in, e.g. bug id, integration, etc., that'd be good. > Thanks, > Valerie > > On 04/14/10 23:49, Bradford Wetmore wrote: >> Valerie, did you want to look at this, or I can work with Andrew on >> getting this in. It's pretty straightforward. >> >> Brad >> >> >> On 4/12/2010 8:49 AM, Andrew John Hughes wrote: >> >>> Hi, >>> >>> I'm trying to debug an issue with the NSS provider crashing on a >>> number of JTreg tests. See >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469 >>> >>> I found a couple of issues in doing so: >>> >>> * The stack trace is incomplete as a couple of exceptions are thrown >>> using only the message without including the cause >>> * The NSS wrapper can't handle a couple of newer NSS error codes >>> >>> This patch: >>> >>> http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch >>> >>> fixes both issues and extends: >>> >>> java.security.cert.CertificateParsingException: java.io.IOException: >>> subject >>> key, Could not create EC public key >>> at sun.security.x509.X509CertInfo.(X509CertInfo.java:171) >>> at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) >>> at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) >>> at >>> sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:550) >>> >>> at >>> sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:434) >>> >>> at >>> java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:444) >>> >>> at ReadCertificates.readCertificates(ReadCertificates.java:51) >>> at ReadCertificates.main(ReadCertificates.java:86) >>> at PKCS11Test.premain(PKCS11Test.java:79) >>> at PKCS11Test.testDefault(PKCS11Test.java:113) >>> at PKCS11Test.main(PKCS11Test.java:86) >>> at ReadCertificates.main(ReadCertificates.java:57) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:616) >>> at >>> com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595) >>> >>> at java.lang.Thread.run(Thread.java:636) >>> Caused by: java.io.IOException: subject key, Could not create EC >>> public key >>> at sun.security.x509.X509Key.parse(X509Key.java:174) >>> at >>> sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) >>> at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) >>> at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) >>> ... 17 more >>> >>> with: >>> >>> Caused by: java.security.InvalidKeyException: Could not create EC >>> public key >>> at sun.security.x509.X509Key.buildX509Key(X509Key.java:227) >>> at sun.security.x509.X509Key.parse(X509Key.java:170) >>> ... 20 more >>> Caused by: java.security.spec.InvalidKeySpecException: Could not >>> create EC >>> public key >>> at >>> sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:154) >>> >>> at java.security.KeyFactory.generatePublic(KeyFactory.java:321) >>> at sun.security.x509.X509Key.buildX509Key(X509Key.java:223) >>> ... 21 more >>> Caused by: java.security.InvalidKeyException: Could not create EC >>> public key >>> at >>> sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:117) >>> >>> at >>> sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:152) >>> >>> ... 23 more >>> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: >>> CKR_DOMAIN_PARAMS_INVALID >>> at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native >>> Method) >>> at >>> sun.security.pkcs11.P11ECKeyFactory.generatePublic(P11ECKeyFactory.java:229) >>> >>> at >>> sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:103) >>> >>> ... 24 more >>> >>> allowing the native NSS error to be seen. >>> >>> Ok to push to tl? If so, can I have a bug ID for this change? >>> >>> Thanks, >>> > From martinrb at google.com Thu Apr 15 22:34:22 2010 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 Apr 2010 15:34:22 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater Message-ID: Hi java.util.concurrent security team, People are using Atomic field updaters to update fields in classes in other classloaders. Toby writes: We received a bug report for App Engine that AtomicLongFieldUpdater (and its sibling) were failing with RuntimePermission accessDeclaredMembers. Looking at the code, it appears that it is a bug for that permission to be required. AtomicLongFieldUpdater (and sibling) are already performing subsequent access checks that ensure that the caller isn't accessing a field it shouldn't be. I've attached a patch which moves the field lookups into doPrivileged blocks. ... There was a bug was filed by ehcache folks. I could follow up with them to see if I could get some pointers to actual usage, if you're looking for motivational reasoning. --- http://code.google.com/p/googleappengine/issues/detail?id=2769 GAE Bug Submitter writes: AtomicLongFieldUpdater is broken in the production sandbox. The simple test application that I wrote (atomically increments and prints a volatile long on each get request) works perfectly in the development environment. In production creating the field updater fails with an AccessControlException when the internal CASUpdater tries to do reflection (on a user class) in order to get a reference to the volatile field. I've attached the test app which works perfectly in development but fails in production. This issue is linked to an associated Ehcache issue: https://jira.terracotta.org/jira/browse/EHC-617 I have a modified experimental version of Toby's patch against openjdk7 here: http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/ I'm afraid to touch this security stuff myself, especially where we might be loosening permissions, but in principle I agree with Toby. (Even though atomic field updaters were designed to be used within a module (whatever that is)) The doPrivileged should not be too costly, as it's only performed at updater creation time. Martin From bradford.wetmore at oracle.com Thu Apr 15 23:06:32 2010 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 15 Apr 2010 16:06:32 -0700 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider In-Reply-To: References: Message-ID: <4BC79BF8.5060909@oracle.com> Hi Andrew, I couldn't tell for sure if this was for OpenJDK 7 or OpenJDK 6. I'm assuming the former? Looks good. I checked for any remaining missing CKR_* values in the PKCS11 spec version 2.20, this covers all the missing values. I've filed: 6944361: Missing CKR_ values in PKCS11Exception Our reviewer names would be wetmore, valeriep. > http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch Specifying just the top level of the webrev is preferred. Thanks! Brad On 4/12/2010 8:49 AM, Andrew John Hughes wrote: > Hi, > > I'm trying to debug an issue with the NSS provider crashing on a > number of JTreg tests. See > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469 > > I found a couple of issues in doing so: > > * The stack trace is incomplete as a couple of exceptions are thrown > using only the message without including the cause > * The NSS wrapper can't handle a couple of newer NSS error codes > > This patch: > > http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch > > fixes both issues and extends: > > java.security.cert.CertificateParsingException: java.io.IOException: subject > key, Could not create EC public key > at sun.security.x509.X509CertInfo.(X509CertInfo.java:171) > at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) > at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > at sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:550) > at sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:434) > at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:444) > at ReadCertificates.readCertificates(ReadCertificates.java:51) > at ReadCertificates.main(ReadCertificates.java:86) > at PKCS11Test.premain(PKCS11Test.java:79) > at PKCS11Test.testDefault(PKCS11Test.java:113) > at PKCS11Test.main(PKCS11Test.java:86) > at ReadCertificates.main(ReadCertificates.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595) > at java.lang.Thread.run(Thread.java:636) > Caused by: java.io.IOException: subject key, Could not create EC public key > at sun.security.x509.X509Key.parse(X509Key.java:174) > at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) > at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) > at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) > ... 17 more > > with: > > Caused by: java.security.InvalidKeyException: Could not create EC public key > at sun.security.x509.X509Key.buildX509Key(X509Key.java:227) > at sun.security.x509.X509Key.parse(X509Key.java:170) > ... 20 more > Caused by: java.security.spec.InvalidKeySpecException: Could not create EC > public key > at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:154) > at java.security.KeyFactory.generatePublic(KeyFactory.java:321) > at sun.security.x509.X509Key.buildX509Key(X509Key.java:223) > ... 21 more > Caused by: java.security.InvalidKeyException: Could not create EC public key > at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:117) > at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:152) > ... 23 more > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: > CKR_DOMAIN_PARAMS_INVALID > at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) > at sun.security.pkcs11.P11ECKeyFactory.generatePublic(P11ECKeyFactory.java:229) > at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:103) > ... 24 more > > allowing the native NSS error to be seen. > > Ok to push to tl? If so, can I have a bug ID for this change? > > Thanks, From xueming.shen at oracle.com Fri Apr 16 00:03:07 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 16 Apr 2010 00:03:07 +0000 Subject: hg: jdk7/tl/jdk: 6931676: TEST_BUG: wrong value for bugid in comments Message-ID: <20100416000326.04CFC44583@hg.openjdk.java.net> Changeset: c70d4266d474 Author: sherman Date: 2010-04-15 17:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c70d4266d474 6931676: TEST_BUG: wrong value for bugid in comments Summary: update to the correct bugid Reviewed-by: martin ! test/java/util/regex/RegExTest.java From martinrb at google.com Fri Apr 16 01:38:16 2010 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 Apr 2010 18:38:16 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BC7B41F.5000104@oracle.com> References: <4BC7B41F.5000104@oracle.com> Message-ID: On Thu, Apr 15, 2010 at 17:49, David Holmes wrote: > Hi Martin, > > If this proceeds I think you need to include AtomicReferenceFieldUpdater in > this as well. Agreed. I may have created some confusion because the test in my webrev did not actually demonstrate the problem. I have since fixed that. http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/test/java/util/concurrent/atomic/AccessControl.java.html The problem happens even for well-behaved classes that only use atomic updaters to update their own fields. Now, they could work around the problem by creating their atomic updater inside a doPrivileged, but probably we intend for them not to have to do that. Martin > But this is not a clear cut issue (security never is!). > > If I understand the test program correctly the problem arises when the > target object's class was loaded by a different class-loader to the class > doing the AtomicXXXFieldUpdater creation. This seems reasonable as > getDeclaredField states: > > ? ?SecurityException - If a security manager, s, is present and any of the > following conditions is met: > ? ? ? ?* invocation of s.checkMemberAccess(this, Member.DECLARED) denies > access to the declared field > ? ? ? ?* the caller's class loader is not the same as or an ancestor of the > class loader for the current class and invocation of s.checkPackageAccess() > denies access to the package of this class > > So here we would not have package access. What puzzles me is then why our > following explicit checks pass: > > ?sun.reflect.misc.ReflectUtil.ensureMemberAccess( > ? ? ? ? ? ? ? ? ?caller, tclass, null, modifiers); > ?sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); > > It seems inconsistent that getDeclaredField's internal checks say you don't > have permission to access this field, while what should amount to the same > checks via ReflectUtil say you do. The question is: which check is wrong? > > David > ----- > > > Martin Buchholz said the following on 04/16/10 08:34: >> >> Hi java.util.concurrent security team, >> >> People are using Atomic field updaters to update fields in classes in >> other classloaders. >> >> Toby writes: >> >> We received a bug report for App Engine that AtomicLongFieldUpdater >> (and its sibling) were failing with RuntimePermission >> accessDeclaredMembers. Looking at the code, it appears that it is a >> bug for that permission to be required. AtomicLongFieldUpdater (and >> sibling) are already performing subsequent access checks that ensure >> that the caller isn't accessing a field it shouldn't be. I've attached >> a patch which moves the field lookups into doPrivileged blocks. >> >> ... >> >> There was a bug was filed by ehcache folks. I could follow up with >> them to see if I could get some pointers to actual usage, if you're >> looking for motivational reasoning. >> >> --- >> >> http://code.google.com/p/googleappengine/issues/detail?id=2769 >> >> GAE Bug Submitter writes: >> >> AtomicLongFieldUpdater is broken in the production sandbox. >> >> The simple test application that I wrote (atomically increments and prints >> a volatile long on each get request) works perfectly in the development >> environment. ?In production creating the field updater fails with an >> AccessControlException when the internal CASUpdater tries to do reflection >> (on a user class) in order to get a reference to the volatile field. >> >> I've attached the test app which works perfectly in development but fails >> in production. >> >> This issue is linked to an associated Ehcache issue: >> >> https://jira.terracotta.org/jira/browse/EHC-617 >> >> I have a modified experimental version of Toby's patch against openjdk7 >> here: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/ >> >> I'm afraid to touch this security stuff myself, >> especially where we might be loosening permissions, >> but in principle I agree with Toby. >> (Even though atomic field updaters were designed to be >> used within a module (whatever that is)) >> >> The doPrivileged should not be too costly, as it's >> only performed at updater creation time. >> >> Martin > From weijun.wang at sun.com Fri Apr 16 02:06:34 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Fri, 16 Apr 2010 02:06:34 +0000 Subject: hg: jdk7/tl/jdk: 6937978: let keytool -gencert generate the chain Message-ID: <20100416020653.5534E44589@hg.openjdk.java.net> Changeset: db4fd2fdf196 Author: weijun Date: 2010-04-16 10:06 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db4fd2fdf196 6937978: let keytool -gencert generate the chain Reviewed-by: mullan ! src/share/classes/sun/security/tools/KeyTool.java ! test/sun/security/tools/keytool/selfissued.sh From weijun.wang at sun.com Fri Apr 16 02:14:57 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Fri, 16 Apr 2010 02:14:57 +0000 Subject: hg: jdk7/tl/jdk: 6939248: Jarsigner can't extract Extended Key Usage from Timestamp Reply correctly Message-ID: <20100416021516.29A684458A@hg.openjdk.java.net> Changeset: 0d989dc383d3 Author: weijun Date: 2010-04-16 10:13 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d989dc383d3 6939248: Jarsigner can't extract Extended Key Usage from Timestamp Reply correctly Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/TimestampedSigner.java + test/sun/security/tools/jarsigner/TimestampCheck.java + test/sun/security/tools/jarsigner/ts.sh From David.Holmes at oracle.com Fri Apr 16 00:49:35 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2010 10:49:35 +1000 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: References: Message-ID: <4BC7B41F.5000104@oracle.com> Hi Martin, If this proceeds I think you need to include AtomicReferenceFieldUpdater in this as well. But this is not a clear cut issue (security never is!). If I understand the test program correctly the problem arises when the target object's class was loaded by a different class-loader to the class doing the AtomicXXXFieldUpdater creation. This seems reasonable as getDeclaredField states: SecurityException - If a security manager, s, is present and any of the following conditions is met: * invocation of s.checkMemberAccess(this, Member.DECLARED) denies access to the declared field * the caller's class loader is not the same as or an ancestor of the class loader for the current class and invocation of s.checkPackageAccess() denies access to the package of this class So here we would not have package access. What puzzles me is then why our following explicit checks pass: sun.reflect.misc.ReflectUtil.ensureMemberAccess( caller, tclass, null, modifiers); sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); It seems inconsistent that getDeclaredField's internal checks say you don't have permission to access this field, while what should amount to the same checks via ReflectUtil say you do. The question is: which check is wrong? David ----- Martin Buchholz said the following on 04/16/10 08:34: > Hi java.util.concurrent security team, > > People are using Atomic field updaters to update fields in classes in > other classloaders. > > Toby writes: > > We received a bug report for App Engine that AtomicLongFieldUpdater > (and its sibling) were failing with RuntimePermission > accessDeclaredMembers. Looking at the code, it appears that it is a > bug for that permission to be required. AtomicLongFieldUpdater (and > sibling) are already performing subsequent access checks that ensure > that the caller isn't accessing a field it shouldn't be. I've attached > a patch which moves the field lookups into doPrivileged blocks. > > ... > > There was a bug was filed by ehcache folks. I could follow up with > them to see if I could get some pointers to actual usage, if you're > looking for motivational reasoning. > > --- > > http://code.google.com/p/googleappengine/issues/detail?id=2769 > > GAE Bug Submitter writes: > > AtomicLongFieldUpdater is broken in the production sandbox. > > The simple test application that I wrote (atomically increments and prints > a volatile long on each get request) works perfectly in the development > environment. In production creating the field updater fails with an > AccessControlException when the internal CASUpdater tries to do reflection > (on a user class) in order to get a reference to the volatile field. > > I've attached the test app which works perfectly in development but fails > in production. > > This issue is linked to an associated Ehcache issue: > > https://jira.terracotta.org/jira/browse/EHC-617 > > I have a modified experimental version of Toby's patch against openjdk7 here: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/ > > I'm afraid to touch this security stuff myself, > especially where we might be loosening permissions, > but in principle I agree with Toby. > (Even though atomic field updaters were designed to be > used within a module (whatever that is)) > > The doPrivileged should not be too costly, as it's > only performed at updater creation time. > > Martin From David.Holmes at oracle.com Fri Apr 16 02:04:30 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2010 12:04:30 +1000 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: References: <4BC7B41F.5000104@oracle.com> Message-ID: <4BC7C5AE.206@oracle.com> Martin Buchholz said the following on 04/16/10 11:38: > On Thu, Apr 15, 2010 at 17:49, David Holmes wrote: >> If this proceeds I think you need to include AtomicReferenceFieldUpdater in >> this as well. > > Agreed. > > I may have created some confusion because the test in my webrev > did not actually demonstrate the problem. > I have since fixed that. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/test/java/util/concurrent/atomic/AccessControl.java.html Aside: you forgot to call pass(). > The problem happens even for well-behaved classes that only > use atomic updaters to update their own fields. I don't think installing a security manager that permits nothing and then getting a SecurityException is a good indicator of a problem. > Now, they > could work around the problem by creating their atomic updater > inside a doPrivileged, but probably we intend for them not to > have to do that. That won't work. The doPrivileged doesn't give them any additional permissions in their code, so it has no affect. doPrivileged is only useful for bootstrap classes to have operations checked using the bootstrap class's permissions rather than the application class (that's a loose statement but suffices). To answer my own question I think the ReflectUtils checks act the same way that getDeclaredField() inside a doPrivileged would act. To that end perhaps this suggested change is "correct". Further it seems to me that the real security check needs to be done when the updater is applied, not when it is created. But I can't help but wonder what purpose this security check is serving, and whether circumventing it is the right thing to do. But I'll let the security folk chime in on that. Thanks, David > > Martin > >> But this is not a clear cut issue (security never is!). >> >> If I understand the test program correctly the problem arises when the >> target object's class was loaded by a different class-loader to the class >> doing the AtomicXXXFieldUpdater creation. This seems reasonable as >> getDeclaredField states: >> >> SecurityException - If a security manager, s, is present and any of the >> following conditions is met: >> * invocation of s.checkMemberAccess(this, Member.DECLARED) denies >> access to the declared field >> * the caller's class loader is not the same as or an ancestor of the >> class loader for the current class and invocation of s.checkPackageAccess() >> denies access to the package of this class >> >> So here we would not have package access. What puzzles me is then why our >> following explicit checks pass: >> >> sun.reflect.misc.ReflectUtil.ensureMemberAccess( >> caller, tclass, null, modifiers); >> sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); >> >> It seems inconsistent that getDeclaredField's internal checks say you don't >> have permission to access this field, while what should amount to the same >> checks via ReflectUtil say you do. The question is: which check is wrong? >> >> David >> ----- >> >> >> Martin Buchholz said the following on 04/16/10 08:34: >>> Hi java.util.concurrent security team, >>> >>> People are using Atomic field updaters to update fields in classes in >>> other classloaders. >>> >>> Toby writes: >>> >>> We received a bug report for App Engine that AtomicLongFieldUpdater >>> (and its sibling) were failing with RuntimePermission >>> accessDeclaredMembers. Looking at the code, it appears that it is a >>> bug for that permission to be required. AtomicLongFieldUpdater (and >>> sibling) are already performing subsequent access checks that ensure >>> that the caller isn't accessing a field it shouldn't be. I've attached >>> a patch which moves the field lookups into doPrivileged blocks. >>> >>> ... >>> >>> There was a bug was filed by ehcache folks. I could follow up with >>> them to see if I could get some pointers to actual usage, if you're >>> looking for motivational reasoning. >>> >>> --- >>> >>> http://code.google.com/p/googleappengine/issues/detail?id=2769 >>> >>> GAE Bug Submitter writes: >>> >>> AtomicLongFieldUpdater is broken in the production sandbox. >>> >>> The simple test application that I wrote (atomically increments and prints >>> a volatile long on each get request) works perfectly in the development >>> environment. In production creating the field updater fails with an >>> AccessControlException when the internal CASUpdater tries to do reflection >>> (on a user class) in order to get a reference to the volatile field. >>> >>> I've attached the test app which works perfectly in development but fails >>> in production. >>> >>> This issue is linked to an associated Ehcache issue: >>> >>> https://jira.terracotta.org/jira/browse/EHC-617 >>> >>> I have a modified experimental version of Toby's patch against openjdk7 >>> here: >>> >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/ >>> >>> I'm afraid to touch this security stuff myself, >>> especially where we might be loosening permissions, >>> but in principle I agree with Toby. >>> (Even though atomic field updaters were designed to be >>> used within a module (whatever that is)) >>> >>> The doPrivileged should not be too costly, as it's >>> only performed at updater creation time. >>> >>> Martin From Weijun.Wang at Sun.COM Fri Apr 16 03:12:00 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Fri, 16 Apr 2010 11:12:00 +0800 Subject: CR 6911951 Updated, weijun.wang now responsible engineer, P4 java/classes_secu NTLM should be a supported Java SASL mechanism In-Reply-To: <11045826.1262579400345.JavaMail.sbladm@swsblss3-new> References: <11045826.1262579400345.JavaMail.sbladm@swsblss3-new> Message-ID: Vinnie Please take a review on this webrev: cr.openjdk.java.net/~weijun/6911951/webrev.00/ I've updated the spec a little by making NTLMv2 as the default version. It has been supported for a long time and now default with Windows 7 and Server 2008 R2. Networking guys, are you OK with the rewrite of NTLMAuthentication? Thanks Max On Jan 4, 2010, at 12:30 PM, Weijun.Wang at Sun.COM wrote: > > *Change Request ID*: 6911951 > > *Synopsis*: NTLM should be a supported Java SASL mechanism > > === *Description* ============================================================ > The NTLM support currently available for HTTP authentication should be generalized > and made available as a Java SASL mechanism for use with other protocols. From martinrb at google.com Fri Apr 16 06:58:52 2010 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 Apr 2010 23:58:52 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BC7C5AE.206@oracle.com> References: <4BC7B41F.5000104@oracle.com> <4BC7C5AE.206@oracle.com> Message-ID: On Thu, Apr 15, 2010 at 19:04, David Holmes wrote: > Martin Buchholz said the following on 04/16/10 11:38: >> >> On Thu, Apr 15, 2010 at 17:49, David Holmes >> wrote: >>> >>> If this proceeds I think you need to include AtomicReferenceFieldUpdater >>> in >>> this as well. >> >> Agreed. >> >> I may have created some confusion because the test in my webrev >> did not actually demonstrate the problem. >> I have since fixed that. >> >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/test/java/util/concurrent/atomic/AccessControl.java.html > > Aside: you forgot to call pass(). Not strictly necessary, since the test fails if and only if it throws. >> The problem happens even for well-behaved classes that only >> use atomic updaters to update their own fields. > > I don't think installing a security manager that permits nothing and then > getting a SecurityException is a good indicator of a problem. > >> Now, they >> could work around the problem by creating their atomic updater >> inside a doPrivileged, but probably we intend for them not to >> have to do that. > > That won't work. The doPrivileged doesn't give them any additional > permissions in their code, so it has no affect. That's not my understanding. doPrivileged is useful whenever you want to perform an operation with permissions checked only on the current stack frame, and not on any other code executing up the stack. Martin doPrivileged is only useful > for bootstrap classes to have operations checked using the bootstrap class's > permissions rather than the application class (that's a loose statement but > suffices). > > To answer my own question I think the ReflectUtils checks act the same way > that getDeclaredField() inside a doPrivileged would act. To that end perhaps > this suggested change is "correct". Further it seems to me that the real > security check needs to be done when the updater is applied, not when it is > created. > > But I can't help but wonder what purpose this security check is serving, and > whether circumventing it is the right thing to do. But I'll let the security > folk chime in on that. > > Thanks, > David From David.Holmes at oracle.com Fri Apr 16 07:23:42 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2010 17:23:42 +1000 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: References: <4BC7B41F.5000104@oracle.com> <4BC7C5AE.206@oracle.com> Message-ID: <4BC8107E.1050801@oracle.com> Martin Buchholz said the following on 04/16/10 16:58: > On Thu, Apr 15, 2010 at 19:04, David Holmes wrote: >> Aside: you forgot to call pass(). > > Not strictly necessary, since the test fails if and only if it throws. Ok but it looks odd to print "pass 0 fail 0" ;-) >>> Now, they >>> could work around the problem by creating their atomic updater >>> inside a doPrivileged, but probably we intend for them not to >>> have to do that. >> That won't work. The doPrivileged doesn't give them any additional >> permissions in their code, so it has no affect. > > That's not my understanding. doPrivileged is useful whenever you > want to perform an operation with permissions checked only on the > current stack frame, and not on any other code executing up the stack. To be specific it will depend on the exact call stack. In general you'll get the least permissions based on your stack. So if application code with no permissions calls library code with permissions, the doPrivileged in the library code says "only look at my permissions" - and so the call can work. But if the application code with no permissions calls doPrivileged then it still has no permissions. A doPrivileged by the application code will only have an effect if the application code has the necessary permissions but there is a frame with fewer permissions further up the stack. Cheers, David > Martin > > doPrivileged is only useful >> for bootstrap classes to have operations checked using the bootstrap class's >> permissions rather than the application class (that's a loose statement but >> suffices). >> >> To answer my own question I think the ReflectUtils checks act the same way >> that getDeclaredField() inside a doPrivileged would act. To that end perhaps >> this suggested change is "correct". Further it seems to me that the real >> security check needs to be done when the updater is applied, not when it is >> created. >> >> But I can't help but wonder what purpose this security check is serving, and >> whether circumventing it is the right thing to do. But I'll let the security >> folk chime in on that. >> >> Thanks, >> David From ahughes at redhat.com Fri Apr 16 09:14:11 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 16 Apr 2010 09:14:11 +0000 Subject: hg: jdk7/tl/jdk: 6944361: Missing CKR_ values in PKCS11Exception Message-ID: <20100416091430.498054459C@hg.openjdk.java.net> Changeset: c444651077d2 Author: andrew Date: 2010-04-16 09:54 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c444651077d2 6944361: Missing CKR_ values in PKCS11Exception Summary: Allow native NSS errors to be observed and correctly reported Reviewed-by: wetmore, valeriep ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/x509/X509Key.java From ahughes at redhat.com Fri Apr 16 09:24:56 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 16 Apr 2010 10:24:56 +0100 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider In-Reply-To: <4BC79BF8.5060909@oracle.com> References: <4BC79BF8.5060909@oracle.com> Message-ID: On 16 April 2010 00:06, Bradford Wetmore wrote: > Hi Andrew, > > I couldn't tell for sure if this was for OpenJDK 7 or OpenJDK 6. ?I'm > assuming the former? > You're correct. I should have made it clearer in the initial e-mail, though I did ask if it was ok to push it to tl which is 7 only. The patch does apply to both, so I'll ask Joe Darcy about backporting it once it's in 7. > Looks good. ?I checked for any remaining missing CKR_* values in the > PKCS11 spec version 2.20, this covers all the missing values. > Thanks. These are all the values used by the current version of NSS (3.12.3 IIRC). > I've filed: > > 6944361: Missing CKR_ values in PKCS11Exception > > Our reviewer names would be wetmore, valeriep. > Thanks. Pushed: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c444651077d2 >> http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch > > Specifying just the top level of the webrev is preferred. > Whoops! Sorry, I usually do post the right URL. Must have copied the wrong one. > Thanks! > > Brad > > > On 4/12/2010 8:49 AM, Andrew John Hughes wrote: >> Hi, >> >> I'm trying to debug an issue with the NSS provider crashing on a >> number of JTreg tests. ?See >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469 >> >> I found a couple of issues in doing so: >> >> * The stack trace is incomplete as a couple of exceptions are thrown >> using only the message without including the cause >> * The NSS wrapper can't handle a couple of newer NSS error codes >> >> This patch: >> >> http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch >> >> fixes both issues and extends: >> >> java.security.cert.CertificateParsingException: java.io.IOException: subject >> key, Could not create EC public key >> ? ? ? ? at sun.security.x509.X509CertInfo.(X509CertInfo.java:171) >> ? ? ? ? at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) >> ? ? ? ? at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) >> ? ? ? ? at sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:550) >> ? ? ? ? at sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:434) >> ? ? ? ? at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:444) >> ? ? ? ? at ReadCertificates.readCertificates(ReadCertificates.java:51) >> ? ? ? ? at ReadCertificates.main(ReadCertificates.java:86) >> ? ? ? ? at PKCS11Test.premain(PKCS11Test.java:79) >> ? ? ? ? at PKCS11Test.testDefault(PKCS11Test.java:113) >> ? ? ? ? at PKCS11Test.main(PKCS11Test.java:86) >> ? ? ? ? at ReadCertificates.main(ReadCertificates.java:57) >> ? ? ? ? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> ? ? ? ? at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> ? ? ? ? at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> ? ? ? ? at java.lang.reflect.Method.invoke(Method.java:616) >> ? ? ? ? at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595) >> ? ? ? ? at java.lang.Thread.run(Thread.java:636) >> Caused by: java.io.IOException: subject key, Could not create EC public key >> ? ? ? ? at sun.security.x509.X509Key.parse(X509Key.java:174) >> ? ? ? ? at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) >> ? ? ? ? at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) >> ? ? ? ? at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) >> ? ? ? ? ... 17 more >> >> with: >> >> Caused by: java.security.InvalidKeyException: Could not create EC public key >> ? ? ? ? at sun.security.x509.X509Key.buildX509Key(X509Key.java:227) >> ? ? ? ? at sun.security.x509.X509Key.parse(X509Key.java:170) >> ? ? ? ? ... 20 more >> Caused by: java.security.spec.InvalidKeySpecException: Could not create EC >> public key >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:154) >> ? ? ? ? at java.security.KeyFactory.generatePublic(KeyFactory.java:321) >> ? ? ? ? at sun.security.x509.X509Key.buildX509Key(X509Key.java:223) >> ? ? ? ? ... 21 more >> Caused by: java.security.InvalidKeyException: Could not create EC public key >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:117) >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(P11ECKeyFactory.java:152) >> ? ? ? ? ... 23 more >> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: >> CKR_DOMAIN_PARAMS_INVALID >> ? ? ? ? at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.generatePublic(P11ECKeyFactory.java:229) >> ? ? ? ? at sun.security.pkcs11.P11ECKeyFactory.implTranslatePublicKey(P11ECKeyFactory.java:103) >> ? ? ? ? ... 24 more >> >> allowing the native NSS error to be seen. >> >> Ok to push to tl? If so, can I have a bug ID for this change? >> >> Thanks, > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From David.Holmes at oracle.com Fri Apr 16 12:50:11 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2010 22:50:11 +1000 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BC84D74.5070901@cs.oswego.edu> References: <4BC84D74.5070901@cs.oswego.edu> Message-ID: <4BC85D03.7030909@oracle.com> Hi Doug, Doug Lea said the following on 04/16/10 21:43: > On 04/15/10 18:34, Martin Buchholz wrote: > >> People are using Atomic field updaters to update fields in classes in >> other classloaders. >> > > I think the policy on this awaits interpretation by Jeff > or other members of security team. FWIW, my take is that > if users know that they may cross class loaders, then they > should wrap these in doPrivileged anyway. As in ... I'm coming around to agreeing with the proposed fix. My take is that the real security check should take place at the time the field is set: field_x_updater.set(obj, val); At this point the calling code must have the necessary permissions to set field x of the given obj of type T. And I believe we do indeed check this. When the AtomicXXXXFieldUpdater constructor binds itself to the Field object for T.x that's an optimization. There's no reason we couldn't do this on each call to set() - other than it would perform terribly. So in that sense the security checks that take place at construction are incidental** and so we should be as permissive as we can make them _provided_ that the actual set() call will make the necessary permission checks. ** This particular check is also incidental because we happen to use a public reflection method to get the Field object. We could just as easily have used a magic VM hook. David ----- > >>>>>> Now, they could work around the problem by creating their atomic >>>>>> updater inside a doPrivileged, but probably we intend for them not to >>>>>> have to do that. >>>> >>>> That won't work. The doPrivileged doesn't give them any additional >>>> permissions in their code, so it has no affect. >> That's not my understanding. doPrivileged is useful whenever you want to >> perform an operation with permissions checked only on the current stack >> frame, and not on any other code executing up the stack. >> > > But if David is right about this not always sufficing ... > >> To be specific it will depend on the exact call stack. In general >> you'll get >> the least permissions based on your stack. So if application code with no >> permissions calls library code with permissions, the doPrivileged in the >> library code says "only look at my permissions" - and so the call can >> work. >> But if the application code with no permissions calls doPrivileged >> then it >> still has no permissions. A doPrivileged by the application code will >> only >> have an effect if the application code has the necessary permissions but >> there is a frame with fewer permissions further up the stack. > > ... then it may be necessary to issue the doPriviliged > inside the constructor in all cases, just in case it does > cross class loaders? > > -Doug > > From bradford.wetmore at oracle.com Fri Apr 16 17:44:43 2010 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 16 Apr 2010 10:44:43 -0700 Subject: [PATCH FOR REVIEW]: Improve error output for NSS provider In-Reply-To: References: <4BC79BF8.5060909@oracle.com> Message-ID: <4BC8A20B.20200@oracle.com> > You're correct. I should have made it clearer in the initial e-mail, > though I did ask if it was ok to push it to tl which is 7 only. The > patch does apply to both, so I'll ask Joe Darcy about backporting it > once it's in 7. I would imagine it would be no problem at all. I'll be happy to review it again. > Thanks. These are all the values used by the current version of NSS > (3.12.3 IIRC). We usually don't include draft values, unless they have gained wide usage already. > Thanks. Pushed: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c444651077d2 I'll move to Fix available when I get to our internal network (still working at home). >>> http://cr.openjdk.java.net/~andrew/nss/webrev.01/jdk.patch >> >> Specifying just the top level of the webrev is preferred. > > Whoops! Sorry, I usually do post the right URL. Must have copied the > wrong one. No problem, partly my fault too. I usually use SFRAMES where the change's full context is available. I didn't think to take off the last component of the URL until I was mostly done. Thanks for fixing that. Brad From dl at cs.oswego.edu Fri Apr 16 11:43:48 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 16 Apr 2010 07:43:48 -0400 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: References: Message-ID: <4BC84D74.5070901@cs.oswego.edu> On 04/15/10 18:34, Martin Buchholz wrote: > People are using Atomic field updaters to update fields in classes in other > classloaders. > I think the policy on this awaits interpretation by Jeff or other members of security team. FWIW, my take is that if users know that they may cross class loaders, then they should wrap these in doPrivileged anyway. As in ... >>>>> Now, they could work around the problem by creating their atomic >>>>> updater inside a doPrivileged, but probably we intend for them not to >>>>> have to do that. >>> >>> That won't work. The doPrivileged doesn't give them any additional >>> permissions in their code, so it has no affect. > That's not my understanding. doPrivileged is useful whenever you want to > perform an operation with permissions checked only on the current stack > frame, and not on any other code executing up the stack. > But if David is right about this not always sufficing ... > To be specific it will depend on the exact call stack. In general you'll get > the least permissions based on your stack. So if application code with no > permissions calls library code with permissions, the doPrivileged in the > library code says "only look at my permissions" - and so the call can work. > But if the application code with no permissions calls doPrivileged then it > still has no permissions. A doPrivileged by the application code will only > have an effect if the application code has the necessary permissions but > there is a frame with fewer permissions further up the stack. ... then it may be necessary to issue the doPriviliged inside the constructor in all cases, just in case it does cross class loaders? -Doug From lana.steuck at sun.com Sat Apr 17 22:11:50 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 17 Apr 2010 22:11:50 +0000 Subject: hg: jdk7/tl: 6 new changesets Message-ID: <20100417221151.766A8445E7@hg.openjdk.java.net> Changeset: 6b1069f53fbc Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/6b1069f53fbc Added tag jdk7-b86 for changeset 433a60a9c0bf ! .hgtags Changeset: 82135c848d5f Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/82135c848d5f Added tag jdk7-b87 for changeset 6b1069f53fbc ! .hgtags Changeset: 9d9097eb4b5a Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/9d9097eb4b5a Added tag jdk7-b88 for changeset 82135c848d5f ! .hgtags Changeset: b1c3b0e44b9d Author: lana Date: 2010-04-08 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/b1c3b0e44b9d Merge Changeset: 7f1ba4459972 Author: lana Date: 2010-04-13 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/7f1ba4459972 Merge Changeset: 425ba3efabbf Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/425ba3efabbf Added tag jdk7-b89 for changeset 7f1ba4459972 ! .hgtags From lana.steuck at sun.com Sat Apr 17 22:11:57 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 17 Apr 2010 22:11:57 +0000 Subject: hg: jdk7/tl/corba: 4 new changesets Message-ID: <20100417221202.D193E445E8@hg.openjdk.java.net> Changeset: 09a41111a401 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/09a41111a401 Added tag jdk7-b86 for changeset 6253e28826d1 ! .hgtags Changeset: 39e14d2da687 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/39e14d2da687 Added tag jdk7-b87 for changeset 09a41111a401 ! .hgtags Changeset: bb4424c5e778 Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/bb4424c5e778 Added tag jdk7-b88 for changeset 39e14d2da687 ! .hgtags Changeset: 56ce07b0eb47 Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/56ce07b0eb47 Added tag jdk7-b89 for changeset bb4424c5e778 ! .hgtags From lana.steuck at sun.com Sat Apr 17 22:13:30 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 17 Apr 2010 22:13:30 +0000 Subject: hg: jdk7/tl/hotspot: 65 new changesets Message-ID: <20100417221649.7512C445E9@hg.openjdk.java.net> Changeset: 4b58861a3570 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4b58861a3570 Added tag jdk7-b86 for changeset bf823ef06b4f ! .hgtags Changeset: 877a14af58e1 Author: never Date: 2010-02-18 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/877a14af58e1 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp Reviewed-by: kvn ! src/share/vm/opto/split_if.cpp + test/compiler/6663854/Test6663854.java Changeset: 2883969d09e7 Author: kvn Date: 2010-02-19 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2883969d09e7 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag Summary: Matcher::float_in_double should be true only when FPU is used for floats. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp Changeset: b71f13525cc8 Author: never Date: 2010-02-19 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b71f13525cc8 6927049: assert(is_Loop(),"invalid node class") Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 8b38237bae55 Author: kvn Date: 2010-02-22 16:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b38237bae55 6928717: HS17 fails to build with SS11 C++ Summary: Add missing handles.inline.hpp for codeCache.cpp. Reviewed-by: never ! src/share/vm/includeDB_core Changeset: 855c5171834c Author: twisti Date: 2010-02-23 17:46 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/855c5171834c 6928839: JSR 292 typo in x86 _adapter_check_cast Summary: There is a small typo in methodHandles_x86.cpp. Reviewed-by: kvn ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: da9559b49b84 Author: never Date: 2010-02-25 11:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/da9559b49b84 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp Changeset: 2432acbee618 Author: kvn Date: 2010-02-25 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2432acbee618 6930035: C2 type system incorrectly handles case j.l.Object->meet(constant AryPtr) Summary: Add missing code. Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 336c6c200f5f Author: kvn Date: 2010-02-25 22:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/336c6c200f5f 6930116: loop predication code does not handle If nodes with only one projection Summary: Add check for iff->outcnt() < 2. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 7d236a9688c5 Author: never Date: 2010-03-01 12:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7d236a9688c5 6930398: fix for return address locals in OSR entries uses wrong test Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp Changeset: b81f3572f355 Author: tonyp Date: 2010-02-23 23:13 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b81f3572f355 6928059: G1: command line parameter renaming Summary: Rename G1 parameters to make them more consistent. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! 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/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 1c72304f1885 Author: tonyp Date: 2010-02-23 23:14 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1c72304f1885 6928073: G1: use existing command line parameters for marking cycle initiation Summary: replace the combination of the G1SteadyStateUsed / G1SteadyStateUsedDelta parameteres to decide the marking initiation threshold and instead use InitiatingHeapOccupancyPercent. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5f1f51edaff6 Author: jmasa Date: 2010-02-24 07:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5f1f51edaff6 6928081: G1: rename parameters common with CMS Summary: Rename marking stack sizing flags to be common between G1 and CMS Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a1c410de27e4 Author: tonyp Date: 2010-02-24 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a1c410de27e4 6928065: G1: use existing command line parameters to set the young generation size Summary: see synopsis Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ab75c83d7c37 Author: johnc Date: 2010-03-02 13:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ab75c83d7c37 Merge ! src/share/vm/includeDB_core Changeset: 8911d8c0596f Author: phh Date: 2010-02-26 16:40 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8911d8c0596f 6923123: Hotspot refuses to start when -Xmx4m or -Xms4m is specified Summary: Reduce NewSize from 4m to 1m. Reviewed-by: tonyp, jmasa ! src/share/vm/runtime/globals.hpp Changeset: c76ca382971b Author: johnc Date: 2010-03-02 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c76ca382971b Merge ! src/share/vm/runtime/globals.hpp Changeset: d47555d7aca8 Author: jmasa Date: 2010-03-03 08:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d47555d7aca8 6910182: CMS: assert(_cursor[j] == _survivor_plab_array[j].end(),"Ctl pt invariant") Summary: Calculation of the slicing of survivor spaces for MT was incorrect. Reviewed-by: ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: c8a467bf56ad Author: coleenp Date: 2010-03-02 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c8a467bf56ad 6914050: jvm assertion "guard pages must be in use" in -Xcomp mode Summary: Move creating stack guard pages in jni attach thread before potential java call rather than after. Also cleanup stack guard pages when jni attach fails Reviewed-by: never, dholmes ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/thread.cpp Changeset: 4b0f2f4918ed Author: xlu Date: 2010-03-10 21:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4b0f2f4918ed 6933402: RFE: Improve PrintSafepointStatistics output to track cleanup time Summary: Improve the usability of safepoint statistics data. See bug evaluation for more details. Reviewed-by: ysr, dholmes ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp Changeset: 12d91eb0f579 Author: acorn Date: 2010-03-11 14:41 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/12d91eb0f579 Merge Changeset: 51db1e4b379d Author: twisti Date: 2010-03-08 04:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/51db1e4b379d 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 Summary: A modified MethodHandlesTest revealed two bugs on x86_64. Reviewed-by: never, jrose ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: 7de45b5044c3 Author: never Date: 2010-03-09 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7de45b5044c3 6932270: Allow Java's ELF symtab reader to use separate debuginfo files Reviewed-by: never Contributed-by: Andrew Haley ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/symtab.c ! agent/src/os/linux/symtab.h + make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/linux/makefiles/vm.make Changeset: 3cf667df43ef Author: twisti Date: 2010-03-09 20:16 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3cf667df43ef 6919934: JSR 292 needs to support x86 C1 Summary: This implements JSR 292 support for C1 x86. Reviewed-by: never, jrose, kvn ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciCPCache.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: d8e270c4f609 Author: twisti Date: 2010-03-09 23:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d8e270c4f609 Merge Changeset: c466efa608d5 Author: roland Date: 2010-03-05 13:58 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c466efa608d5 6932496: c1: deoptimization of jsr subroutine fails on sparcv9 Summary: store jsr ret bci as intptr constant in c1 debug info Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/6932496/Test6932496.java Changeset: da06d1795d84 Author: twisti Date: 2010-03-11 05:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/da06d1795d84 6934089: Zero 32-bit/64kb page fix Summary: The fix for 6927165 increased the number of shadow pages for 32-bit platforms and this causes a problem on systems with 64kb pages. Reviewed-by: twisti Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp Changeset: 9eba43136cb5 Author: twisti Date: 2010-03-16 11:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9eba43136cb5 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob Summary: Passing a null pointer to an InvokeDynamic function call should lead to a NullPointerException. Reviewed-by: kvn, never ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/includeDB_core ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 428a9c451986 Author: kvn Date: 2010-03-16 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/428a9c451986 6935466: new CodeCache flushing code is not guarded by the flag Summary: Add missing guard. Reviewed-by: never ! src/share/vm/compiler/compileBroker.cpp Changeset: fc2c71045ada Author: twisti Date: 2010-03-17 10:22 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc2c71045ada 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls Summary: The logic for x86 C1 to save the SP over MH calls is pretty straight forward but SPARC handles that differently. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp Changeset: 2484f4d6a54e Author: kvn Date: 2010-03-17 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2484f4d6a54e 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Summary: Added missing counter decrement when substring search restarted. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp + test/compiler/6935535/Test.java Changeset: c047da02984c Author: never Date: 2010-03-17 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c047da02984c 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp + test/compiler/6930043/Test6930043.java Changeset: 76c1d7d13ec5 Author: twisti Date: 2010-03-18 09:56 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/76c1d7d13ec5 6932091: JSR 292 x86 code cleanup Summary: Some code cleanups found during the JSR 292 SPARC port. Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 97fe2cc98b1d Author: twisti Date: 2010-03-18 06:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/97fe2cc98b1d Merge Changeset: 6c94fe3c8df3 Author: trims Date: 2010-03-18 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c94fe3c8df3 Merge Changeset: 07226e9eab8f Author: trims Date: 2010-03-18 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07226e9eab8f 6936366: Fork HS17 to HS18 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS18 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3deb84ecd19d Author: trims Date: 2010-03-23 20:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3deb84ecd19d Added tag hs18-b01 for changeset 07226e9eab8f ! .hgtags Changeset: e7e7e36ccdb5 Author: trims Date: 2010-03-23 20:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7e7e36ccdb5 Merge ! .hgtags Changeset: 465c39e1fb46 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/465c39e1fb46 Added tag jdk7-b87 for changeset e7e7e36ccdb5 ! .hgtags Changeset: 2a1472c30599 Author: jcoomes Date: 2010-03-03 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2a1472c30599 4396719: Mark Sweep stack overflow on deeply nested Object arrays Summary: Use an explicit stack for object arrays and process them in chunks. Reviewed-by: iveresov, apetrusenko ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp + src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc_parallel ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp + src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 94946bdf36bd Author: apetrusenko Date: 2010-03-15 02:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/94946bdf36bd Merge Changeset: 664ae0c5e0e5 Author: johnc Date: 2010-03-11 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/664ae0c5e0e5 6755988: G1: assert(new_obj != 0 || ... "should be forwarded") Summary: A TLAB became large enough to be considered a humongous object allowing multiple objects to be allocated in a humongous region, which violates a basic assumption about humongous regions. The changes ensure that TLABs cannot be regarded as humongous. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 3f0549ed0c98 Author: apetrusenko Date: 2010-03-18 01:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f0549ed0c98 6921710: G1: assert(new_finger >= _finger && new_finger < _region_limit,"invariant") Summary: If CM task was aborted while scanning the last object of the specified region and the size of that object is equal to bitmap's granularity then the next offset would be equal or over the region limit which is exactly what the assertion states. Reviewed-by: ysr, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: c385bf94cfb8 Author: jcoomes Date: 2010-03-18 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c385bf94cfb8 6935839: excessive marking stack growth during full gcs Summary: process one item at a time from the objarray stack/queue Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: cc98cc548f51 Author: apetrusenko Date: 2010-03-22 02:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cc98cc548f51 Merge ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp Changeset: d4197f8d516a Author: tonyp Date: 2010-03-18 12:14 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d4197f8d516a 6935821: G1: threads created during marking do not active their SATB queues Summary: Newly-created threads always had the active field of their SATB queue initialized to false, even if they were created during marking. As a result, updates from threads created during a marking cycle were never enqueued and never processed. The fix includes remaining a method from active() to is_active() for readability and naming consistency. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 5c9df1575c39 Author: trims Date: 2010-04-01 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5c9df1575c39 Merge Changeset: 096b18156d91 Author: trims Date: 2010-04-01 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/096b18156d91 6940419: Bump the HS18 build number to 02 Summary: Update the HS18 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b3d12e645e7 Author: coleenp Date: 2010-03-12 10:42 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3b3d12e645e7 6929067: Stack guard pages should be removed when thread is detached Summary: Add code to unmap stack guard area when thread is detached. Reviewed-by: coleenp, kamg ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp + test/runtime/6929067/T.java + test/runtime/6929067/Test6929067.sh + test/runtime/6929067/invoke.c Changeset: 0f6600cee529 Author: xlu Date: 2010-03-13 16:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0f6600cee529 6934758: Expose the break down of clean up task time during safepoint. Summary: Use -XX:+TraceSafepointCleanupTime to print out the details of each clean up tasks. Reviewed-by: dholmes, ysr ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp Changeset: 21141e23627a Author: dcubed Date: 2010-03-16 17:47 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/21141e23627a 6923488: 4/4 need minor tweaks to HotSpot build for Cygwin Summary: Clean up get_msc_ver, build.bat and build.make in general and for Cygwin. Reviewed-by: ohair ! make/windows/build.bat ! make/windows/build.make ! make/windows/get_msc_ver.sh Changeset: cd20a6f46fec Author: dcubed Date: 2010-03-16 20:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cd20a6f46fec Merge Changeset: e392695de029 Author: fparain Date: 2010-03-17 11:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e392695de029 6935224: Adding new DTrace probes to work with Palantir Summary: Adding probes related to thread scheduling and class initialization Reviewed-by: kamg, never ! src/os/solaris/dtrace/hotspot.d ! src/os/solaris/vm/attachListener_solaris.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/dtraceAttacher.hpp Changeset: 98ba8ca25feb Author: coleenp Date: 2010-03-18 16:47 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/98ba8ca25feb 6936168: Recent fix for unmapping stack guard pages doesn't close /proc/self/maps Summary: Add close to returns (fix for 6929067 also contributed by aph) Reviewed-by: aph, dcubed, andrew, acorn Contributed-by: aph at redhat.com, andreas.kohn at fredhopper.com ! src/os/linux/vm/os_linux.cpp Changeset: 4f7af0dc447b Author: dcubed Date: 2010-03-23 14:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4f7af0dc447b 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove assert to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/vm/services/management.cpp Changeset: 5d393243d487 Author: dcubed Date: 2010-03-23 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5d393243d487 Merge Changeset: 39e409a664b3 Author: dcubed Date: 2010-03-25 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/39e409a664b3 6938185: 3/4 6923488 breaks Windows command shell builds Summary: Fix build.bat so invoking command shell doesn't exit on error. Fix dirname assumptions. Document some MKS environment dependencies. Reviewed-by: coleenp ! make/windows/build.bat ! make/windows/build.make ! make/windows/create.bat ! make/windows/get_msc_ver.sh Changeset: 84043c7507b9 Author: dcubed Date: 2010-03-25 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/84043c7507b9 Merge Changeset: 4a9cc99938e3 Author: acorn Date: 2010-03-26 11:10 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4a9cc99938e3 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp Changeset: 7c358fbb6a84 Author: acorn Date: 2010-04-01 11:23 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7c358fbb6a84 Merge Changeset: 4b60f23c4223 Author: acorn Date: 2010-04-01 20:48 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4b60f23c4223 Merge Changeset: 3f12a94552cc Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f12a94552cc Added tag jdk7-b88 for changeset 4b60f23c4223 ! .hgtags Changeset: 5b29c2368d93 Author: lana Date: 2010-04-08 15:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5b29c2368d93 Merge ! src/share/vm/opto/type.cpp Changeset: 15836273ac24 Author: lana Date: 2010-04-13 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/15836273ac24 Merge Changeset: 765578777b6e Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/765578777b6e Added tag jdk7-b89 for changeset 15836273ac24 ! .hgtags From lana.steuck at sun.com Sat Apr 17 22:19:17 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 17 Apr 2010 22:19:17 +0000 Subject: hg: jdk7/tl/jaxp: 4 new changesets Message-ID: <20100417221918.0B97F445EA@hg.openjdk.java.net> Changeset: 8b493f1aa136 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/8b493f1aa136 Added tag jdk7-b86 for changeset 81c0f115bbe5 ! .hgtags Changeset: d8ebd1591003 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d8ebd1591003 Added tag jdk7-b87 for changeset 8b493f1aa136 ! .hgtags Changeset: d2818fd2b036 Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d2818fd2b036 Added tag jdk7-b88 for changeset d8ebd1591003 ! .hgtags Changeset: c5d932ee326d Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c5d932ee326d Added tag jdk7-b89 for changeset d2818fd2b036 ! .hgtags From lana.steuck at sun.com Sat Apr 17 22:19:23 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 17 Apr 2010 22:19:23 +0000 Subject: hg: jdk7/tl/jaxws: 4 new changesets Message-ID: <20100417221923.842D7445EB@hg.openjdk.java.net> Changeset: 3febd6fab2ac Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/3febd6fab2ac Added tag jdk7-b86 for changeset 512b0e924a5a ! .hgtags Changeset: 8c666f8f3565 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/8c666f8f3565 Added tag jdk7-b87 for changeset 3febd6fab2ac ! .hgtags Changeset: bf3675aa7f20 Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/bf3675aa7f20 Added tag jdk7-b88 for changeset 8c666f8f3565 ! .hgtags Changeset: ead7c4566a00 Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ead7c4566a00 Added tag jdk7-b89 for changeset bf3675aa7f20 ! .hgtags From lana.steuck at sun.com Sat Apr 17 22:20:50 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 17 Apr 2010 22:20:50 +0000 Subject: hg: jdk7/tl/jdk: 21 new changesets Message-ID: <20100417222718.A7AC2445EC@hg.openjdk.java.net> Changeset: 2cafbbe9825e Author: mikejwre Date: 2010-03-18 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2cafbbe9825e Added tag jdk7-b86 for changeset eae6e9ab2606 ! .hgtags Changeset: b3c69282f6d3 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b3c69282f6d3 Added tag jdk7-b87 for changeset 2cafbbe9825e ! .hgtags Changeset: b50cfd4479fa Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b50cfd4479fa Added tag jdk7-b88 for changeset b3c69282f6d3 ! .hgtags Changeset: 0137b5857c63 Author: okutsu Date: 2010-03-10 14:32 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0137b5857c63 6932473: (tz) javazic produces incorrect SimpleTimeZone parameters with Sun<=7 Reviewed-by: peytoia ! make/tools/src/build/tools/javazic/RuleDay.java Changeset: 0e0ce1aa1bba Author: peytoia Date: 2010-03-11 11:54 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e0ce1aa1bba 6933032: (tz) Support tzdata2010e Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/southamerica Changeset: ce3770eadf85 Author: malenkov Date: 2010-03-11 17:39 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce3770eadf85 6707226: java.beans.Statement & java.beans.Expression miss one important usecase Reviewed-by: rupashka ! src/share/classes/java/beans/Expression.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Statement/Test6707226.java Changeset: d86c053ca938 Author: rupashka Date: 2010-03-15 16:16 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d86c053ca938 6931347: SynthTabbedPaneUI.paintTabArea() is not called when tabbed pane is painted Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: 1224c1388e86 Author: rupashka Date: 2010-03-17 12:48 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1224c1388e86 6933784: NIMBUS: ImageView getNoImageIcon and getLoadingImageIcon returns nulls instead of an icon Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java + test/javax/swing/plaf/synth/Test6933784.java Changeset: ac4c8e3bf93f Author: lana Date: 2010-03-17 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ac4c8e3bf93f Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: 325823a26aac Author: peterz Date: 2010-03-18 12:02 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/325823a26aac 6932524: NIMBUS: 3 constructors of JSplitPane creates new jsp with continuous layout - they should not. Reviewed-by: alexp ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/plaf/nimbus/skin.laf Changeset: ef892cd084ec Author: rupashka Date: 2010-03-24 15:14 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ef892cd084ec 6922214: SynthTextPaneUI.installUI() doesn't install the default caret and highlighter Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java Changeset: f799c62ad4f8 Author: peytoia Date: 2010-03-30 18:35 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f799c62ad4f8 6939021: (tz) Support tzdata2010g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java Changeset: dbde35ddda78 Author: peytoia Date: 2010-03-30 21:16 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbde35ddda78 6907881: Different undesired behavior for entering Asian characters in Windows IME starting with Java 6.0 Reviewed-by: okutsu ! src/windows/native/sun/windows/awt_Component.cpp Changeset: eb39ccbd95f9 Author: lana Date: 2010-04-08 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb39ccbd95f9 Merge Changeset: d23dcd3e3ce4 Author: andrew Date: 2010-03-12 01:09 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d23dcd3e3ce4 6934327: Update linux fontconfigs for Ubuntu and Fedora. Summary: Use fontconfigs suitable for recent Fedora, Ubuntu and Debian releases. Reviewed-by: prr ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties Changeset: 45bd445f6250 Author: lana Date: 2010-03-19 18:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45bd445f6250 Merge - make/java/text/FILES_java.gmk - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: bf23bec88222 Author: lana Date: 2010-04-08 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf23bec88222 Merge Changeset: 025f9e57566a Author: lana Date: 2010-04-08 15:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/025f9e57566a Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/java/beans/Statement.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 4a6abb7e224c Author: lana Date: 2010-04-13 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a6abb7e224c Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 7f90d0b9dbb7 Author: mikejwre Date: 2010-04-15 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7f90d0b9dbb7 Added tag jdk7-b89 for changeset 4a6abb7e224c ! .hgtags Changeset: 7ecc023957d8 Author: lana Date: 2010-04-17 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7ecc023957d8 Merge From lana.steuck at sun.com Sat Apr 17 22:32:39 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 17 Apr 2010 22:32:39 +0000 Subject: hg: jdk7/tl/langtools: 7 new changesets Message-ID: <20100417223258.D9E59445EE@hg.openjdk.java.net> Changeset: 409db93d19c0 Author: mikejwre Date: 2010-03-18 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/409db93d19c0 Added tag jdk7-b86 for changeset ef07347428f2 ! .hgtags Changeset: f9b5d4867a26 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f9b5d4867a26 Added tag jdk7-b87 for changeset 409db93d19c0 ! .hgtags Changeset: 737185f3300f Author: mikejwre Date: 2010-04-08 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/737185f3300f Added tag jdk7-b88 for changeset f9b5d4867a26 ! .hgtags Changeset: ad1bf317cc57 Author: lana Date: 2010-04-08 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ad1bf317cc57 Merge - test/tools/javap/T6305779.java Changeset: 6cea9a143208 Author: lana Date: 2010-04-13 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6cea9a143208 Merge - test/tools/javap/T6305779.java Changeset: 71c2c23a7c35 Author: mikejwre Date: 2010-04-15 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/71c2c23a7c35 Added tag jdk7-b89 for changeset 6cea9a143208 ! .hgtags Changeset: 37fa8cd046ab Author: lana Date: 2010-04-17 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/37fa8cd046ab Merge From tomas at primekey.se Mon Apr 19 08:34:06 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Mon, 19 Apr 2010 10:34:06 +0200 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BB3F01F.6080504@oracle.com> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> <4BB3F01F.6080504@oracle.com> Message-ID: <4BCC157E.8010902@primekey.se> Hi, Sorry being late, I was away on vacation. Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we specify token=false would it still be a token object on the HSM finally? For most HSMs we need to use a cusom PCKS11 config file, otherwise it is not possible to generate key because the HSM will throw an error, usually invalid_template. Cheers, Tomas Valerie (Yu-Ching) Peng wrote: > > If the default PKCS11 config is used, I'd expect that KeyPairGenerator > to generate a "session" key and then SunPKCS11 keystore impl will do a > C_CopyObject(...) w/ the desired alias. > > Is a custom PKCS11 config file used here? If yes, perhaps it specifies > that token key be generated for key generation? > Valerie > > On 03/31/10 17:51, Michael StJohns wrote: >> KeyPairGenerator should be generating a "Session" key pair. >> >> When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. >> >> Let me look at the code and see what's going on and make further comments tomorrow. >> >> Mike >> >> >> At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >> >> >>> Hi, >>> >>> Sorry if I misunderstood you. That is actually exactly how we do it, >>> >>> 1. Use KeyPairGenerator with P11 provider to generate key pair. >>> 2. Create a keystore with the P11 provier. >>> 3. Generate a self signed certificate. >>> 4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>> >>> The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >>> 1. Private key - no alias >>> 2. Public key - no alias >>> 3. Certificate - myalias >>> >>> The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >>> This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >>> >>> If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >>> >>> So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >>> >>> Cheers, >>> Tomas >>> >>> >>> On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>> >>>> Why do you assume that the key is generated in software? >>>> You use the KeyGenerator API to generate a key, this key can be >>>> generated on the HSM if you have SunPKCS11 provider configured to be the >>>> most preferred provider. This key should actually just encapsulate the >>>> native key handle (not the actual value/encoding) which you can then >>>> pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>>> impl would then take this key object (with the native key handle) and >>>> create a persistent copy on the HSM with the specified alias. >>>> >>>> Regards, >>>> Valerie >>>> >>>> On 03/29/10 22:57, Tomas Gustavsson wrote: >>>> >>>>> Hi, thanks for the answer. >>>>> >>>>> Generating a key in software and trying to store it on the HSM violates >>>>> the whole idea of using an HSM. Which is to generate and maintain the >>>>> keys in the HSM at all times. >>>>> Most high security policies *requires* that the keys are generated by >>>>> the HSM, inside the HSM. >>>>> I also doubt that it would work to store software generated keys using >>>>> the keytool API. Many HSMs even forbid this, at least when running in >>>>> strict FIPS mode. >>>>> >>>>> Regards, >>>>> Tomas >>>>> >>>>> Valerie Peng wrote: >>>>> >>>>> >>>>>> Have you tried saving that key through the KeyStore API which allows you >>>>>> to specify an alias? >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>> >>>>>> >>>>>>> Slightly off topic. >>>>>>> Something I would like to see is API support for setting aliases when >>>>>>> using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>>> not allow changing an alias of private keys after they have been >>>>>>> generated. Since the key pair generator sets a blank alias when using >>>>>>> PKCS#11, HSM key pairs are left with no alias. >>>>>>> >>>>>>> You can set an alias by providing it using pkcs11 attributes through >>>>>>> the provider, but that alias is provider global (for all generated key >>>>>>> pairs) which is not very usable. >>>>>>> >>>>>>> Regards, >>>>>>> Tomas >>>>>>> >>>>>>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>> >>>>>>> >>>>>>>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>>> are constructed using the attributes values associated with the >>>>>>>> keys/certs. Thus, this is probably due to some problem with the native >>>>>>>> library which generated the keys/certs. >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi Valerie >>>>>>>>> >>>>>>>>> As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>> >>>>>>>>> Is this something we should fix on the Java side? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >> >> >> > From mstjohns at comcast.net Mon Apr 19 15:04:50 2010 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 19 Apr 2010 11:04:50 -0400 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BCC157E.8010902@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> <4BB3F01F.6080504@oracle.com> <4BCC157E.8010902@primekey.se> Message-ID: <20100419150456.287AD661F@mail.openjdk.java.net> At 04:34 AM 4/19/2010, Tomas Gustavsson wrote: >Hi, >Sorry being late, I was away on vacation. > >Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we specify token=false would it still be a token object on the HSM finally? Yes. The C_CopyObject turns the Session object into a Token object. and that happens as a side effect of the KeyStore.store operation. >For most HSMs we need to use a cusom PCKS11 config file, otherwise it is not possible to generate key because the HSM will throw an error, usually invalid_template. Does this happen for all keys or just for EC keys? >Cheers, >Tomas > > >Valerie (Yu-Ching) Peng wrote: >>If the default PKCS11 config is used, I'd expect that KeyPairGenerator to generate a "session" key and then SunPKCS11 keystore impl will do a C_CopyObject(...) w/ the desired alias. >>Is a custom PKCS11 config file used here? If yes, perhaps it specifies that token key be generated for key generation? >>Valerie >>On 03/31/10 17:51, Michael StJohns wrote: >>>KeyPairGenerator should be generating a "Session" key pair. >>> >>>When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. >>> >>>Let me look at the code and see what's going on and make further comments tomorrow. >>> >>>Mike >>> >>> >>>At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >>> >>> >>>>Hi, >>>> >>>>Sorry if I misunderstood you. That is actually exactly how we do it, >>>> >>>>1. Use KeyPairGenerator with P11 provider to generate key pair. >>>>2. Create a keystore with the P11 provier. >>>>3. Generate a self signed certificate. >>>>4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>>> >>>>The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >>>>1. Private key - no alias >>>>2. Public key - no alias >>>>3. Certificate - myalias >>>> >>>>The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >>>>This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >>>> >>>>If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >>>> >>>>So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >>>> >>>>Cheers, >>>>Tomas >>>> >>>> >>>>On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>>> >>>>>Why do you assume that the key is generated in software? >>>>>You use the KeyGenerator API to generate a key, this key can be >>>>>generated on the HSM if you have SunPKCS11 provider configured to be the >>>>>most preferred provider. This key should actually just encapsulate the >>>>>native key handle (not the actual value/encoding) which you can then >>>>>pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>>>>impl would then take this key object (with the native key handle) and >>>>>create a persistent copy on the HSM with the specified alias. >>>>> >>>>>Regards, >>>>>Valerie >>>>> >>>>>On 03/29/10 22:57, Tomas Gustavsson wrote: >>>>> >>>>>>Hi, thanks for the answer. >>>>>> >>>>>>Generating a key in software and trying to store it on the HSM violates >>>>>>the whole idea of using an HSM. Which is to generate and maintain the >>>>>>keys in the HSM at all times. >>>>>>Most high security policies *requires* that the keys are generated by >>>>>>the HSM, inside the HSM. >>>>>>I also doubt that it would work to store software generated keys using >>>>>>the keytool API. Many HSMs even forbid this, at least when running in >>>>>>strict FIPS mode. >>>>>> >>>>>>Regards, >>>>>>Tomas >>>>>> >>>>>>Valerie Peng wrote: >>>>>> >>>>>> >>>>>>>Have you tried saving that key through the KeyStore API which allows you >>>>>>>to specify an alias? >>>>>>>Thanks, >>>>>>>Valerie >>>>>>> >>>>>>>On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>>> >>>>>>> >>>>>>>>Slightly off topic. >>>>>>>>Something I would like to see is API support for setting aliases when >>>>>>>>using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>>>>not allow changing an alias of private keys after they have been >>>>>>>>generated. Since the key pair generator sets a blank alias when using >>>>>>>>PKCS#11, HSM key pairs are left with no alias. >>>>>>>> >>>>>>>>You can set an alias by providing it using pkcs11 attributes through >>>>>>>>the provider, but that alias is provider global (for all generated key >>>>>>>>pairs) which is not very usable. >>>>>>>> >>>>>>>>Regards, >>>>>>>>Tomas >>>>>>>> >>>>>>>>On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>>> >>>>>>>> >>>>>>>>>Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>>>>are constructed using the attributes values associated with the >>>>>>>>>keys/certs. Thus, this is probably due to some problem with the native >>>>>>>>>library which generated the keys/certs. >>>>>>>>>Valerie >>>>>>>>> >>>>>>>>>On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>Hi Valerie >>>>>>>>>> >>>>>>>>>>As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>>>customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>>> >>>>>>>>>>Is this something we should fix on the Java side? >>>>>>>>>> >>>>>>>>>>Thanks >>>>>>>>>>Max >>>>>>>>>> >>>>>>>>>> >>> >>> >>> From tomas at primekey.se Mon Apr 19 15:08:00 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Mon, 19 Apr 2010 17:08:00 +0200 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <20100419150456.CA590C3A9A@mail.primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> <4BB3F01F.6080504@oracle.com> <4BCC157E.8010902@primekey.se> <20100419150456.CA590C3A9A@mail.primekey.se> Message-ID: If we need it it's usually for all keys, both RSA and EC. Cheers, Tomas "Michael StJohns" wrote: >At 04:34 AM 4/19/2010, Tomas Gustavsson wrote: > >>Hi, >>Sorry being late, I was away on vacation. >> >>Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we specify token=false would it still be a token object on the HSM finally? > >Yes. The C_CopyObject turns the Session object into a Token object. and that happens as a side effect of the KeyStore.store operation. > >>For most HSMs we need to use a cusom PCKS11 config file, otherwise it is not possible to generate key because the HSM will throw an error, usually invalid_template. > >Does this happen for all keys or just for EC keys? > > >>Cheers, >>Tomas >> >> >>Valerie (Yu-Ching) Peng wrote: >>>If the default PKCS11 config is used, I'd expect that KeyPairGenerator to generate a "session" key and then SunPKCS11 keystore impl will do a C_CopyObject(...) w/ the desired alias. >>>Is a custom PKCS11 config file used here? If yes, perhaps it specifies that token key be generated for key generation? >>>Valerie >>>On 03/31/10 17:51, Michael StJohns wrote: >>>>KeyPairGenerator should be generating a "Session" key pair. >>>> >>>>When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. >>>> >>>>Let me look at the code and see what's going on and make further comments tomorrow. >>>> >>>>Mike >>>> >>>> >>>>At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>Sorry if I misunderstood you. That is actually exactly how we do it, >>>>> >>>>>1. Use KeyPairGenerator with P11 provider to generate key pair. >>>>>2. Create a keystore with the P11 provier. >>>>>3. Generate a self signed certificate. >>>>>4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>>>> >>>>>The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >>>>>1. Private key - no alias >>>>>2. Public key - no alias >>>>>3. Certificate - myalias >>>>> >>>>>The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >>>>>This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >>>>> >>>>>If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >>>>> >>>>>So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >>>>> >>>>>Cheers, >>>>>Tomas >>>>> >>>>> >>>>>On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>>>> >>>>>>Why do you assume that the key is generated in software? >>>>>>You use the KeyGenerator API to generate a key, this key can be >>>>>>generated on the HSM if you have SunPKCS11 provider configured to be the >>>>>>most preferred provider. This key should actually just encapsulate the >>>>>>native key handle (not the actual value/encoding) which you can then >>>>>>pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>>>>>impl would then take this key object (with the native key handle) and >>>>>>create a persistent copy on the HSM with the specified alias. >>>>>> >>>>>>Regards, >>>>>>Valerie >>>>>> >>>>>>On 03/29/10 22:57, Tomas Gustavsson wrote: >>>>>> >>>>>>>Hi, thanks for the answer. >>>>>>> >>>>>>>Generating a key in software and trying to store it on the HSM violates >>>>>>>the whole idea of using an HSM. Which is to generate and maintain the >>>>>>>keys in the HSM at all times. >>>>>>>Most high security policies *requires* that the keys are generated by >>>>>>>the HSM, inside the HSM. >>>>>>>I also doubt that it would work to store software generated keys using >>>>>>>the keytool API. Many HSMs even forbid this, at least when running in >>>>>>>strict FIPS mode. >>>>>>> >>>>>>>Regards, >>>>>>>Tomas >>>>>>> >>>>>>>Valerie Peng wrote: >>>>>>> >>>>>>> >>>>>>>>Have you tried saving that key through the KeyStore API which allows you >>>>>>>>to specify an alias? >>>>>>>>Thanks, >>>>>>>>Valerie >>>>>>>> >>>>>>>>On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>>>> >>>>>>>> >>>>>>>>>Slightly off topic. >>>>>>>>>Something I would like to see is API support for setting aliases when >>>>>>>>>using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>>>>>not allow changing an alias of private keys after they have been >>>>>>>>>generated. Since the key pair generator sets a blank alias when using >>>>>>>>>PKCS#11, HSM key pairs are left with no alias. >>>>>>>>> >>>>>>>>>You can set an alias by providing it using pkcs11 attributes through >>>>>>>>>the provider, but that alias is provider global (for all generated key >>>>>>>>>pairs) which is not very usable. >>>>>>>>> >>>>>>>>>Regards, >>>>>>>>>Tomas >>>>>>>>> >>>>>>>>>On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>>>>>are constructed using the attributes values associated with the >>>>>>>>>>keys/certs. Thus, this is probably due to some problem with the native >>>>>>>>>>library which generated the keys/certs. >>>>>>>>>>Valerie >>>>>>>>>> >>>>>>>>>>On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Hi Valerie >>>>>>>>>>> >>>>>>>>>>>As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>>>>customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>>>> >>>>>>>>>>>Is this something we should fix on the Java side? >>>>>>>>>>> >>>>>>>>>>>Thanks >>>>>>>>>>>Max >>>>>>>>>>> >>>>>>>>>>> >>>> >>>> >>>> > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From martinrb at google.com Mon Apr 19 18:23:39 2010 From: martinrb at google.com (Martin Buchholz) Date: Mon, 19 Apr 2010 11:23:39 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BC85D03.7030909@oracle.com> References: <4BC84D74.5070901@cs.oswego.edu> <4BC85D03.7030909@oracle.com> Message-ID: Hi David, I think you've done a good job of convincing me! The key idea is that updaters should mimic the access permissions of regular field updates by callers. Since those are not affected by what's further up the stack, neither should the field updaters. So I'm promoting myself from "messenger" to "advocate". I've updated the webrev from prototype to "serious". http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/ containing changes to the three field updater classes and cleanups to the test case, and javac warning removals. Arguably the new method getDeclaredFieldPrivileged belongs in a package-private class like AtomicSupport.java, but I'd rather not create such a class for just one method. Jeff, please review. Martin On Fri, Apr 16, 2010 at 05:50, David Holmes wrote: > Hi Doug, > > as I'm not a subscriber.> > > Doug Lea said the following on 04/16/10 21:43: >> >> On 04/15/10 18:34, Martin Buchholz wrote: >> >>> People are using Atomic field updaters to update fields in classes in >>> other classloaders. >>> >> >> I think the policy on this awaits interpretation by Jeff >> or other members of security team. FWIW, my take is that >> if users know that they may cross class loaders, then they >> should wrap these in doPrivileged anyway. As in ... > > I'm coming around to agreeing with the proposed fix. My take is that the > real security check should take place at the time the field is set: > > ?field_x_updater.set(obj, val); > > At this point the calling code must have the necessary permissions to set > field x of the given obj of type T. And I believe we do indeed check this. > > When the AtomicXXXXFieldUpdater constructor binds itself to the Field object > for T.x that's an optimization. There's no reason we couldn't do this on > each call to set() - other than it would perform terribly. So in that sense > the security checks that take place at construction are incidental** and so > we should be as permissive as we can make them _provided_ that the actual > set() call will make the necessary permission checks. > > ** This particular check is also incidental because we happen to use a > public reflection method to get the Field object. We could just as easily > have used a magic VM hook. > > David > ----- > >> >>>>>>> Now, they could work around the problem by creating their atomic >>>>>>> updater inside a doPrivileged, but probably we intend for them not to >>>>>>> have to do that. >>>>> >>>>> That won't work. The doPrivileged doesn't give them any additional >>>>> permissions in their code, so it has no affect. >>> >>> That's not my understanding. ?doPrivileged is useful whenever you want to >>> perform an operation with permissions checked only on the current stack >>> frame, and not on any other code executing up the stack. >>> >> >> But if David is right about this not always sufficing ... >> >>> To be specific it will depend on the exact call stack. In general you'll >>> get >>> the least permissions based on your stack. So if application code with no >>> permissions calls library code with permissions, the doPrivileged in the >>> library code says "only look at my permissions" - and so the call can >>> work. >>> But if the application code with no permissions calls doPrivileged then >>> it >>> still has no permissions. A doPrivileged by the application code will >>> only >>> have an effect if the application code has the necessary permissions but >>> there is a frame with fewer permissions further up the stack. >> >> ... then it may be necessary to issue the doPriviliged >> inside the constructor in all cases, just in case it does >> cross class loaders? >> >> -Doug >> >> > From valerie.peng at oracle.com Mon Apr 19 18:47:56 2010 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 19 Apr 2010 11:47:56 -0700 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> <4BB3F01F.6080504@oracle.com> <4BCC157E.8010902@primekey.se> <20100419150456.CA590C3A9A@mail.primekey.se> Message-ID: <4BCCA55C.3@oracle.com> You can use your custom PKCS11 config and as long as you call the KeyStore API to store the key (generated as session key) under the desired alias, it will be saved as a token key as a result. Have you tried it and see if this solves your problem? Valerie On 04/19/10 08:08, Tomas Gustavsson wrote: > If we need it it's usually for all keys, both RSA and EC. > > Cheers, > Tomas > > "Michael StJohns" wrote: > > >> At 04:34 AM 4/19/2010, Tomas Gustavsson wrote: >> >> >>> Hi, >>> Sorry being late, I was away on vacation. >>> >>> Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we specify token=false would it still be a token object on the HSM finally? >>> >> Yes. The C_CopyObject turns the Session object into a Token object. and that happens as a side effect of the KeyStore.store operation. >> >> >>> For most HSMs we need to use a cusom PCKS11 config file, otherwise it is not possible to generate key because the HSM will throw an error, usually invalid_template. >>> >> Does this happen for all keys or just for EC keys? >> >> >> >>> Cheers, >>> Tomas >>> >>> >>> Valerie (Yu-Ching) Peng wrote: >>> >>>> If the default PKCS11 config is used, I'd expect that KeyPairGenerator to generate a "session" key and then SunPKCS11 keystore impl will do a C_CopyObject(...) w/ the desired alias. >>>> Is a custom PKCS11 config file used here? If yes, perhaps it specifies that token key be generated for key generation? >>>> Valerie >>>> On 03/31/10 17:51, Michael StJohns wrote: >>>> >>>>> KeyPairGenerator should be generating a "Session" key pair. >>>>> >>>>> When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. >>>>> >>>>> Let me look at the code and see what's going on and make further comments tomorrow. >>>>> >>>>> Mike >>>>> >>>>> >>>>> At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Sorry if I misunderstood you. That is actually exactly how we do it, >>>>>> >>>>>> 1. Use KeyPairGenerator with P11 provider to generate key pair. >>>>>> 2. Create a keystore with the P11 provier. >>>>>> 3. Generate a self signed certificate. >>>>>> 4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>>>>> >>>>>> The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >>>>>> 1. Private key - no alias >>>>>> 2. Public key - no alias >>>>>> 3. Certificate - myalias >>>>>> >>>>>> The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >>>>>> This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >>>>>> >>>>>> If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >>>>>> >>>>>> So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >>>>>> >>>>>> Cheers, >>>>>> Tomas >>>>>> >>>>>> >>>>>> On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>>>>> >>>>>> >>>>>>> Why do you assume that the key is generated in software? >>>>>>> You use the KeyGenerator API to generate a key, this key can be >>>>>>> generated on the HSM if you have SunPKCS11 provider configured to be the >>>>>>> most preferred provider. This key should actually just encapsulate the >>>>>>> native key handle (not the actual value/encoding) which you can then >>>>>>> pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>>>>>> impl would then take this key object (with the native key handle) and >>>>>>> create a persistent copy on the HSM with the specified alias. >>>>>>> >>>>>>> Regards, >>>>>>> Valerie >>>>>>> >>>>>>> On 03/29/10 22:57, Tomas Gustavsson wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, thanks for the answer. >>>>>>>> >>>>>>>> Generating a key in software and trying to store it on the HSM violates >>>>>>>> the whole idea of using an HSM. Which is to generate and maintain the >>>>>>>> keys in the HSM at all times. >>>>>>>> Most high security policies *requires* that the keys are generated by >>>>>>>> the HSM, inside the HSM. >>>>>>>> I also doubt that it would work to store software generated keys using >>>>>>>> the keytool API. Many HSMs even forbid this, at least when running in >>>>>>>> strict FIPS mode. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Tomas >>>>>>>> >>>>>>>> Valerie Peng wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Have you tried saving that key through the KeyStore API which allows you >>>>>>>>> to specify an alias? >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Slightly off topic. >>>>>>>>>> Something I would like to see is API support for setting aliases when >>>>>>>>>> using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>>>>>> not allow changing an alias of private keys after they have been >>>>>>>>>> generated. Since the key pair generator sets a blank alias when using >>>>>>>>>> PKCS#11, HSM key pairs are left with no alias. >>>>>>>>>> >>>>>>>>>> You can set an alias by providing it using pkcs11 attributes through >>>>>>>>>> the provider, but that alias is provider global (for all generated key >>>>>>>>>> pairs) which is not very usable. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Tomas >>>>>>>>>> >>>>>>>>>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>>>>>> are constructed using the attributes values associated with the >>>>>>>>>>> keys/certs. Thus, this is probably due to some problem with the native >>>>>>>>>>> library which generated the keys/certs. >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi Valerie >>>>>>>>>>>> >>>>>>>>>>>> As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>>>>> >>>>>>>>>>>> Is this something we should fix on the Java side? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> >>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at primekey.se Tue Apr 20 08:06:36 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Tue, 20 Apr 2010 10:06:36 +0200 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BCCA55C.3@oracle.com> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> <4BB3F01F.6080504@oracle.com> <4BCC157E.8010902@primekey.se> <20100419150456.CA590C3A9A@mail.primekey.se> <4BCCA55C.3@oracle.com> Message-ID: <4BCD608C.4070600@primekey.se> Hi here are some more detailed testing results. Tested on one of the most common HSMs, a SafeNet Luna SA. If it would be of interest for you I could use pkcs11-spy to log the exact PKCS11 calls that are passed. 1) When simply generating keys without a PKCS11 config file, the key generation works but when we try to use the key to create a self signed certificate (so use in setKeyEntry and keyStore.store) the following error is thrown. ----- Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT at sun.security.pkcs11.wrapper.PKCS11.C_SignFinal(Native Method) at sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:462) ... 14 more ----- 2) We have earlier resolved this by using a PKCS11 config file: ----- name=Luna library=/usr/lunasa/lib/libCryptoki2_64.so slot = 1 attributes(generate,*,*) = { CKA_TOKEN = true } attributes(generate,CKO_PUBLIC_KEY,*) = { CKA_ENCRYPT = true CKA_VERIFY = true CKA_WRAP = true } attributes(generate, CKO_PRIVATE_KEY,*) = { CKA_EXTRACTABLE = false CKA_DECRYPT = true CKA_SIGN = true CKA_UNWRAP = true } ----- This results in everything working, but only the certificate entry gets an alias when we list the objects on the HSM. 3) I modified the PKCS11 config file to remove the CKA_TOKEN, according to your recommendation. ----- name=Luna library=/usr/lunasa/lib/libCryptoki2_64.so slot = 1 attributes(generate,CKO_PUBLIC_KEY,*) = { CKA_ENCRYPT = true CKA_VERIFY = true CKA_WRAP = true } attributes(generate, CKO_PRIVATE_KEY,*) = { CKA_EXTRACTABLE = false CKA_DECRYPT = true CKA_SIGN = true CKA_UNWRAP = true } ----- The results are the same as in 2. Only the certificate has a label when listing the objects in the HSM (with 'cmu list'). Kind regards, Tomas Valerie (Yu-Ching) Peng wrote: > > You can use your custom PKCS11 config and as long as you call the > KeyStore API to store the key (generated as session key) under the > desired alias, it will be saved as a token key as a result. > > Have you tried it and see if this solves your problem? > Valerie > > On 04/19/10 08:08, Tomas Gustavsson wrote: >> If we need it it's usually for all keys, both RSA and EC. >> >> Cheers, >> Tomas >> >> "Michael StJohns" wrote: >> >> >>> At 04:34 AM 4/19/2010, Tomas Gustavsson wrote: >>> >>> >>>> Hi, >>>> Sorry being late, I was away on vacation. >>>> >>>> Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we specify token=false would it still be a token object on the HSM finally? >>>> >>> Yes. The C_CopyObject turns the Session object into a Token object. and that happens as a side effect of the KeyStore.store operation. >>> >>> >>>> For most HSMs we need to use a cusom PCKS11 config file, otherwise it is not possible to generate key because the HSM will throw an error, usually invalid_template. >>>> >>> Does this happen for all keys or just for EC keys? >>> >>> >>> >>>> Cheers, >>>> Tomas >>>> >>>> >>>> Valerie (Yu-Ching) Peng wrote: >>>> >>>>> If the default PKCS11 config is used, I'd expect that KeyPairGenerator to generate a "session" key and then SunPKCS11 keystore impl will do a C_CopyObject(...) w/ the desired alias. >>>>> Is a custom PKCS11 config file used here? If yes, perhaps it specifies that token key be generated for key generation? >>>>> Valerie >>>>> On 03/31/10 17:51, Michael StJohns wrote: >>>>> >>>>>> KeyPairGenerator should be generating a "Session" key pair. >>>>>> >>>>>> When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. >>>>>> >>>>>> Let me look at the code and see what's going on and make further comments tomorrow. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Sorry if I misunderstood you. That is actually exactly how we do it, >>>>>>> >>>>>>> 1. Use KeyPairGenerator with P11 provider to generate key pair. >>>>>>> 2. Create a keystore with the P11 provier. >>>>>>> 3. Generate a self signed certificate. >>>>>>> 4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>>>>>> >>>>>>> The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >>>>>>> 1. Private key - no alias >>>>>>> 2. Public key - no alias >>>>>>> 3. Certificate - myalias >>>>>>> >>>>>>> The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >>>>>>> This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >>>>>>> >>>>>>> If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >>>>>>> >>>>>>> So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >>>>>>> >>>>>>> Cheers, >>>>>>> Tomas >>>>>>> >>>>>>> >>>>>>> On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>> >>>>>>> >>>>>>>> Why do you assume that the key is generated in software? >>>>>>>> You use the KeyGenerator API to generate a key, this key can be >>>>>>>> generated on the HSM if you have SunPKCS11 provider configured to be the >>>>>>>> most preferred provider. This key should actually just encapsulate the >>>>>>>> native key handle (not the actual value/encoding) which you can then >>>>>>>> pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>>>>>>> impl would then take this key object (with the native key handle) and >>>>>>>> create a persistent copy on the HSM with the specified alias. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 03/29/10 22:57, Tomas Gustavsson wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi, thanks for the answer. >>>>>>>>> >>>>>>>>> Generating a key in software and trying to store it on the HSM violates >>>>>>>>> the whole idea of using an HSM. Which is to generate and maintain the >>>>>>>>> keys in the HSM at all times. >>>>>>>>> Most high security policies *requires* that the keys are generated by >>>>>>>>> the HSM, inside the HSM. >>>>>>>>> I also doubt that it would work to store software generated keys using >>>>>>>>> the keytool API. Many HSMs even forbid this, at least when running in >>>>>>>>> strict FIPS mode. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Tomas >>>>>>>>> >>>>>>>>> Valerie Peng wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Have you tried saving that key through the KeyStore API which allows you >>>>>>>>>> to specify an alias? >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Slightly off topic. >>>>>>>>>>> Something I would like to see is API support for setting aliases when >>>>>>>>>>> using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>>>>>>> not allow changing an alias of private keys after they have been >>>>>>>>>>> generated. Since the key pair generator sets a blank alias when using >>>>>>>>>>> PKCS#11, HSM key pairs are left with no alias. >>>>>>>>>>> >>>>>>>>>>> You can set an alias by providing it using pkcs11 attributes through >>>>>>>>>>> the provider, but that alias is provider global (for all generated key >>>>>>>>>>> pairs) which is not very usable. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Tomas >>>>>>>>>>> >>>>>>>>>>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>>>>>>> are constructed using the attributes values associated with the >>>>>>>>>>>> keys/certs. Thus, this is probably due to some problem with the native >>>>>>>>>>>> library which generated the keys/certs. >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>> On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>> >>>>>>>>>>>>> As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>>>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>>>>>> >>>>>>>>>>>>> Is this something we should fix on the Java side? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>>>>> >> >> > From weijun.wang at sun.com Tue Apr 20 11:31:47 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 20 Apr 2010 11:31:47 +0000 Subject: hg: jdk7/tl/jdk: 6944847: native gss lib names on linux Message-ID: <20100420113239.C9A5044628@hg.openjdk.java.net> Changeset: 97fb6f6d230a Author: weijun Date: 2010-04-20 19:30 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/97fb6f6d230a 6944847: native gss lib names on linux Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java + test/sun/security/krb5/Krb5NameEquals.java + test/sun/security/krb5/runNameEquals.sh From chris.hegarty at oracle.com Tue Apr 20 13:57:25 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 20 Apr 2010 14:57:25 +0100 Subject: [security-dev 01563]: Subject lines in security-dev. In-Reply-To: <4B5F4D78.9000700@sun.com> References: <4B5F4D78.9000700@sun.com> Message-ID: <4BCDB2C5.4090400@oracle.com> Brad, Sorry to chime in late, but would it make server side rules/filtering simpler if we added the mailing list name in the subject line? The reason I ask is that since moving to a new mail server I can no longer create filters on the 'sender' ( or any other more exotic ) headers. This makes filtering a real pain for messages coming from the openjdk mailing lists. If the mailing list name was in the subject line... Of course I would need all the mailing lists I'm subscribed to to do the same. -Chris. Brad Wetmore wrote: > Looking for opinions as to whether the current subject line format of > the security-dev at o.j.n emails is useful: > > Subject: [security-dev 01800]: The Real subject. > > I note a lot of the client (e.g. sounds, swing) lists have just the list > name, and a lot of the server lists (e.g. tl, hotspot) don't have > either. security-dev is the only one doing both the list name and the > message number. It's not as useful as I originally thought when I > configured it, but I could be talked into it either way. > > If you have an opinion, especially for keeping it the same, let me know > privately, no need to clutter everyone's email. But I'm thinking I may > just remove the topic/number. If I see a clear/obvious preference for > keeping one or both, I'll certainly take that into consideration. > > Thanks, > Brad > security-dev admin > > From mstjohns at comcast.net Tue Apr 20 17:08:40 2010 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 20 Apr 2010 13:08:40 -0400 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BCD608C.4070600@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> <4BB3F01F.6080504@oracle.com> <4BCC157E.8010902@primekey.se> <20100419150456.CA590C3A9A@mail.primekey.se> <4BCCA55C.3@oracle.com> <4BCD608C.4070600@primekey.se> Message-ID: <20100420170847.0C30B6A74@mail.openjdk.java.net> This is kind of a strange error message. It generally gets issued when a key type and a mechanism don't agree. Moving the key from a session key to a token key basically changes the key from ephemeral to permanent - so not sure what's going on here. I note that you have more than just CKA_TOKEN=true going on here. Do you still have the exact problem if you delete just the CKA_TOKEN=true line/attribute group? It's possible that the thing that solved the problem is the CKA_SIGN=true in the private key space. There's a useful module that's part of opensc www.opensc-project.org - pkcs11-spy. (Browse source to trunk/src/pkcs11/pkcs11-spy. It acts as a shim between a program and a real PKCS11 module to allow you to wiretap the interactions. I'd be interested in seeing exactly what the differences are in the PKCS11 arguments between the with and without CKA_TOKEN=true. With respect to matching up the keys and certs - look at the CKA_ID attribute. The value for that attribute should be common across the cert, private and public key after a store. Mike [Should we take this offline? May be out of scope for security-dev] At 04:06 AM 4/20/2010, Tomas Gustavsson wrote: >Hi here are some more detailed testing results. > >Tested on one of the most common HSMs, a SafeNet Luna SA. > >If it would be of interest for you I could use pkcs11-spy to log the exact PKCS11 calls that are passed. > >1) >When simply generating keys without a PKCS11 config file, the key generation works but when we try to use the key to create a self signed certificate (so use in setKeyEntry and keyStore.store) the following error is thrown. >----- >Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT > at sun.security.pkcs11.wrapper.PKCS11.C_SignFinal(Native Method) > at sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:462) > ... 14 more >----- > >2) >We have earlier resolved this by using a PKCS11 config file: >----- >name=Luna >library=/usr/lunasa/lib/libCryptoki2_64.so >slot = 1 > >attributes(generate,*,*) = { > CKA_TOKEN = true >} >attributes(generate,CKO_PUBLIC_KEY,*) = { > CKA_ENCRYPT = true > CKA_VERIFY = true > CKA_WRAP = true >} >attributes(generate, CKO_PRIVATE_KEY,*) = { > CKA_EXTRACTABLE = false > CKA_DECRYPT = true > CKA_SIGN = true > CKA_UNWRAP = true >} > >----- > >This results in everything working, but only the certificate entry gets an alias when we list the objects on the HSM. > >3) >I modified the PKCS11 config file to remove the CKA_TOKEN, according to your recommendation. >----- >name=Luna >library=/usr/lunasa/lib/libCryptoki2_64.so >slot = 1 > >attributes(generate,CKO_PUBLIC_KEY,*) = { > CKA_ENCRYPT = true > CKA_VERIFY = true > CKA_WRAP = true >} >attributes(generate, CKO_PRIVATE_KEY,*) = { > CKA_EXTRACTABLE = false > CKA_DECRYPT = true > CKA_SIGN = true > CKA_UNWRAP = true >} >----- > >The results are the same as in 2. Only the certificate has a label when listing the objects in the HSM (with 'cmu list'). > >Kind regards, >Tomas > > >Valerie (Yu-Ching) Peng wrote: >>You can use your custom PKCS11 config and as long as you call the KeyStore API to store the key (generated as session key) under the desired alias, it will be saved as a token key as a result. >>Have you tried it and see if this solves your problem? >>Valerie >>On 04/19/10 08:08, Tomas Gustavsson wrote: >>>If we need it it's usually for all keys, both RSA and EC. >>> >>>Cheers, >>>Tomas >>> >>>"Michael StJohns" wrote: >>> >>> >>>>At 04:34 AM 4/19/2010, Tomas Gustavsson wrote: >>>> >>>> >>>>>Hi, >>>>>Sorry being late, I was away on vacation. >>>>> >>>>>Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we specify token=false would it still be a token object on the HSM finally? >>>>> >>>>Yes. The C_CopyObject turns the Session object into a Token object. and that happens as a side effect of the KeyStore.store operation. >>>> >>>> >>>>>For most HSMs we need to use a cusom PCKS11 config file, otherwise it is not possible to generate key because the HSM will throw an error, usually invalid_template. >>>>> >>>>Does this happen for all keys or just for EC keys? >>>> >>>> >>>> >>>>>Cheers, >>>>>Tomas >>>>> >>>>> >>>>>Valerie (Yu-Ching) Peng wrote: >>>>> >>>>>>If the default PKCS11 config is used, I'd expect that KeyPairGenerator to generate a "session" key and then SunPKCS11 keystore impl will do a C_CopyObject(...) w/ the desired alias. >>>>>>Is a custom PKCS11 config file used here? If yes, perhaps it specifies that token key be generated for key generation? >>>>>>Valerie >>>>>>On 03/31/10 17:51, Michael StJohns wrote: >>>>>> >>>>>>>KeyPairGenerator should be generating a "Session" key pair. >>>>>>> >>>>>>>When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. >>>>>>> >>>>>>>Let me look at the code and see what's going on and make further comments tomorrow. >>>>>>> >>>>>>>Mike >>>>>>> >>>>>>> >>>>>>>At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi, >>>>>>>> >>>>>>>>Sorry if I misunderstood you. That is actually exactly how we do it, >>>>>>>> >>>>>>>>1. Use KeyPairGenerator with P11 provider to generate key pair. >>>>>>>>2. Create a keystore with the P11 provier. >>>>>>>>3. Generate a self signed certificate. >>>>>>>>4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>>>>>>> >>>>>>>>The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >>>>>>>>1. Private key - no alias >>>>>>>>2. Public key - no alias >>>>>>>>3. Certificate - myalias >>>>>>>> >>>>>>>>The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >>>>>>>>This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >>>>>>>> >>>>>>>>If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >>>>>>>> >>>>>>>>So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >>>>>>>> >>>>>>>>Cheers, >>>>>>>>Tomas >>>>>>>> >>>>>>>> >>>>>>>>On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>>> >>>>>>>> >>>>>>>>>Why do you assume that the key is generated in software? >>>>>>>>>You use the KeyGenerator API to generate a key, this key can be >>>>>>>>>generated on the HSM if you have SunPKCS11 provider configured to be the >>>>>>>>>most preferred provider. This key should actually just encapsulate the >>>>>>>>>native key handle (not the actual value/encoding) which you can then >>>>>>>>>pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>>>>>>>>impl would then take this key object (with the native key handle) and >>>>>>>>>create a persistent copy on the HSM with the specified alias. >>>>>>>>> >>>>>>>>>Regards, >>>>>>>>>Valerie >>>>>>>>> >>>>>>>>>On 03/29/10 22:57, Tomas Gustavsson wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>Hi, thanks for the answer. >>>>>>>>>> >>>>>>>>>>Generating a key in software and trying to store it on the HSM violates >>>>>>>>>>the whole idea of using an HSM. Which is to generate and maintain the >>>>>>>>>>keys in the HSM at all times. >>>>>>>>>>Most high security policies *requires* that the keys are generated by >>>>>>>>>>the HSM, inside the HSM. >>>>>>>>>>I also doubt that it would work to store software generated keys using >>>>>>>>>>the keytool API. Many HSMs even forbid this, at least when running in >>>>>>>>>>strict FIPS mode. >>>>>>>>>> >>>>>>>>>>Regards, >>>>>>>>>>Tomas >>>>>>>>>> >>>>>>>>>>Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Have you tried saving that key through the KeyStore API which allows you >>>>>>>>>>>to specify an alias? >>>>>>>>>>>Thanks, >>>>>>>>>>>Valerie >>>>>>>>>>> >>>>>>>>>>>On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>Slightly off topic. >>>>>>>>>>>>Something I would like to see is API support for setting aliases when >>>>>>>>>>>>using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>>>>>>>>not allow changing an alias of private keys after they have been >>>>>>>>>>>>generated. Since the key pair generator sets a blank alias when using >>>>>>>>>>>>PKCS#11, HSM key pairs are left with no alias. >>>>>>>>>>>> >>>>>>>>>>>>You can set an alias by providing it using pkcs11 attributes through >>>>>>>>>>>>the provider, but that alias is provider global (for all generated key >>>>>>>>>>>>pairs) which is not very usable. >>>>>>>>>>>> >>>>>>>>>>>>Regards, >>>>>>>>>>>>Tomas >>>>>>>>>>>> >>>>>>>>>>>>On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>>>>>>>>are constructed using the attributes values associated with the >>>>>>>>>>>>>keys/certs. Thus, this is probably due to some problem with the native >>>>>>>>>>>>>library which generated the keys/certs. >>>>>>>>>>>>>Valerie >>>>>>>>>>>>> >>>>>>>>>>>>>On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>Hi Valerie >>>>>>>>>>>>>> >>>>>>>>>>>>>>As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>>>>>>>customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>>>>>>> >>>>>>>>>>>>>>Is this something we should fix on the Java side? >>>>>>>>>>>>>> >>>>>>>>>>>>>>Thanks >>>>>>>>>>>>>>Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>> >>> >>> From valerie.peng at oracle.com Tue Apr 20 18:57:08 2010 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 20 Apr 2010 11:57:08 -0700 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BCD608C.4070600@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> <4BB3F01F.6080504@oracle.com> <4BCC157E.8010902@primekey.se> <20100419150456.CA590C3A9A@mail.primekey.se> <4BCCA55C.3@oracle.com> <4BCD608C.4070600@primekey.se> Message-ID: <4BCDF904.60502@oracle.com> Hmm, can you log the exact PKCS11 calls as well as setting this debugging option "-Djava.security.debug=pkcs11keystore" when launching your program w/ both (2) and (3)? Thanks, Valerie On 04/20/10 01:06, Tomas Gustavsson wrote: > > Hi here are some more detailed testing results. > > Tested on one of the most common HSMs, a SafeNet Luna SA. > > If it would be of interest for you I could use pkcs11-spy to log the > exact PKCS11 calls that are passed. > > 1) > When simply generating keys without a PKCS11 config file, the key > generation works but when we try to use the key to create a self > signed certificate (so use in setKeyEntry and keyStore.store) the > following error is thrown. > ----- > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: > CKR_KEY_TYPE_INCONSISTENT > at sun.security.pkcs11.wrapper.PKCS11.C_SignFinal(Native Method) > at sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:462) > ... 14 more > ----- > > 2) > We have earlier resolved this by using a PKCS11 config file: > ----- > name=Luna > library=/usr/lunasa/lib/libCryptoki2_64.so > slot = 1 > > attributes(generate,*,*) = { > CKA_TOKEN = true > } > attributes(generate,CKO_PUBLIC_KEY,*) = { > CKA_ENCRYPT = true > CKA_VERIFY = true > CKA_WRAP = true > } > attributes(generate, CKO_PRIVATE_KEY,*) = { > CKA_EXTRACTABLE = false > CKA_DECRYPT = true > CKA_SIGN = true > CKA_UNWRAP = true > } > > ----- > > This results in everything working, but only the certificate entry > gets an alias when we list the objects on the HSM. > > 3) > I modified the PKCS11 config file to remove the CKA_TOKEN, according > to your recommendation. > ----- > name=Luna > library=/usr/lunasa/lib/libCryptoki2_64.so > slot = 1 > > attributes(generate,CKO_PUBLIC_KEY,*) = { > CKA_ENCRYPT = true > CKA_VERIFY = true > CKA_WRAP = true > } > attributes(generate, CKO_PRIVATE_KEY,*) = { > CKA_EXTRACTABLE = false > CKA_DECRYPT = true > CKA_SIGN = true > CKA_UNWRAP = true > } > ----- > > The results are the same as in 2. Only the certificate has a label > when listing the objects in the HSM (with 'cmu list'). > > Kind regards, > Tomas > > > Valerie (Yu-Ching) Peng wrote: >> >> You can use your custom PKCS11 config and as long as you call the >> KeyStore API to store the key (generated as session key) under the >> desired alias, it will be saved as a token key as a result. >> >> Have you tried it and see if this solves your problem? >> Valerie >> >> On 04/19/10 08:08, Tomas Gustavsson wrote: >>> If we need it it's usually for all keys, both RSA and EC. >>> >>> Cheers, >>> Tomas >>> >>> "Michael StJohns" wrote: >>> >>> >>>> At 04:34 AM 4/19/2010, Tomas Gustavsson wrote: >>>> >>>> >>>>> Hi, >>>>> Sorry being late, I was away on vacation. >>>>> >>>>> Yes in most cases we do use a custom PKCS11 config fil, with >>>>> token=yes. If we specify token=false would it still be a token >>>>> object on the HSM finally? >>>>> >>>> Yes. The C_CopyObject turns the Session object into a Token >>>> object. and that happens as a side effect of the KeyStore.store >>>> operation. >>>> >>>> >>>>> For most HSMs we need to use a cusom PCKS11 config file, otherwise >>>>> it is not possible to generate key because the HSM will throw an >>>>> error, usually invalid_template. >>>>> >>>> Does this happen for all keys or just for EC keys? >>>> >>>> >>>> >>>>> Cheers, >>>>> Tomas >>>>> >>>>> >>>>> Valerie (Yu-Ching) Peng wrote: >>>>> >>>>>> If the default PKCS11 config is used, I'd expect that >>>>>> KeyPairGenerator to generate a "session" key and then SunPKCS11 >>>>>> keystore impl will do a C_CopyObject(...) w/ the desired alias. >>>>>> Is a custom PKCS11 config file used here? If yes, perhaps it >>>>>> specifies that token key be generated for key generation? >>>>>> Valerie >>>>>> On 03/31/10 17:51, Michael StJohns wrote: >>>>>> >>>>>>> KeyPairGenerator should be generating a "Session" key pair. >>>>>>> >>>>>>> When you write the key store object, the underlying function >>>>>>> should do a C_CopyObject from the Session object to a Token >>>>>>> object. (Or from a software key to a Token object). At that >>>>>>> point, the template provided to C_CopyObject should be able to >>>>>>> reset the CKA_LABEL attribute to the alias. >>>>>>> >>>>>>> Let me look at the code and see what's going on and make further >>>>>>> comments tomorrow. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Sorry if I misunderstood you. That is actually exactly how we >>>>>>>> do it, >>>>>>>> >>>>>>>> 1. Use KeyPairGenerator with P11 provider to generate key pair. >>>>>>>> 2. Create a keystore with the P11 provier. >>>>>>>> 3. Generate a self signed certificate. >>>>>>>> 4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>>>>>>> >>>>>>>> The keys work fine to use in java. The issue is that in the HSM >>>>>>>> three objects are generated/stored. >>>>>>>> 1. Private key - no alias >>>>>>>> 2. Public key - no alias >>>>>>>> 3. Certificate - myalias >>>>>>>> >>>>>>>> The reason for this is that the alias of the private and public >>>>>>>> keys are set in the HSM when the keys are generated (with the >>>>>>>> KeyPairGenerator). The HSMs do not allow an alias of a private >>>>>>>> key (in particular) to be changed after generation, so >>>>>>>> setKeyEntry can not change the empty alias of the private key >>>>>>>> object. >>>>>>>> This has been confirmed by technicians at AEP, but it works the >>>>>>>> same in nCipher, SafeNet and Utimaco, i.e. no alias on the >>>>>>>> private key object. >>>>>>>> >>>>>>>> If we want to use HSM vendors tools to manipulate objects this >>>>>>>> usually causes problems because they mostly rely on an alias. >>>>>>>> >>>>>>>> So finally :-) this is why an alias parameter to >>>>>>>> KeyPairGenerator would be useful. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Tomas >>>>>>>> >>>>>>>> >>>>>>>> On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>>> >>>>>>>>> Why do you assume that the key is generated in software? >>>>>>>>> You use the KeyGenerator API to generate a key, this key can be >>>>>>>>> generated on the HSM if you have SunPKCS11 provider configured >>>>>>>>> to be the >>>>>>>>> most preferred provider. This key should actually just >>>>>>>>> encapsulate the >>>>>>>>> native key handle (not the actual value/encoding) which you >>>>>>>>> can then >>>>>>>>> pass it to the KeyStore API and specify an alias. The PKCS11 >>>>>>>>> keystore >>>>>>>>> impl would then take this key object (with the native key >>>>>>>>> handle) and >>>>>>>>> create a persistent copy on the HSM with the specified alias. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 03/29/10 22:57, Tomas Gustavsson wrote: >>>>>>>>> >>>>>>>>>> Hi, thanks for the answer. >>>>>>>>>> >>>>>>>>>> Generating a key in software and trying to store it on the >>>>>>>>>> HSM violates >>>>>>>>>> the whole idea of using an HSM. Which is to generate and >>>>>>>>>> maintain the >>>>>>>>>> keys in the HSM at all times. >>>>>>>>>> Most high security policies *requires* that the keys are >>>>>>>>>> generated by >>>>>>>>>> the HSM, inside the HSM. >>>>>>>>>> I also doubt that it would work to store software generated >>>>>>>>>> keys using >>>>>>>>>> the keytool API. Many HSMs even forbid this, at least when >>>>>>>>>> running in >>>>>>>>>> strict FIPS mode. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Tomas >>>>>>>>>> >>>>>>>>>> Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Have you tried saving that key through the KeyStore API >>>>>>>>>>> which allows you >>>>>>>>>>> to specify an alias? >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Slightly off topic. >>>>>>>>>>>> Something I would like to see is API support for setting >>>>>>>>>>>> aliases when >>>>>>>>>>>> using the KeyPairGenerator. This is due to the fact that >>>>>>>>>>>> many HSMs do >>>>>>>>>>>> not allow changing an alias of private keys after they have >>>>>>>>>>>> been >>>>>>>>>>>> generated. Since the key pair generator sets a blank alias >>>>>>>>>>>> when using >>>>>>>>>>>> PKCS#11, HSM key pairs are left with no alias. >>>>>>>>>>>> >>>>>>>>>>>> You can set an alias by providing it using pkcs11 >>>>>>>>>>>> attributes through >>>>>>>>>>>> the provider, but that alias is provider global (for all >>>>>>>>>>>> generated key >>>>>>>>>>>> pairs) which is not very usable. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Tomas >>>>>>>>>>>> >>>>>>>>>>>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Probably not. Unless explicitly specified through KeyStore >>>>>>>>>>>>> APIs, aliases >>>>>>>>>>>>> are constructed using the attributes values associated >>>>>>>>>>>>> with the >>>>>>>>>>>>> keys/certs. Thus, this is probably due to some problem >>>>>>>>>>>>> with the native >>>>>>>>>>>>> library which generated the keys/certs. >>>>>>>>>>>>> Valerie >>>>>>>>>>>>> >>>>>>>>>>>>> On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>>> >>>>>>>>>>>>>> As described >>>>>>>>>>>>>> inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>>>>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this something we should fix on the Java side? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>> >>> >>> >> From dbhole at redhat.com Tue Apr 20 20:49:55 2010 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 20 Apr 2010 16:49:55 -0400 Subject: Permission resolution issues with jar protocol Message-ID: <20100420204954.GB10728@redhat.com> Hi, I work for Red Hat in the Java team. We have come across a problem with permission resolution for urls using the jar protocol. Please see: https://bugs.openjdk.java.net/show_bug.cgi?id=100142 for more information, including a standalone test case. Only OpenJDK seems to be affected. Oracle/Sun JDK resolves permissions correctly. Cheers, Deepak From bradford.wetmore at oracle.com Tue Apr 20 21:25:32 2010 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Tue, 20 Apr 2010 21:25:32 +0000 Subject: hg: jdk7/tl/jdk: 6945604: wrong error message in CardImpl.java Message-ID: <20100420212638.5B2D14462F@hg.openjdk.java.net> Changeset: d8ad2da3ecf3 Author: wetmore Date: 2010-04-20 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8ad2da3ecf3 6945604: wrong error message in CardImpl.java Reviewed-by: mullan ! src/share/classes/sun/security/smartcardio/CardImpl.java From bradford.wetmore at oracle.com Tue Apr 20 21:48:35 2010 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 20 Apr 2010 14:48:35 -0700 Subject: Support for TLS 1.1 & 1.2 In-Reply-To: References: Message-ID: <4BCE2133.30106@oracle.com> Christian/Christopher and any others, On 1/7/2010 8:47 AM, Christopher Wood ( Ottawa ) wrote: > 1. In a previous email (January 2008) ...referring to Christian's email... http://mail.openjdk.java.net/pipermail/security-dev/2008-January/000054.html > asked about support for > TLS 1.1. The reply indicated that it was planned for J2SE 7 and that > the implementation was in progress; is that still the case? We had made some progress, but some higher-priority issues came up and it got back-burnered. > 2. Are there any plans to support TLS 1.2? If so, in what release and > timeframe? With all the transitions going on around here, we're now regrouping on the question of *BOTH* TLS 1.1 and 1.2 support. We're going to be re-proposing TLS 1.1/1.2 for a future JDK release. We've been pulling together our own reasons, but having actual customer feedback will help our case for completing this work. Any information you can supply about your needs may be added to our proposal. Feel free to reply directly to me if you'd rather not discuss your needs in a public forum. Thanks, Brad From Weijun.Wang at Sun.COM Wed Apr 21 03:56:20 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Wed, 21 Apr 2010 11:56:20 +0800 Subject: code review request: 6856069 PrincipalName.clone() does not invoke super.clone() References: <13011608.1246347690055.JavaMail.sbladm@swsblss4-new> Message-ID: <798ED9B5-90E1-4EBB-BEA9-EE6C0C58CD37@Sun.COM> Hi Anyone can review this code change? http://cr.openjdk.java.net/~weijun/6856069/webrev.00/ Thanks Max Begin forwarded message: > *Change Request ID*: 6856069 > *Synopsis*: PrincipalName.clone() does not invoke super.clone() > > === *Description* ============================================================ > PrincipalName's clone() method does not invoke super.clone(), and it has a child class ServiceName. This means the clone of a ServiceName object is not of type ServiceName. > > See "Effective Java" Item 10. > > *** (#1 of 1): 2009-06-30 07:34:10 GMT+00:00 weijun.wang at sun.com From chris.hegarty at oracle.com Wed Apr 21 10:53:18 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 21 Apr 2010 11:53:18 +0100 Subject: code review request: 6856069 PrincipalName.clone() does not invoke super.clone() In-Reply-To: <798ED9B5-90E1-4EBB-BEA9-EE6C0C58CD37@Sun.COM> References: <13011608.1246347690055.JavaMail.sbladm@swsblss4-new> <798ED9B5-90E1-4EBB-BEA9-EE6C0C58CD37@Sun.COM> Message-ID: <4BCED91E.8000609@oracle.com> Max, Good catch to find this bug! Some comments: 1) I don't get why salt now becomes transient. I don't see that it has any effect on how the object is cloned and class is not Serializable. 2) You should be able to remove L128 in the new file. The cloned object will have same value for nameType, and since it is a primitive there shouldn't be an issue. 3) You should be able to replace the arraycopy with nameStrings.clone(). The array elements are immutable Strings, right? -Chris. On 21/04/2010 04:56, Weijun Wang wrote: > Hi > > Anyone can review this code change? > > http://cr.openjdk.java.net/~weijun/6856069/webrev.00/ > > Thanks > Max > > Begin forwarded message: > >> *Change Request ID*: 6856069 >> *Synopsis*: PrincipalName.clone() does not invoke super.clone() >> >> === *Description* ============================================================ >> PrincipalName's clone() method does not invoke super.clone(), and it has a child class ServiceName. This means the clone of a ServiceName object is not of type ServiceName. >> >> See "Effective Java" Item 10. >> >> *** (#1 of 1): 2009-06-30 07:34:10 GMT+00:00 weijun.wang at sun.com > From maurizio.cimadamore at sun.com Wed Apr 21 11:25:00 2010 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 21 Apr 2010 11:25:00 +0000 Subject: hg: jdk7/tl/langtools: 6730476: invalid "unchecked generic array" warning Message-ID: <20100421112508.4FF4C44640@hg.openjdk.java.net> Changeset: 04cf82179fa7 Author: mcimadamore Date: 2010-04-21 12:24 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/04cf82179fa7 6730476: invalid "unchecked generic array" warning Summary: Reifiable-ness of varargs element type should be checked after JLS3 15.12.2.8 Reviewed-by: jjg ! 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/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/6730476/T6730476a.java + test/tools/javac/varargs/6730476/T6730476b.java From Weijun.Wang at Sun.COM Wed Apr 21 11:24:48 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Wed, 21 Apr 2010 19:24:48 +0800 Subject: code review request: 6856069 PrincipalName.clone() does not invoke super.clone() In-Reply-To: <4BCED91E.8000609@oracle.com> References: <13011608.1246347690055.JavaMail.sbladm@swsblss4-new> <798ED9B5-90E1-4EBB-BEA9-EE6C0C58CD37@Sun.COM> <4BCED91E.8000609@oracle.com> Message-ID: On Apr 21, 2010, at 6:53 PM, Chris Hegarty wrote: > Max, > > Good catch to find this bug! > > Some comments: > 1) I don't get why salt now becomes transient. I don't see that it has > any effect on how the object is cloned and class is not Serializable. Reversed. I just had a habit to mark all non-core data as transient, be it in serialization or clone. Not necessary anyway. > > 2) You should be able to remove L128 in the new file. The cloned object > will have same value for nameType, and since it is a primitive there > shouldn't be an issue. > > 3) You should be able to replace the arraycopy with nameStrings.clone(). > The array elements are immutable Strings, right? Correct! Webrev updated at -- http://cr.openjdk.java.net/~weijun/6856069/webrev.01/ Thanks Max P.S. Oh I hate the latest Google Chrome browser removes http:// in the address bar: have to manually add here. > > -Chris. > > On 21/04/2010 04:56, Weijun Wang wrote: >> Hi >> >> Anyone can review this code change? >> >> http://cr.openjdk.java.net/~weijun/6856069/webrev.00/ >> >> Thanks >> Max >> >> Begin forwarded message: >> >>> *Change Request ID*: 6856069 >>> *Synopsis*: PrincipalName.clone() does not invoke super.clone() >>> >>> === *Description* ============================================================ >>> PrincipalName's clone() method does not invoke super.clone(), and it has a child class ServiceName. This means the clone of a ServiceName object is not of type ServiceName. >>> >>> See "Effective Java" Item 10. >>> >>> *** (#1 of 1): 2009-06-30 07:34:10 GMT+00:00 weijun.wang at sun.com >> From chris.hegarty at oracle.com Wed Apr 21 12:11:37 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 21 Apr 2010 13:11:37 +0100 Subject: code review request: 6856069 PrincipalName.clone() does not invoke super.clone() In-Reply-To: References: <13011608.1246347690055.JavaMail.sbladm@swsblss4-new> <798ED9B5-90E1-4EBB-BEA9-EE6C0C58CD37@Sun.COM> <4BCED91E.8000609@oracle.com> Message-ID: <4BCEEB79.9010706@oracle.com> On 21/04/2010 12:24, Weijun Wang wrote: > > On Apr 21, 2010, at 6:53 PM, Chris Hegarty wrote: > >> Max, >> >> Good catch to find this bug! >> >> Some comments: >> 1) I don't get why salt now becomes transient. I don't see that it has >> any effect on how the object is cloned and class is not Serializable. > > Reversed. I just had a habit to mark all non-core data as transient, be it in serialization or clone. Not necessary anyway. > >> >> 2) You should be able to remove L128 in the new file. The cloned object >> will have same value for nameType, and since it is a primitive there >> shouldn't be an issue. >> >> 3) You should be able to replace the arraycopy with nameStrings.clone(). >> The array elements are immutable Strings, right? > > Correct! > > Webrev updated at -- > > http://cr.openjdk.java.net/~weijun/6856069/webrev.01/ Thanks Max, this looks much cleaner now. -Chris. > > Thanks > Max > > P.S. Oh I hate the latest Google Chrome browser removes http:// in the address bar: have to manually add here. > >> >> -Chris. >> >> On 21/04/2010 04:56, Weijun Wang wrote: >>> Hi >>> >>> Anyone can review this code change? >>> >>> http://cr.openjdk.java.net/~weijun/6856069/webrev.00/ >>> >>> Thanks >>> Max >>> >>> Begin forwarded message: >>> >>>> *Change Request ID*: 6856069 >>>> *Synopsis*: PrincipalName.clone() does not invoke super.clone() >>>> >>>> === *Description* ============================================================ >>>> PrincipalName's clone() method does not invoke super.clone(), and it has a child class ServiceName. This means the clone of a ServiceName object is not of type ServiceName. >>>> >>>> See "Effective Java" Item 10. >>>> >>>> *** (#1 of 1): 2009-06-30 07:34:10 GMT+00:00 weijun.wang at sun.com >>> > From David.Holmes at oracle.com Thu Apr 22 03:35:45 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 22 Apr 2010 13:35:45 +1000 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BCF988E.7010002@oracle.com> References: <4BC84D74.5070901@cs.oswego.edu> <4BC85D03.7030909@oracle.com> <4BCF988E.7010002@oracle.com> Message-ID: <4BCFC411.3060500@oracle.com> Jeff I'm a little confused about the reasoning here. I was surprised to discover that the atomic updaters allow you to perform accesses that direct bytecode and reflection do not (perhaps I knew this when we put them together but have since forgotten). So contrary to my expectation that the real checks occurred at set/get and so construction checks were not necessary, it seems that because there are no checks at set/get then construction checks are somewhat pointless anyway. Is that the view here? That the check under question is unnecessarily strict given that we don't perform more obvious checks at get/set time? David Jeff Nisewanger said the following on 04/22/10 10:30: > On 4/16/2010 5:50 AM, David Holmes wrote: >> Hi Doug, >> >> > approval as I'm not a subscriber.> >> >> Doug Lea said the following on 04/16/10 21:43: >>> On 04/15/10 18:34, Martin Buchholz wrote: >>> >>>> People are using Atomic field updaters to update fields in classes >>>> in other classloaders. >>>> >>> >>> I think the policy on this awaits interpretation by Jeff >>> or other members of security team. FWIW, my take is that >>> if users know that they may cross class loaders, then they >>> should wrap these in doPrivileged anyway. As in ... >> >> I'm coming around to agreeing with the proposed fix. My take is that >> the real security check should take place at the time the field is set: >> >> field_x_updater.set(obj, val); >> >> At this point the calling code must have the necessary permissions to >> set field x of the given obj of type T. And I believe we do indeed >> check this. >> >> When the AtomicXXXXFieldUpdater constructor binds itself to the Field >> object for T.x that's an optimization. There's no reason we couldn't >> do this on each call to set() - other than it would perform terribly. >> So in that sense the security checks that take place at construction >> are incidental** and so we should be as permissive as we can make them >> _provided_ that the actual set() call will make the necessary >> permission checks. >> >> ** This particular check is also incidental because we happen to use a >> public reflection method to get the Field object. We could just as >> easily have used a magic VM hook. >> > > This is describing the security checking philosophy of the > java.lang.reflect apis > which mimic the security semantics of static bytecode at the point at > which they > are dynamically invoked. They perform the full security > check on every get() or set() method. This has a substantial performance > penalty > for various reasons but it allows java.lang.reflect.Field instances to > be freely passed > around internally within an application or library's implementation > classes since the > actual security check is against the caller of the get/set() method. > Static bytecode > doesn't have these performance issues since the check is performed once at > constant pool resolution time and the calling point is inherently bound > to that class. > > On the other hand, the java.util.concurrent.atomic APIs were > designed to allow > highly efficient atomic access where performing a full security check on > the set() > method would be a substantial performance burden. Therefore, all of the > access-oriented > security checks are performed at construction time and the set() method > (for example) > only performs type checks to ensure the integrity of the field offset > within the > enclosing object. > > I vaguely recall discussions from years past about the need to > improve the security-relevant > aspects of the javadoc so this distinction would be clear to developers > using the API. > However, I'm not seeing any of this in the jdk 7 docs. This needs to be > fixed. (!) > > The current webrev looks reasonable to me aside from the need to > improve the javadoc. > > > Jeff From jeffrey.nisewanger at oracle.com Mon Apr 19 18:57:05 2010 From: jeffrey.nisewanger at oracle.com (Jeff Nisewanger) Date: Mon, 19 Apr 2010 11:57:05 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: References: <4BC84D74.5070901@cs.oswego.edu> <4BC85D03.7030909@oracle.com> Message-ID: <4BCCA781.8070303@oracle.com> On 4/19/2010 11:23 AM, Martin Buchholz wrote: > Jeff, please review. > > Yes, will do. I was caught up with other things last week. I will try to go through and catch up with this discussion later today. Jeff From jeffrey.nisewanger at oracle.com Thu Apr 22 00:30:06 2010 From: jeffrey.nisewanger at oracle.com (Jeff Nisewanger) Date: Wed, 21 Apr 2010 17:30:06 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BC85D03.7030909@oracle.com> References: <4BC84D74.5070901@cs.oswego.edu> <4BC85D03.7030909@oracle.com> Message-ID: <4BCF988E.7010002@oracle.com> On 4/16/2010 5:50 AM, David Holmes wrote: > Hi Doug, > > approval as I'm not a subscriber.> > > Doug Lea said the following on 04/16/10 21:43: >> On 04/15/10 18:34, Martin Buchholz wrote: >> >>> People are using Atomic field updaters to update fields in classes >>> in other classloaders. >>> >> >> I think the policy on this awaits interpretation by Jeff >> or other members of security team. FWIW, my take is that >> if users know that they may cross class loaders, then they >> should wrap these in doPrivileged anyway. As in ... > > I'm coming around to agreeing with the proposed fix. My take is that > the real security check should take place at the time the field is set: > > field_x_updater.set(obj, val); > > At this point the calling code must have the necessary permissions to > set field x of the given obj of type T. And I believe we do indeed > check this. > > When the AtomicXXXXFieldUpdater constructor binds itself to the Field > object for T.x that's an optimization. There's no reason we couldn't > do this on each call to set() - other than it would perform terribly. > So in that sense the security checks that take place at construction > are incidental** and so we should be as permissive as we can make them > _provided_ that the actual set() call will make the necessary > permission checks. > > ** This particular check is also incidental because we happen to use a > public reflection method to get the Field object. We could just as > easily have used a magic VM hook. > This is describing the security checking philosophy of the java.lang.reflect apis which mimic the security semantics of static bytecode at the point at which they are dynamically invoked. They perform the full security check on every get() or set() method. This has a substantial performance penalty for various reasons but it allows java.lang.reflect.Field instances to be freely passed around internally within an application or library's implementation classes since the actual security check is against the caller of the get/set() method. Static bytecode doesn't have these performance issues since the check is performed once at constant pool resolution time and the calling point is inherently bound to that class. On the other hand, the java.util.concurrent.atomic APIs were designed to allow highly efficient atomic access where performing a full security check on the set() method would be a substantial performance burden. Therefore, all of the access-oriented security checks are performed at construction time and the set() method (for example) only performs type checks to ensure the integrity of the field offset within the enclosing object. I vaguely recall discussions from years past about the need to improve the security-relevant aspects of the javadoc so this distinction would be clear to developers using the API. However, I'm not seeing any of this in the jdk 7 docs. This needs to be fixed. (!) The current webrev looks reasonable to me aside from the need to improve the javadoc. Jeff From weijun.wang at sun.com Thu Apr 22 04:46:57 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 22 Apr 2010 04:46:57 +0000 Subject: hg: jdk7/tl/jdk: 6856069: PrincipalName.clone() does not invoke super.clone() Message-ID: <20100422044716.459B244657@hg.openjdk.java.net> Changeset: edde2f60415b Author: weijun Date: 2010-04-22 12:45 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/edde2f60415b 6856069: PrincipalName.clone() does not invoke super.clone() Reviewed-by: chegar ! src/share/classes/sun/security/krb5/PrincipalName.java + test/sun/security/krb5/ServiceNameClone.java From martinrb at google.com Thu Apr 22 06:09:32 2010 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Apr 2010 23:09:32 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BCF988E.7010002@oracle.com> References: <4BC84D74.5070901@cs.oswego.edu> <4BC85D03.7030909@oracle.com> <4BCF988E.7010002@oracle.com> Message-ID: Jeff, I totally agree with your analysis. I'd like to see better javadoc for java.util.concurrent.atomic in general. I'm not sure I'm the best person to come up with the kind of security-related javadoc we want to see here. The key idea is that, like an instance of Unsafe, an updater is a token that gives its holder special powers to update the field, inherited from the immediate creator of the updater. Martin On Wed, Apr 21, 2010 at 17:30, Jeff Nisewanger wrote: > On 4/16/2010 5:50 AM, David Holmes wrote: >> >> Hi Doug, >> >> > approval as I'm not a subscriber.> >> >> Doug Lea said the following on 04/16/10 21:43: >>> >>> On 04/15/10 18:34, Martin Buchholz wrote: >>> >>>> People are using Atomic field updaters to update fields in classes in >>>> other classloaders. >>>> >>> >>> I think the policy on this awaits interpretation by Jeff >>> or other members of security team. FWIW, my take is that >>> if users know that they may cross class loaders, then they >>> should wrap these in doPrivileged anyway. As in ... >> >> I'm coming around to agreeing with the proposed fix. My take is that the >> real security check should take place at the time the field is set: >> >> ?field_x_updater.set(obj, val); >> >> At this point the calling code must have the necessary permissions to set >> field x of the given obj of type T. And I believe we do indeed check this. >> >> When the AtomicXXXXFieldUpdater constructor binds itself to the Field >> object for T.x that's an optimization. There's no reason we couldn't do this >> on each call to set() - other than it would perform terribly. So in that >> sense the security checks that take place at construction are incidental** >> and so we should be as permissive as we can make them _provided_ that the >> actual set() call will make the necessary permission checks. >> >> ** This particular check is also incidental because we happen to use a >> public reflection method to get the Field object. We could just as easily >> have used a magic VM hook. >> > > ? ?This is describing the security checking philosophy of the > java.lang.reflect apis > which mimic the security semantics of static bytecode at the point at which > they > are dynamically invoked. They perform the full security > check on every get() or set() method. This has a substantial performance > penalty > for various reasons but it allows java.lang.reflect.Field instances to be > freely passed > around internally within an application or library's implementation classes > since the > actual security check is against the caller of the get/set() method. Static > bytecode > doesn't have these performance issues since the check is performed once at > constant pool resolution time and the calling point is inherently bound to > that class. > > ? ?On the other hand, the java.util.concurrent.atomic APIs were designed to > allow > highly efficient atomic access where performing a full security check on the > set() > method would be a substantial performance burden. Therefore, all of the > access-oriented > security checks are performed at construction time and the set() method (for > example) > only performs type checks to ensure the integrity of the field offset within > the > enclosing object. > > ? ?I vaguely recall discussions from years past about the need to improve > the security-relevant > aspects of the javadoc so this distinction would be clear to developers > using the API. > However, I'm not seeing any of this in the jdk 7 docs. This needs to be > fixed. (!) > > ? ?The current webrev looks reasonable to me aside from the need to improve > the javadoc. > > > ? ?Jeff > From Jeff.Nisewanger at Sun.COM Thu Apr 22 22:06:56 2010 From: Jeff.Nisewanger at Sun.COM (Jeff Nisewanger) Date: Thu, 22 Apr 2010 15:06:56 -0700 Subject: Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater In-Reply-To: <4BCFC411.3060500@oracle.com> References: <4BC84D74.5070901@cs.oswego.edu> <4BC85D03.7030909@oracle.com> <4BCF988E.7010002@oracle.com> <4BCFC411.3060500@oracle.com> Message-ID: <4BD0C880.7060604@Sun.COM> On 4/21/2010 8:35 PM, David Holmes wrote: > Jeff I'm a little confused about the reasoning here. I was surprised to > discover that the atomic updaters allow you to perform accesses that > direct bytecode and reflection do not (perhaps I knew this when we put > them together but have since forgotten). So contrary to my expectation > that the real checks occurred at set/get and so construction checks were > not necessary, it seems that because there are no checks at set/get then > construction checks are somewhat pointless anyway. > > Is that the view here? That the check under question is unnecessarily > strict given that we don't perform more obvious checks at get/set time? > Since the checks during get/set() protect only type system integrity it is therefore vital that the access security checks are performed in the constructor. Somewhat similarly, the bytecode verifier protects the type system and the constant pool resolution performs the access security checks for compiled code. My best guess is that the security check implicit in the call to Class.getDeclaredField() wasn't intended when the original code for the AtomicIntegerFieldUpdater constructor was written. I haven't written or tried running any test cases on the current behavior but have just read the implementation code for the constructor. The getDeclaredField() security check ultimately calls SecurityManager.checkMemberAccess() and the javadoc for this says: > The default policy is to allow access to PUBLIC members, as well > as access to classes that have the same class loader as the caller. > In all other cases, this method calls checkPermission with the > RuntimePermission("accessDeclaredMembers") permission. In the case of the constructor for AtomicIntegerFieldUpdaterImpl, the classloader of the caller is the bootstrap loader. Therefore, the RuntimePermission check will be skipped if the class containing the declared field to be updated is a standard JRE class (one also loaded by the bootstrap loader). If the target class is from another classloader (the application or applet loader) then the RuntimePermission check is performed. That doesn't really make any sense as a security check for constructing AtomicIntegerFieldUpdater instances. The behavior of SecurityManager.checkMemberAccess() is intended to limit the ability to introspect on the internal implementation fields and field types of code unrelated to the calling code (code from another classloader). In the case of AtomicIntegerFieldUpdater, the reflective field discovery is an internal intermediate result and the construction does not complete normally unless other security checks validate that the caller of the constructor could have legally accessed the field via static bytecode (assuming the field's declaring class was loadable via the caller's defining class loader). Jeff > > Jeff Nisewanger said the following on 04/22/10 10:30: >> On 4/16/2010 5:50 AM, David Holmes wrote: >>> Hi Doug, >>> >>> >> approval as I'm not a subscriber.> >>> >>> Doug Lea said the following on 04/16/10 21:43: >>>> On 04/15/10 18:34, Martin Buchholz wrote: >>>> >>>>> People are using Atomic field updaters to update fields in classes >>>>> in other classloaders. >>>>> >>>> >>>> I think the policy on this awaits interpretation by Jeff >>>> or other members of security team. FWIW, my take is that >>>> if users know that they may cross class loaders, then they >>>> should wrap these in doPrivileged anyway. As in ... >>> >>> I'm coming around to agreeing with the proposed fix. My take is that >>> the real security check should take place at the time the field is set: >>> >>> field_x_updater.set(obj, val); >>> >>> At this point the calling code must have the necessary permissions to >>> set field x of the given obj of type T. And I believe we do indeed >>> check this. >>> >>> When the AtomicXXXXFieldUpdater constructor binds itself to the Field >>> object for T.x that's an optimization. There's no reason we couldn't >>> do this on each call to set() - other than it would perform terribly. >>> So in that sense the security checks that take place at construction >>> are incidental** and so we should be as permissive as we can make >>> them _provided_ that the actual set() call will make the necessary >>> permission checks. >>> >>> ** This particular check is also incidental because we happen to use >>> a public reflection method to get the Field object. We could just as >>> easily have used a magic VM hook. >>> >> >> This is describing the security checking philosophy of the >> java.lang.reflect apis >> which mimic the security semantics of static bytecode at the point at >> which they >> are dynamically invoked. They perform the full security >> check on every get() or set() method. This has a substantial >> performance penalty >> for various reasons but it allows java.lang.reflect.Field instances to >> be freely passed >> around internally within an application or library's implementation >> classes since the >> actual security check is against the caller of the get/set() method. >> Static bytecode >> doesn't have these performance issues since the check is performed >> once at >> constant pool resolution time and the calling point is inherently >> bound to that class. >> >> On the other hand, the java.util.concurrent.atomic APIs were designed >> to allow >> highly efficient atomic access where performing a full security check >> on the set() >> method would be a substantial performance burden. Therefore, all of >> the access-oriented >> security checks are performed at construction time and the set() >> method (for example) >> only performs type checks to ensure the integrity of the field offset >> within the >> enclosing object. >> >> I vaguely recall discussions from years past about the need to improve >> the security-relevant >> aspects of the javadoc so this distinction would be clear to >> developers using the API. >> However, I'm not seeing any of this in the jdk 7 docs. This needs to >> be fixed. (!) >> >> The current webrev looks reasonable to me aside from the need to >> improve the javadoc. >> >> >> Jeff From alan.bateman at sun.com Sat Apr 24 16:40:28 2010 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Sat, 24 Apr 2010 16:40:28 +0000 Subject: hg: jdk7/tl/corba: 6939646: Remove obsolete com.sun.corba.se.internal.io package Message-ID: <20100424164029.55B224416A@hg.openjdk.java.net> Changeset: cefae6b4a590 Author: alanb Date: 2010-04-24 17:09 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/cefae6b4a590 6939646: Remove obsolete com.sun.corba.se.internal.io package Reviewed-by: ohair ! make/sun/corba/Makefile - make/sun/corba/core/Makefile - make/sun/corba/core/mapfile-vers - src/share/classes/com/sun/corba/se/internal/io/IIOPInputStream.java - src/share/classes/com/sun/corba/se/internal/io/IIOPOutputStream.java - src/share/classes/com/sun/corba/se/internal/io/LibraryManager.java - src/share/classes/com/sun/corba/se/internal/io/ObjectStreamClass.java - src/share/native/com/sun/corba/se/internal/io/ioser.c From ahughes at redhat.com Mon Apr 26 13:10:36 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 26 Apr 2010 14:10:36 +0100 Subject: [security-dev 01563]: Subject lines in security-dev. In-Reply-To: <4BCDB2C5.4090400@oracle.com> References: <4B5F4D78.9000700@sun.com> <4BCDB2C5.4090400@oracle.com> Message-ID: On 20 April 2010 14:57, Chris Hegarty wrote: > Brad, > > Sorry to chime in late, but would it make server side rules/filtering > simpler if we added the mailing list name in the subject line? > > The reason I ask is that since moving to a new mail server I can no longer > create filters on the 'sender' ( or any other more exotic ) headers. This > makes filtering a real pain for messages coming from the openjdk mailing > lists. If the mailing list name was in the subject line... Of course I would > need all the mailing lists I'm subscribed to to do the same. > > -Chris. > > Brad Wetmore wrote: >> >> Looking for opinions as to whether the current subject line format of >> the security-dev at o.j.n emails is useful: >> >> ? ?Subject: [security-dev 01800]: The Real subject. >> >> I note a lot of the client (e.g. sounds, swing) lists have just the list >> name, and a lot of the server lists (e.g. tl, hotspot) don't have >> either. ?security-dev is the only one doing both the list name and the >> message number. ?It's not as useful as I originally thought when I >> configured it, but I could be talked into it either way. >> >> If you have an opinion, especially for keeping it the same, let me know >> privately, no need to clutter everyone's email. ?But I'm thinking I may >> just remove the topic/number. ?If I see a clear/obvious preference for >> keeping one or both, I'll certainly take that into consideration. >> >> Thanks, >> Brad >> security-dev admin >> >> > I think the mailing list name is useful and is used by a number of other lists; with the number of OpenJDK lists, it's nice to be able to see at a glance which one a mail was sent to. I've never seen any use for the number. Indeed, I didn't even know what it meant until this thread. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From chris.hegarty at oracle.com Tue Apr 27 08:44:27 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 27 Apr 2010 08:44:27 +0000 Subject: hg: jdk7/tl/jdk: 6718504: IN6_IS_ADDR_ANY tests only 12 bytes of 16-byte address Message-ID: <20100427084440.6CAE0441AD@hg.openjdk.java.net> Changeset: 0c27202d66c1 Author: chegar Date: 2010-04-27 09:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0c27202d66c1 6718504: IN6_IS_ADDR_ANY tests only 12 bytes of 16-byte address Reviewed-by: alanb ! src/windows/native/java/net/net_util_md.h + test/java/net/DatagramSocket/LocalSocketAddress.java From Weijun.Wang at Sun.COM Tue Apr 27 08:44:32 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Tue, 27 Apr 2010 16:44:32 +0800 Subject: code review request: 6947487: use HexDumpEncoder.encodeBuffer() References: <24646280.1272357678406.JavaMail.sbladm@swsblss3-new> Message-ID: <70FC58C3-00F6-48A1-9415-7AB4A123C714@Sun.COM> Hi Simple fix, webrev at http://cr.openjdk.java.net/~weijun/6947487/webrev.00 Thanks Max Begin forwarded message: > > *Change Request ID*: 6947487 > *Synopsis*: use HexDumpEncoder.encodeBuffer() > > === *Description* ============================================================ > Some security classes use HexDumpEncoder.encode() to output a hexdump of a byte array. This method does not print out the line suffix of the final line. encodeBuffer() should be used instead. > > *** (#1 of 1): 2010-04-27 08:40:31 GMT+00:00 weijun.wang at sun.com From sean.mullan at oracle.com Wed Apr 28 14:10:17 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 28 Apr 2010 10:10:17 -0400 Subject: code review request: 6947487: use HexDumpEncoder.encodeBuffer() In-Reply-To: <70FC58C3-00F6-48A1-9415-7AB4A123C714@Sun.COM> References: <24646280.1272357678406.JavaMail.sbladm@swsblss3-new> <70FC58C3-00F6-48A1-9415-7AB4A123C714@Sun.COM> Message-ID: <4BD841C9.6070103@oracle.com> Looks good to me. --Sean On 4/27/10 4:44 AM, Weijun Wang wrote: > Hi > > Simple fix, webrev at > > http://cr.openjdk.java.net/~weijun/6947487/webrev.00 > > Thanks > Max > > Begin forwarded message: >> >> *Change Request ID*: 6947487 >> *Synopsis*: use HexDumpEncoder.encodeBuffer() >> >> === *Description* ============================================================ >> Some security classes use HexDumpEncoder.encode() to output a hexdump of a byte array. This method does not print out the line suffix of the final line. encodeBuffer() should be used instead. >> >> *** (#1 of 1): 2010-04-27 08:40:31 GMT+00:00 weijun.wang at sun.com > From Weijun.Wang at Sun.COM Thu Apr 29 04:40:48 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Thu, 29 Apr 2010 12:40:48 +0800 Subject: code review request: 6948287 KDC test strange kvno References: <746529.1272514896902.JavaMail.sbladm@swsblss3-new> Message-ID: Hi Please take a review at this test bug: http://cr.openjdk.java.net/~weijun/6948287/webrev.00 Thanks Max > *Change Request ID*: 6948287 > > *Synopsis*: KDC test strange kvno > > Keywords: noreg-self > > === *Description* ============================================================ > In KDC.java test there is a simple contract that when a password ends with a digit, the keys generated should have a key version number as this digit. Sometimes, the randomPassword() method does return such a password and the test gets confused. > > BTW, it's with this bug that I know the following characters are all digits, cool. > > HEX DECIMAL CHAR > 1099 4249 ?? > 17e3 6115 ?? > aa51 43601 ?? Bad, Bugster cannot save my pasted chars. > > *** (#1 of 1): 2010-04-29 04:12:31 GMT+00:00 weijun.wang at sun.com From weijun.wang at sun.com Thu Apr 29 07:52:42 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 29 Apr 2010 07:52:42 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100429075321.E03B4442BF@hg.openjdk.java.net> Changeset: b833a422c776 Author: weijun Date: 2010-04-29 15:50 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b833a422c776 6947487: use HexDumpEncoder.encodeBuffer() Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/javax/security/auth/kerberos/KeyImpl.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/tools/KeyTool.java Changeset: 4c8075f8c0ee Author: weijun Date: 2010-04-29 15:51 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4c8075f8c0ee 6844193: support max_retries in krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbKdcReq.java + test/sun/security/krb5/auto/MaxRetries.java From jonathan.gibbons at sun.com Thu Apr 29 21:26:49 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 29 Apr 2010 21:26:49 +0000 Subject: hg: jdk7/tl/langtools: 6948251: need to quote args in langtools launcher script Message-ID: <20100429212653.A14CC44370@hg.openjdk.java.net> Changeset: 32675c68a3ca Author: jjg Date: 2010-04-29 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/32675c68a3ca 6948251: need to quote args in langtools launcher script Reviewed-by: darcy ! src/share/bin/launcher.sh-template