hg: jdk8/tl/langtools: 3 new changesets
Changeset: bc24411bcc37 Author:katleman Date: 2013-02-14 11:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc24411bcc37 Added tag jdk8-b77 for changeset 89c664151689 ! .hgtags Changeset: a3aa32fe4536 Author:lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a3aa32fe4536 Merge Changeset: 4cf6e84f844f Author:lana Date: 2013-02-19 20:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4cf6e84f844f Merge
hg: jdk8/tl/hotspot: 36 new changesets
Changeset: 1f84c84f8e1a Author:katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f84c84f8e1a Added tag jdk8-b77 for changeset cdb46031e718 ! .hgtags Changeset: 1a0174612b49 Author:amurillo Date: 2013-02-08 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a0174612b49 8007801: new hotspot build - hs25-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8d9fc28831cc Author:dcubed Date: 2013-02-06 14:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d9fc28831cc 7182152: Instrumentation hot swap test incorrect monitor count Summary: Add/refine new tracing support using -XX:TraceRedefineClasses=16384. Reviewed-by: coleenp, acorn, sspitsyn ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 3a88007634b0 Author:ctornqvi Date: 2013-02-08 10:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a88007634b0 8007434: Write tests for 8006298 Summary: Four tests written for 8006298 Reviewed-by: mgerdin, coleenp + test/runtime/CommandLine/BooleanFlagWithInvalidValue.java + test/runtime/CommandLine/FlagWithInvalidValue.java + test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java + test/runtime/CommandLine/UnrecognizedVMOption.java Changeset: 758935f7c23f Author:sla Date: 2013-02-08 12:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/758935f7c23f 8006423: SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) Summary: Do not rely on mach thread port names to identify threads from SA Reviewed-by: dholmes, minqi, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp Changeset: 7194f764221c Author:sla Date: 2013-02-08 14:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7194f764221c Merge Changeset: 461a3adac4d1 Author:sspitsyn Date: 2013-02-08 09:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/461a3adac4d1 Merge ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 8bf62bd86a4e Author:zgu Date: 2013-02-08 14:49 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8bf62bd86a4e 8007791: More Restricted hs_err file permission Summary: Enforce more restricted hs_file permission Reviewed-by: acorn, dcubed, dsamersoff ! src/share/vm/utilities/vmError.cpp Changeset: 1ba5b18088a8 Author:zgu Date: 2013-02-08 14:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ba5b18088a8 Merge Changeset: 41d73c9b30a8 Author:zgu Date: 2013-02-08 16:31 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41d73c9b30a8 8006691: Remove jvm_version_info.is_kernel_jvm field Summary: Removed is_kernel_jvm from jvm_version_info as Kernel VM has been deprecated Reviewed-by: mchung, coleenp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 3f11b37f047c Author:zgu Date: 2013-02-08 13:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f11b37f047c Merge Changeset: f989aff6946f Author:zgu Date: 2013-02-08 16:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f989aff6946f Merge Changeset: 927a311d00f9 Author:coleenp Date: 2013-02-11 14:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/927a311d00f9 8007320: NPG: move method annotations Summary: allocate method annotations and attach to ConstMethod if present Reviewed-by: dcubed, jiangli, sspitsyn, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvm
hg: jdk8/tl: 3 new changesets
Changeset: 45d6d221 Author:katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/45d6d221 Added tag jdk8-b77 for changeset 3933eebc659d ! .hgtags Changeset: bbb7548d45c7 Author:lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bbb7548d45c7 Merge Changeset: eca3bce3d151 Author:lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/eca3bce3d151 Merge
hg: jdk8/tl/jaxws: Added tag jdk8-b77 for changeset 64dfba1bad16
Changeset: 391de4c992d1 Author:katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/391de4c992d1 Added tag jdk8-b77 for changeset 64dfba1bad16 ! .hgtags
hg: jdk8/tl/jaxp: Added tag jdk8-b77 for changeset 573e789c187a
Changeset: 00958c5a7070 Author:katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/00958c5a7070 Added tag jdk8-b77 for changeset 573e789c187a ! .hgtags
hg: jdk8/tl/corba: 2 new changesets
Changeset: 27d6368ae8ba Author:katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/27d6368ae8ba Added tag jdk8-b77 for changeset 35684a40c584 ! .hgtags Changeset: c528d8ce83f1 Author:lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/c528d8ce83f1 Merge
Re: Safe storage of RSA private keys before binding to X.509 cert
Abandon all hope, ye who import sun.* ? :-D On Wed, Feb 20, 2013 at 02:54:08AM +, mstjo...@comcast.net wrote: > Use the source Luke. > > Sent from Comcast mobile > > -Original Message- > From: Matthew Hall > To: mstjohns > Cc: security-dev > Sent: 2013-02-20 02:48:57 + > Subject: Re: Safe storage of RSA private keys before binding to X.509 cert > > How could I do it with the undocumented classes? Muahahahahaha! :) > > On Wed, Feb 20, 2013 at 02:36:26AM +, mstjo...@comcast.net wrote: > > Not using the pkcs11 provider. If you use the (undocumented) wrapper > > classes you can get more direct access to the pkcs11 libraries. Or go with > > the iaik pkcs11 lobs. > >> Sent from Comcast mobile > >> -Original Message- > > From: Matthew Hall > > To: mstjohns > > Cc: security-dev > > Sent: 2013-02-20 02:27:21 + > > Subject: Re: Safe storage of RSA private keys before binding to X.509 cert > >> Is there a more elegant way? > >> On Wed, Feb 20, 2013 at 02:24:40AM +, mstjo...@comcast.net wrote: > >> Store the private key with a self-signed certificate. Replace the cert > >> when it is issued. > >>> Sent from Comcast mobile > >>> -Original Message- > >> From: Matthew Hall > >> To: security-dev > >> Sent: 2013-02-20 00:27:51 + > >> Subject: Safe storage of RSA private keys before binding to X.509 cert > >>> Hello, > >>> I have a question about safely storing RSA private keys while waiting for > >>> a > >> Cerification Request to be processed remotely so a signed X.509 > >> Certificate > >> will be returned. > >>> I want to store it inside the PKCS #11 KeyStore so it will be protected > >>> while > >> we wait for the Certificate to become available, so that both can be bound > >> together and then stored. > >>> However, the KeyStore APIs prevent this from succeeding: > >>> If public final void setKeyEntry(String alias, byte[] key, Certificate[] > >> chain) is used with keyPair.getPrivate().getEncoded(), it throws > >> UnsupportedOperationException. > >>> If public final void setKeyEntry(String alias, Key key, char[] password, > >> Certificate[] chain) is used, it throws > >> java.lang.IllegalArgumentException: > >> Private key must be accompanied by certificate chain. > >>> If one creates a RAW-type SecretKey using SecretKeySpec privateKeySpec = > >>> new > >> SecretKeySpec(privateKeyBytes, "RAW"), and attempts to store the RAW > >> SecretKey, it throws java.security.KeyStoreException: Cannot convert to > >> PKCS11 > >> keys caused by java.security.InvalidKeyException: Unknown algorithm RAW. > >>> How is one supposed to store the RSA PrivateKey in a FIPS-safe way, if > >>> the > >> KeyStore refuses to handle it via any of these APIs? Several threads on > >> StackOverflow also mentioned this issue, with no known workaround. > >>> Regards, > >> Matthew.
Re: Safe storage of RSA private keys before binding to X.509 cert
Use the source Luke. Sent from Comcast mobile -Original Message- From: Matthew Hall To: mstjohns Cc: security-dev Sent: 2013-02-20 02:48:57 + Subject: Re: Safe storage of RSA private keys before binding to X.509 cert How could I do it with the undocumented classes? Muahahahahaha! :) On Wed, Feb 20, 2013 at 02:36:26AM +, mstjo...@comcast.net wrote: > Not using the pkcs11 provider. If you use the (undocumented) wrapper classes > you can get more direct access to the pkcs11 libraries. Or go with the iaik > pkcs11 lobs. >> Sent from Comcast mobile >> -Original Message- > From: Matthew Hall > To: mstjohns > Cc: security-dev > Sent: 2013-02-20 02:27:21 + > Subject: Re: Safe storage of RSA private keys before binding to X.509 cert >> Is there a more elegant way? >> On Wed, Feb 20, 2013 at 02:24:40AM +, mstjo...@comcast.net wrote: >> Store the private key with a self-signed certificate. Replace the cert when >> it is issued. >>> Sent from Comcast mobile >>> -Original Message- >> From: Matthew Hall >> To: security-dev >> Sent: 2013-02-20 00:27:51 + >> Subject: Safe storage of RSA private keys before binding to X.509 cert >>> Hello, >>> I have a question about safely storing RSA private keys while waiting for a >> Cerification Request to be processed remotely so a signed X.509 Certificate >> will be returned. >>> I want to store it inside the PKCS #11 KeyStore so it will be protected >>> while >> we wait for the Certificate to become available, so that both can be bound >> together and then stored. >>> However, the KeyStore APIs prevent this from succeeding: >>> If public final void setKeyEntry(String alias, byte[] key, Certificate[] >> chain) is used with keyPair.getPrivate().getEncoded(), it throws >> UnsupportedOperationException. >>> If public final void setKeyEntry(String alias, Key key, char[] password, >> Certificate[] chain) is used, it throws java.lang.IllegalArgumentException: >> Private key must be accompanied by certificate chain. >>> If one creates a RAW-type SecretKey using SecretKeySpec privateKeySpec = >>> new >> SecretKeySpec(privateKeyBytes, "RAW"), and attempts to store the RAW >> SecretKey, it throws java.security.KeyStoreException: Cannot convert to >> PKCS11 >> keys caused by java.security.InvalidKeyException: Unknown algorithm RAW. >>> How is one supposed to store the RSA PrivateKey in a FIPS-safe way, if the >> KeyStore refuses to handle it via any of these APIs? Several threads on >> StackOverflow also mentioned this issue, with no known workaround. >>> Regards, >> Matthew.
Re: Safe storage of RSA private keys before binding to X.509 cert
How could I do it with the undocumented classes? Muahahahahaha! :) On Wed, Feb 20, 2013 at 02:36:26AM +, mstjo...@comcast.net wrote: > Not using the pkcs11 provider. If you use the (undocumented) wrapper classes > you can get more direct access to the pkcs11 libraries. Or go with the iaik > pkcs11 lobs. > > Sent from Comcast mobile > > -Original Message- > From: Matthew Hall > To: mstjohns > Cc: security-dev > Sent: 2013-02-20 02:27:21 + > Subject: Re: Safe storage of RSA private keys before binding to X.509 cert > > Is there a more elegant way? > > On Wed, Feb 20, 2013 at 02:24:40AM +, mstjo...@comcast.net wrote: > > Store the private key with a self-signed certificate. Replace the cert > > when it is issued. > >> Sent from Comcast mobile > >> -Original Message- > > From: Matthew Hall > > To: security-dev > > Sent: 2013-02-20 00:27:51 + > > Subject: Safe storage of RSA private keys before binding to X.509 cert > >> Hello, > >> I have a question about safely storing RSA private keys while waiting for > >> a > > Cerification Request to be processed remotely so a signed X.509 Certificate > > will be returned. > >> I want to store it inside the PKCS #11 KeyStore so it will be protected > >> while > > we wait for the Certificate to become available, so that both can be bound > > together and then stored. > >> However, the KeyStore APIs prevent this from succeeding: > >> If public final void setKeyEntry(String alias, byte[] key, Certificate[] > > chain) is used with keyPair.getPrivate().getEncoded(), it throws > > UnsupportedOperationException. > >> If public final void setKeyEntry(String alias, Key key, char[] password, > > Certificate[] chain) is used, it throws java.lang.IllegalArgumentException: > > Private key must be accompanied by certificate chain. > >> If one creates a RAW-type SecretKey using SecretKeySpec privateKeySpec = > >> new > > SecretKeySpec(privateKeyBytes, "RAW"), and attempts to store the RAW > > SecretKey, it throws java.security.KeyStoreException: Cannot convert to > > PKCS11 > > keys caused by java.security.InvalidKeyException: Unknown algorithm RAW. > >> How is one supposed to store the RSA PrivateKey in a FIPS-safe way, if the > > KeyStore refuses to handle it via any of these APIs? Several threads on > > StackOverflow also mentioned this issue, with no known workaround. > >> Regards, > > Matthew.
Re: Safe storage of RSA private keys before binding to X.509 cert
Not using the pkcs11 provider. If you use the (undocumented) wrapper classes you can get more direct access to the pkcs11 libraries. Or go with the iaik pkcs11 lobs. Sent from Comcast mobile -Original Message- From: Matthew Hall To: mstjohns Cc: security-dev Sent: 2013-02-20 02:27:21 + Subject: Re: Safe storage of RSA private keys before binding to X.509 cert Is there a more elegant way? On Wed, Feb 20, 2013 at 02:24:40AM +, mstjo...@comcast.net wrote: > Store the private key with a self-signed certificate. Replace the cert when > it is issued. >> Sent from Comcast mobile >> -Original Message- > From: Matthew Hall > To: security-dev > Sent: 2013-02-20 00:27:51 + > Subject: Safe storage of RSA private keys before binding to X.509 cert >> Hello, >> I have a question about safely storing RSA private keys while waiting for a > Cerification Request to be processed remotely so a signed X.509 Certificate > will be returned. >> I want to store it inside the PKCS #11 KeyStore so it will be protected >> while > we wait for the Certificate to become available, so that both can be bound > together and then stored. >> However, the KeyStore APIs prevent this from succeeding: >> If public final void setKeyEntry(String alias, byte[] key, Certificate[] > chain) is used with keyPair.getPrivate().getEncoded(), it throws > UnsupportedOperationException. >> If public final void setKeyEntry(String alias, Key key, char[] password, > Certificate[] chain) is used, it throws java.lang.IllegalArgumentException: > Private key must be accompanied by certificate chain. >> If one creates a RAW-type SecretKey using SecretKeySpec privateKeySpec = new > SecretKeySpec(privateKeyBytes, "RAW"), and attempts to store the RAW > SecretKey, it throws java.security.KeyStoreException: Cannot convert to > PKCS11 > keys caused by java.security.InvalidKeyException: Unknown algorithm RAW. >> How is one supposed to store the RSA PrivateKey in a FIPS-safe way, if the > KeyStore refuses to handle it via any of these APIs? Several threads on > StackOverflow also mentioned this issue, with no known workaround. >> Regards, > Matthew.
Re: Safe storage of RSA private keys before binding to X.509 cert
Is there a more elegant way? On Wed, Feb 20, 2013 at 02:24:40AM +, mstjo...@comcast.net wrote: > Store the private key with a self-signed certificate. Replace the cert when > it is issued. > > Sent from Comcast mobile > > -Original Message- > From: Matthew Hall > To: security-dev > Sent: 2013-02-20 00:27:51 + > Subject: Safe storage of RSA private keys before binding to X.509 cert > > Hello, > > I have a question about safely storing RSA private keys while waiting for a > Cerification Request to be processed remotely so a signed X.509 Certificate > will be returned. > > I want to store it inside the PKCS #11 KeyStore so it will be protected while > we wait for the Certificate to become available, so that both can be bound > together and then stored. > > However, the KeyStore APIs prevent this from succeeding: > > If public final void setKeyEntry(String alias, byte[] key, Certificate[] > chain) is used with keyPair.getPrivate().getEncoded(), it throws > UnsupportedOperationException. > > If public final void setKeyEntry(String alias, Key key, char[] password, > Certificate[] chain) is used, it throws java.lang.IllegalArgumentException: > Private key must be accompanied by certificate chain. > > If one creates a RAW-type SecretKey using SecretKeySpec privateKeySpec = new > SecretKeySpec(privateKeyBytes, "RAW"), and attempts to store the RAW > SecretKey, it throws java.security.KeyStoreException: Cannot convert to > PKCS11 > keys caused by java.security.InvalidKeyException: Unknown algorithm RAW. > > How is one supposed to store the RSA PrivateKey in a FIPS-safe way, if the > KeyStore refuses to handle it via any of these APIs? Several threads on > StackOverflow also mentioned this issue, with no known workaround. > > Regards, > Matthew.
Re: Safe storage of RSA private keys before binding to X.509 cert
Store the private key with a self-signed certificate. Replace the cert when it is issued. Sent from Comcast mobile -Original Message- From: Matthew Hall To: security-dev Sent: 2013-02-20 00:27:51 + Subject: Safe storage of RSA private keys before binding to X.509 cert Hello, I have a question about safely storing RSA private keys while waiting for a Cerification Request to be processed remotely so a signed X.509 Certificate will be returned. I want to store it inside the PKCS #11 KeyStore so it will be protected while we wait for the Certificate to become available, so that both can be bound together and then stored. However, the KeyStore APIs prevent this from succeeding: If public final void setKeyEntry(String alias, byte[] key, Certificate[] chain) is used with keyPair.getPrivate().getEncoded(), it throws UnsupportedOperationException. If public final void setKeyEntry(String alias, Key key, char[] password, Certificate[] chain) is used, it throws java.lang.IllegalArgumentException: Private key must be accompanied by certificate chain. If one creates a RAW-type SecretKey using SecretKeySpec privateKeySpec = new SecretKeySpec(privateKeyBytes, "RAW"), and attempts to store the RAW SecretKey, it throws java.security.KeyStoreException: Cannot convert to PKCS11 keys caused by java.security.InvalidKeyException: Unknown algorithm RAW. How is one supposed to store the RSA PrivateKey in a FIPS-safe way, if the KeyStore refuses to handle it via any of these APIs? Several threads on StackOverflow also mentioned this issue, with no known workaround. Regards, Matthew.
hg: jdk8/tl/langtools: 8006948: Update javac for MethodParameters format change
Changeset: 9345394ac8fe Author:ksrini Date: 2013-02-19 17:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9345394ac8fe 8006948: Update javac for MethodParameters format change Reviewed-by: ksrini, forax Contributed-by: eric.mccor...@oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
hg: jdk8/tl/jdk: 8008262: pack200 should support MethodParameters - part 2
Changeset: ec1a79c3a99c Author:ksrini Date: 2013-02-19 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec1a79c3a99c 8008262: pack200 should support MethodParameters - part 2 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/Utils.java
Re: PKCS #11 provider shutdown process, key zeroization
I found another issue related to this topic.
Quite a number of bits of code are printing out the content of the private
exponent of the RSA Private Keys by default into the toString() output, which
could lead to key compromise if they're printed into a log.
share/classes/sun/security/pkcs11/P11Key.java:552:sb.append("\n
private exponent: ");
share/classes/sun/security/pkcs11/P11Key.java:624:sb.append("\n
private exponent: ");
share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java:238:
sb.append("\n private exponent: ");
share/classes/sun/security/rsa/RSAPrivateKeyImpl.java:105:+ n +
"\n private exponent: " + d;
Ordinarily I believe FIPS and PCI would require that there isn't any code
sitting around that could accidentally or unexpectedly print out the private
key data. Is this toString() behaving that way for a good reason?
Matthew.
Safe storage of RSA private keys before binding to X.509 cert
Hello, I have a question about safely storing RSA private keys while waiting for a Cerification Request to be processed remotely so a signed X.509 Certificate will be returned. I want to store it inside the PKCS #11 KeyStore so it will be protected while we wait for the Certificate to become available, so that both can be bound together and then stored. However, the KeyStore APIs prevent this from succeeding: If public final void setKeyEntry(String alias, byte[] key, Certificate[] chain) is used with keyPair.getPrivate().getEncoded(), it throws UnsupportedOperationException. If public final void setKeyEntry(String alias, Key key, char[] password, Certificate[] chain) is used, it throws java.lang.IllegalArgumentException: Private key must be accompanied by certificate chain. If one creates a RAW-type SecretKey using SecretKeySpec privateKeySpec = new SecretKeySpec(privateKeyBytes, "RAW"), and attempts to store the RAW SecretKey, it throws java.security.KeyStoreException: Cannot convert to PKCS11 keys caused by java.security.InvalidKeyException: Unknown algorithm RAW. How is one supposed to store the RSA PrivateKey in a FIPS-safe way, if the KeyStore refuses to handle it via any of these APIs? Several threads on StackOverflow also mentioned this issue, with no known workaround. Regards, Matthew.
hg: jdk8/tl/jdk: 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
Changeset: 267bca6af07e Author:jzavgren Date: 2013-02-19 15:31 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/267bca6af07e 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Reviewed-by: mullan, chegar ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
hg: jdk8/tl/jdk: 8004561: Additional functional interfaces, extension methods and name changes
Changeset: 16efb7ba188f Author:mduigou Date: 2013-02-19 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16efb7ba188f 8004561: Additional functional interfaces, extension methods and name changes Summary: Adds additional functional interfaces for primitives and "Bi" (two operand). Adds utility extension methods. Includes some name changes for existing functional interfaces per EG decisions. Reviewed-by: briangoetz, darcy, chegar, dholmes ! src/share/classes/java/time/chrono/HijrahDeviationReader.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java + src/share/classes/java/util/function/BiConsumer.java + src/share/classes/java/util/function/BiFunction.java + src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java - src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/BooleanSupplier.java + src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java - src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java - src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java - src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/ObjDoubleConsumer.java + src/share/classes/java/util/function/ObjIntConsumer.java + src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/ToDoubleBiFunction.java + src/share/classes/java/util/function/ToDoubleFunction.java + src/share/classes/java/util/function/ToIntBiFunction.java + src/share/classes/java/util/function/ToIntFunction.java + src/share/classes/java/util/function/ToLongBiFunction.java + src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java ! test/java/lang/PrimitiveSumMinMaxTest.java
PKCS #11 provider shutdown process, key zeroization
Hello,
I am working on a product which uses the Sun PKCS #11 provider. I was curious
how the FIPS mode worked, in particular about the shutdown procedure and
whether or not it performed key and password zeroization, so I was reading
through the OpenJDK 7 trunk version of the implementation code to learn more.
In share/classes/sun/security/pkcs11/wrapper/PKCS11.java we have some
methods:
private static native void finalizeLibrary();
I could not find any code which ever called this method. In
share/native/sun/security/pkcs11/wrapper/p11_general.c, all the implementation
code for this native method is commented out, with an XXX marker but no
explanation why it's commented out.
public native void C_Finalize(Object pReserved) throws PKCS11Exception;
I could not find any code which ever called this either, but at least the
implementation code is not commented out, and looks like it would probably
work if it was called. I believe that this method often implements zeroization
so it seems like it could be an issue if nothing is ever calling this.
/**
* Calls disconnect() to cleanup the native part of the wrapper. Once this
* method is called, this object cannot be used any longer. Any subsequent
* call to a C_* method will result in a runtime exception.
*
* @exception Throwable If finalization fails.
*/
public void finalize() throws Throwable {
disconnect();
}
Next we have the finalizer, which calls the disconnect method. Note that it is
documented as throwing an exception, but any exceptions during finalization
would be ignored and not reported anywhere, which would mean we would not have
a way of knowing that unloading is failing and nothing is getting zeroized
properly. (This is according to Object#finalize documentation).
Is there a way to obtain a reference to the PKCS11 wrapper and call this
function explicitly? I could not find a good way to do it. Since finalize
might never get called if the object never gets unreferences, I can't see how
we could be sure the keys are zeroized right, even if some of the items inside
of disconnect perform the zeroization, which I'm not sure that they do.
/**
* Disconnects the PKCS#11 library from this object. After calling this
* method, this object is no longer connected to a native PKCS#11 module
* and any subsequent calls to C_ methods will fail. This method is for
* internal use only.
* Declared private, because incorrect handling may result in errors in the
* native part.
*
* @preconditions
* @postconditions
*/
private native void disconnect();
Let's take a look at the implementation of disconnect from
solaris/native/sun/security/pkcs11/wrapper/p11_md.c:
/*
* Class: sun_security_pkcs11_wrapper_PKCS11
* Method:disconnect
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_sun_security_pkcs11_wrapper_PKCS11_disconnect
(JNIEnv *env, jobject obj)
{
ModuleData *moduleData;
TRACE0("DEBUG: disconnecting module...");
moduleData = removeModuleEntry(env, obj);
if (moduleData != NULL) {
dlclose(moduleData->hModule);
}
free(moduleData);
TRACE0("FINISHED\n");
}
If you read through removeModuleEntry, the only interesting operation
performed there is:
(*env)->SetLongField(env, pkcs11Implementation, pNativeDataID, 0);
This is setting the pNativeDataID field from the PKCS #11 class to zero.
Then, the higher code in disconnect will dlclose the library. However dlclose
is only reference-counting, and does not guarantee the library will be removed
from memory, or that the removed memory will be zeroized.
In addition if the keys are stored in a dynamic area and not a static area
inside the library, which is what I suspect, they could still be present in
memory after this point, which seems to be against what's required for
zeroization in FIPS.
Therefore I am asking now, if we are sure that the way all of this works will
perform the key zeroization we expect. Can anybody comment on whether this
could be an actual issue or not?
In addition, I noticed there are a number of pieces of code that are zeroizing
keys using \x20 instead of \x00:
share/classes/com/sun/crypto/provider/PBEKey.java:70:
java.util.Arrays.fill(passwd, ' ');
share/classes/com/sun/crypto/provider/PBEKeyFactory.java:151:
java.util.Arrays.fill(passwdChars, ' ');
share/classes/com/sun/jmx/remote/security/FileLoginModule.java:561:
Arrays.fill(password, ' ');
share/classes/com/sun/security/auth/module/LdapLoginModule.java:1000:
Arrays.fill(password, ' ');
share/classes/java/io/Console.java:84: * java.util.Arrays.fill(passwd, ' ');
share/classes/java/io/Console.java:388:Arrays.fill(rcb, 0, len,
' ');
share/classes/java/security/KeyStore.java:297:
Arrays.fill(password, ' ');
share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java:91:
if (password != null) Arrays.fill(password, ' ');
share/classes
Re: RFR: JDK-8007607
- The implementation of throwByName(...) and throwOutOfMemory(...)
should be moved to NativeUtil.c as that's where most if not all the
utility functions are held.
- I think it's better to move the block of code from line 330 to 333 to
before the initGSSBuffer(...) call on line 329. Note that
initGSSBuffer(...) calls should be paired with resetGSSBuffer(...)
calls, so, easier/cleaner if you adjust the order here.
- Same comment applies to line 927 and the code block of line928-931.
Swapping their order would save you the call of resetGSSBuffer(...) calls.
- why do you make change to line 1167?
- The extern declaration on line 31 should be moved to NativeUtil.h and
not here.
- This is nothing to do with your change, but I noticed that there
should be a return statement following line618. No point to continue to
the rest of code, i.e. malloc and etc., if an exception has already
occurred.
- since there are only one calloc call, I don't see much value for
defining a local method. I think you can just follow the same pattern of
line 78-85. Less lines of code this way.
- see above, same comment as Solaris.c.
- line141, space between the "if" and "("?
- line 195-196, I think the check here is somewhat redundant. If an
exception occurred in the pcsc_multi2jstring(...), then it should free
"mszReaders" before returning. The next two lines doing exactly that, so
I don't think adding a check here makes any difference.
- line 311, it's cleaner to do the malloc call and the null-check before
calling (*env)->GetIntArrayElements(...) (you have on line 309) since it
is paired with a (*env)->ReleaseIntArrayElements(...) call.
*
*
- There is no malloc calls in this file at all. So, I think you should
just move the throwOutOfMemoryError method to the "pcsc.c" file. Then
you can get rid of the code block from line 42 to 57.
Thanks,
Valerie
On 02/18/13 08:09, John Zavgren wrote:
Greetings:
I posted a new webrev image.
http://cr.openjdk.java.net/~jzavgren/8007607/webrev.04/
Re: hg: jdk8/tl/langtools: 8006212: javac, convert jtreg tests from shell script to java
Woohoo -- 23 shell tests replaced with equivalent Java code: that's over 2/3 of the shell tests in langtools/test. -- Jon On 02/19/2013 09:54 AM, vicente.rom...@oracle.com wrote: Changeset: dc8b7aa7cef3 Author:vromero Date: 2013-02-19 17:53 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dc8b7aa7cef3 8006212: javac, convert jtreg tests from shell script to java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java + test/tools/apt/Basics/CheckAptIsRemovedTest.java - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh + test/tools/javac/4846262/CheckEBCDICLocaleTest.java - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh + test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java - test/tools/javac/6302184/T6302184.sh + test/tools/javac/ClassPathTest/ClassPathTest.java - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java + test/tools/javac/ExtDirs/ExtDirTest.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh + test/tools/javac/MissingInclude/MissingIncludeTest.java - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java + test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java + test/tools/javac/T5090006/AssertionFailureTest.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh + test/tools/javac/constDebug/ConstDebugTest.java - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh + test/tools/javac/fatalErrors/NoJavaLangTest.java - test/tools/javac/innerClassFile/Driver.sh + test/tools/javac/innerClassFile/InnerClassFileTest.java - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java + test/tools/javac/javazip/JavaZipTest.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java + test/tools/javac/lib/ToolBox.java + test/tools/javac/links/LinksTest.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh + test/tools/javac/newlines/NewLineTest.java - test/tools/javac/newlines/Newlines.sh + test/tools/javac/stackmap/StackMapTest.java - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.java - test/tools/javac/unicode/SupplementaryJavaID6.sh + test/tools/javah/6257087/T6257087.java - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java + test/tools/javah/T4942232/MissingParamClassTest.java + test/tools/javah/constMacroTest/ConstMacroTest.java + test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java + test/tools/javap/4866831/PublicInterfaceTest.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh + test/tools/javap/stackmap/StackmapTest.java - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh
hg: jdk8/tl/jdk: 7092447: Clarify the default locale used in each locale sensitive operation
Changeset: af396ec087f4 Author:naoto Date: 2013-02-19 10:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af396ec087f4 7092447: Clarify the default locale used in each locale sensitive operation Reviewed-by: okutsu ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Scanner.java
Re: RFR JDK-8008107
Looks good to me too. --Sean On 02/19/2013 12:42 PM, Chris Hegarty wrote: Looks ok to me. -Chris. On 02/19/2013 05:16 PM, John Zavgren wrote: Greetings: I posted a webrev image: http://cr.openjdk.java.net/~jzavgren/8008107/webrev.01/, of a change that I made to the native source code file: jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c There is a block of code in this file, around line 685, that attempts to free memory after an exception has been detected. The original code frees memory at the address of the pointer: ckParam.pReturnedKeyMaterial, then it frees memory at the address: ckParam.pReturnedKeyMaterial->pIVClient, that is pointed to by the same freed pointer. After the original memory location is freed, the pointer is no longer valid. I fixed the problem by reversing the order in which these two memory segments are freed. Thanks! John Zavgren
Re: RFR JDK-8008107
Looks ok to me. -Chris. On 02/19/2013 05:16 PM, John Zavgren wrote: Greetings: I posted a webrev image: http://cr.openjdk.java.net/~jzavgren/8008107/webrev.01/, of a change that I made to the native source code file: jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c There is a block of code in this file, around line 685, that attempts to free memory after an exception has been detected. The original code frees memory at the address of the pointer: ckParam.pReturnedKeyMaterial, then it frees memory at the address: ckParam.pReturnedKeyMaterial->pIVClient, that is pointed to by the same freed pointer. After the original memory location is freed, the pointer is no longer valid. I fixed the problem by reversing the order in which these two memory segments are freed. Thanks! John Zavgren
hg: jdk8/tl/jdk: 8008312: Re-enable MethodParameter tests in JDK
Changeset: e20c1c9197bf Author:emc Date: 2013-02-19 17:09 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e20c1c9197bf 8008312: Re-enable MethodParameter tests in JDK Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java
RFR JDK-8008107
Greetings: I posted a webrev image: http://cr.openjdk.java.net/~jzavgren/8008107/webrev.01/, of a change that I made to the native source code file: jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c There is a block of code in this file, around line 685, that attempts to free memory after an exception has been detected. The original code frees memory at the address of the pointer: ckParam.pReturnedKeyMaterial, then it frees memory at the address: ckParam.pReturnedKeyMaterial->pIVClient, that is pointed to by the same freed pointer. After the original memory location is freed, the pointer is no longer valid. I fixed the problem by reversing the order in which these two memory segments are freed. Thanks! John Zavgren
Re: RFR: JDK-8007607
Hi John,
Functionally this looks fine. Most my comments are nit picking, and style.
src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
My fault, I think I suggested you return NULL, but since these
methods return jlong they cannot (without generating warnings).
It would be better to:
< 332 return NULL;
---
> 332 return jlong_zero;
1167 return NULL; [same comment, return jlong_zero]
The indentation looks a little too much in a few places, e.g.
331 if ((*env)->ExceptionCheck(env)) {
332 __return NULL;
333 }
src/share/native/sun/security/jgss/wrapper/NativeUtil.c
620 cOid = malloc(sizeof(struct gss_OID_desc_struct));
621 if_(cOid == NULL) { [add a space after if]
622 throwOutOfMemoryError(env,NULL); [I would suggest 2 spaces]
623 return GSS_C_NO_OID;
624 }
625 cOid->length = (*env)->GetArrayLength(env, jbytes) - 2;
626 cOid->elements = malloc(cOid->length);
627 if(cOid->elements == NULL) {[ same as above ]
628 throwOutOfMemoryError(env,NULL);
629 free(cOid);
630 return GSS_C_NO_OID;
631 }
src/share/native/sun/security/smartcardio/pcsc.c
src/solaris/native/sun/security/smartcardio/pcsc_md.c
It is kinda weird to have #ifdef WIN32 for these. It really seems
that these functions should be moved up to the shared pcsc.c
and externed from platform specific code, or an addition of
pcsc.h that declares the definitions.
src/solaris/native/com/sun/security/auth/module/Solaris.c
The comment is strange
34 /*
35 * ** Throws a Java Exception by name
36 * **/
src/solaris/native/com/sun/security/auth/module/Unix.c
Strange comment ( as above ). Also, why is there a need to for
#ifndef __solaris__ ??
-Chris.
On 02/18/2013 04:09 PM, John Zavgren wrote:
Greetings:
I posted a new webrev image.
http://cr.openjdk.java.net/~jzavgren/8007607/webrev.04/
hg: jdk8/tl/jdk: 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc
Changeset: 824187de1591 Author:jzavgren Date: 2013-02-19 16:19 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/824187de1591 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc Reviewed-by: alanb, chegar, dholmes ! src/windows/native/java/io/WinNTFileSystem_md.c
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 885bb24f6018 Author:coffeys Date: 2013-02-19 14:07 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/885bb24f6018 7197187: Currency.isPastCutoverDate should be made more robust Reviewed-by: alanb ! src/share/classes/java/util/Currency.java Changeset: 01b6b0dd2006 Author:coffeys Date: 2013-02-19 14:12 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b6b0dd2006 8007315: HttpURLConnection.filterHeaderField method returns null where empty string is expected Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/net/www/protocol/http/HttpOnly.java
hg: jdk8/tl: 8008435: Fix new build to include jdk.Supported in ct.sym
Changeset: ecc8fda8f187 Author:darcy Date: 2013-02-19 00:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ecc8fda8f187 8008435: Fix new build to include jdk.Supported in ct.sym Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk
hg: jdk8/tl/jdk: 8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone
Changeset: 49b3d8efd30a Author:darcy Date: 2013-02-19 00:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49b3d8efd30a 8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone Reviewed-by: mduigou, okutsu ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/util/TimeZone.java
