From weijun.wang at oracle.com Sat Mar 1 03:53:11 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 1 Mar 2014 11:53:11 +0800 Subject: RFR 7176574 for 7u-dev: sun/security/krb5/auto/TcpTimeout.java failure In-Reply-To: <0B77E234-3877-444F-A032-1ABFDA0B1ABE@oracle.com> References: <0B77E234-3877-444F-A032-1ABFDA0B1ABE@oracle.com> Message-ID: <65EC702B-4893-4830-B1E3-03A2DA201F11@oracle.com> Ping again. On Feb 25, 2014, at 20:44, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/7176574/7u/webrev.00/ > > This is a backport of 3 jdk8 fixes on sun/security/krb5/auto/TcpTimeout.java > > 7176574: sun/security/krb5/auto/TcpTimeout.java failed with solaris-i586 > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4435f8b20d08 > > 7162687: enhance KDC server availability detection > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2fc04c2dfc8 > > 7122169: TcpTimeout fail for various reasons > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11698dedbe79 > > Please note that the jdk8 fixes include code changes to other files and are not suitable to be backported all. Here I only intend to backport changes for sun/security/krb5/auto/TcpTimeout.java and merge all of them as a backport of the last bug 7176574. > > After this change, the test is identical to the one in jdk8 (and jdk9). > > Thanks > Max > From xuelei.fan at oracle.com Sat Mar 1 06:12:43 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 01 Mar 2014 14:12:43 +0800 Subject: RFR 7176574 for 7u-dev: sun/security/krb5/auto/TcpTimeout.java failure In-Reply-To: <65EC702B-4893-4830-B1E3-03A2DA201F11@oracle.com> References: <0B77E234-3877-444F-A032-1ABFDA0B1ABE@oracle.com> <65EC702B-4893-4830-B1E3-03A2DA201F11@oracle.com> Message-ID: <53117A5B.9030700@oracle.com> Fine to me. Xuelei On 3/1/2014 11:53 AM, Wang Weijun wrote: > Ping again. > > On Feb 25, 2014, at 20:44, Wang Weijun wrote: > >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/7176574/7u/webrev.00/ >> >> This is a backport of 3 jdk8 fixes on sun/security/krb5/auto/TcpTimeout.java >> >> 7176574: sun/security/krb5/auto/TcpTimeout.java failed with solaris-i586 >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4435f8b20d08 >> >> 7162687: enhance KDC server availability detection >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2fc04c2dfc8 >> >> 7122169: TcpTimeout fail for various reasons >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11698dedbe79 >> >> Please note that the jdk8 fixes include code changes to other files and are not suitable to be backported all. Here I only intend to backport changes for sun/security/krb5/auto/TcpTimeout.java and merge all of them as a backport of the last bug 7176574. >> >> After this change, the test is identical to the one in jdk8 (and jdk9). >> >> Thanks >> Max >> > From weijun.wang at oracle.com Mon Mar 3 02:43:26 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 3 Mar 2014 10:43:26 +0800 Subject: RFR 8036104: Rename the PAData.java test Message-ID: Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8036104 Basically, the PAData.java test has the same name as the internal PAData.java source file. IntelliJ IDEA always shows me the code completion hints I do not want. And when I manually code the correct method, it shows an red flag. This is a trivial change and no webrev. diff --git a/test/sun/security/krb5/PAData.java b/test/sun/security/krb5/TestPAData.java rename from test/sun/security/krb5/PAData.java rename to test/sun/security/krb5/TestPAData.java --- a/test/sun/security/krb5/PAData.java +++ b/test/sun/security/krb5/TestPAData.java @@ -30,7 +30,7 @@ import sun.security.krb5.internal.Krb5; import sun.security.util.DerValue; -public class PAData { +public class TestPAData { public static void main(String[] args) throws Exception { // This is the dump of a KRB-ERROR data, no sensitive info included. byte[] bytes = { Thanks Max From xuelei.fan at oracle.com Mon Mar 3 02:48:01 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 03 Mar 2014 10:48:01 +0800 Subject: RFR 8036104: Rename the PAData.java test In-Reply-To: References: Message-ID: <5313ED61.6060505@oracle.com> Fine. Xuelei On 3/3/2014 10:43 AM, Wang Weijun wrote: > Please review the fix for > > https://bugs.openjdk.java.net/browse/JDK-8036104 > > Basically, the PAData.java test has the same name as the internal PAData.java source file. IntelliJ IDEA always shows me the code completion hints I do not want. And when I manually code the correct method, it shows an red flag. > > This is a trivial change and no webrev. > > diff --git a/test/sun/security/krb5/PAData.java b/test/sun/security/krb5/TestPAData.java > rename from test/sun/security/krb5/PAData.java > rename to test/sun/security/krb5/TestPAData.java > --- a/test/sun/security/krb5/PAData.java > +++ b/test/sun/security/krb5/TestPAData.java > @@ -30,7 +30,7 @@ > import sun.security.krb5.internal.Krb5; > import sun.security.util.DerValue; > > -public class PAData { > +public class TestPAData { > public static void main(String[] args) throws Exception { > // This is the dump of a KRB-ERROR data, no sensitive info included. > byte[] bytes = { > > Thanks > Max > From weijun.wang at oracle.com Mon Mar 3 02:52:36 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 3 Mar 2014 10:52:36 +0800 Subject: RFR 8036104: Rename the PAData.java test In-Reply-To: <5313ED61.6060505@oracle.com> References: <5313ED61.6060505@oracle.com> Message-ID: Thanks. That is so fast. --Max On Mar 3, 2014, at 10:48, Xuelei Fan wrote: > Fine. > > Xuelei > > On 3/3/2014 10:43 AM, Wang Weijun wrote: From xuelei.fan at oracle.com Mon Mar 3 05:30:26 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 03 Mar 2014 13:30:26 +0800 Subject: Code review 8032473, Restructure JSSE regression test hierarchy in jdk test Message-ID: <53141372.1080207@oracle.com> Please review the for: https://bugs.openjdk.java.net/browse/JDK-8032473 The deep regression test hierarchy under jdk/test/sun/security/ssl is inconsistent with how tests are usually structured. This update is trying to restructure the test hierarchy. The webrev is ugly because the rename (hg rename) of the files and directories. Here is a simple version of the update. Besides the rename, we also need to update the dependence of files, for example the "etc" location in regression tests. Thanks, Xuelei from source name -> to destination name --------------------------------------- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine -> test/javax/net/ssl/SSLEngine test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult -> test/javax/net/ssl/SSLEngineResult test/sun/security/ssl/javax/net/ssl/NewAPIs -> test/javax/net/ssl/SSLSession test/sun/security/ssl/README -> test/javax/net/ssl/README test/sun/security/ssl/javax/net/ssl -> test/javax/net/ssl test/sun/security/ssl/templates -> test/javax/net/ssl/templates test/sun/security/ssl/sanity -> test/javax/net/ssl/sanity test/sun/security/ssl/etc -> test/javax/net/ssl/etc test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java -> test/sun/net/www/protocol/https/ChunkedOutputStream.java test/sun/security/ssl/sun/net/www/httpstest -> test/sun/net/www/protocol/https test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https -> test/sun/net/www/protocol/https test/sun/security/ssl/sun/net/www/protocol/https/NewImpl -> test/sun/net/www/protocol/https/HostnameVerifier test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection -> test/sun/net/www/protocol/https/HttpsURLConnection test/sun/security/ssl/com/sun/net/ssl/internal/ssl -> test/sun/security/ssl test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https -> test/sun/net/www/protocol/https test/sun/security/ssl/com/sun/net/ssl/SSLSecurity -> test/com/sun/net/ssl/SSLSecurity From weijun.wang at oracle.com Mon Mar 3 05:54:27 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 3 Mar 2014 13:54:27 +0800 Subject: Code review 8032473, Restructure JSSE regression test hierarchy in jdk test In-Reply-To: <53141372.1080207@oracle.com> References: <53141372.1080207@oracle.com> Message-ID: As Brad mentioned in the comment, do you need to update the test/TEST.groups file? Although not friendly to read, you do have a webrev somewhere? Thanks Max From xuelei.fan at oracle.com Mon Mar 3 11:46:01 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 03 Mar 2014 19:46:01 +0800 Subject: Code review 8032473, Restructure JSSE regression test hierarchy in jdk test In-Reply-To: References: <53141372.1080207@oracle.com> Message-ID: <53146B79.3000006@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/8032473/webrev.00/ On 3/3/2014 1:54 PM, Wang Weijun wrote: > As Brad mentioned in the comment, do you need to update the test/TEST.groups file? > Yes. > Although not friendly to read, you do have a webrev somewhere? > Just made it ready. Please review the update. Thanks, Xuelei > Thanks > Max > From weijun.wang at oracle.com Mon Mar 3 13:38:06 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 3 Mar 2014 21:38:06 +0800 Subject: Code review 8032473, Restructure JSSE regression test hierarchy in jdk test In-Reply-To: <53146B79.3000006@oracle.com> References: <53141372.1080207@oracle.com> <53146B79.3000006@oracle.com> Message-ID: Hi Xuelei Yes it's quite difficult to read the actual webrev so instead I try to apply jdk.patch to my repo and see what happens. The patch file cannot remove the old files so I cannot be sure the cleanup is clean. Is it possible you recreate the webrev with a changeset (instead of jdk.patch). I think it can be created with a plain webrev call without using the -r option. I just want to confirm: 1. No more file in old directory 2. JPRT runs fine 3. Number of test running not changed Also, the webrev shows no diff and it looks each file just have a new name and its content unchanged, but we know there are at least path to store changes. --Max On Mar 3, 2014, at 19:46, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net/~xuelei/8032473/webrev.00/ > > On 3/3/2014 1:54 PM, Wang Weijun wrote: >> As Brad mentioned in the comment, do you need to update the test/TEST.groups file? >> > Yes. > >> Although not friendly to read, you do have a webrev somewhere? >> > Just made it ready. Please review the update. > > Thanks, > Xuelei > >> Thanks >> Max >> > From sean.mullan at oracle.com Mon Mar 3 13:38:06 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 03 Mar 2014 08:38:06 -0500 Subject: Request for Review: 8035973: NPE in ForwardBuilder In-Reply-To: <5310E9EE.3090400@oracle.com> References: <5310E9EE.3090400@oracle.com> Message-ID: <531485BE.4060206@oracle.com> On 02/28/2014 02:56 PM, Jason Uh wrote: > Could I please get a review of this change? Looks fine to me, but the priority should be higher if this requires a backport to 7u. Also, the bug should be labeled with "8-na" and "9-na" since this is not an issue in 8 and 9. --Sean > > Just a simple fix for 7u-dev that adds a check for a null CertStore, in > case URICertStore.getInstance returns null. > > webrev: http://cr.openjdk.java.net/~juh/8035973/webrev.00/ > bug: http://bugs.openjdk.java.net/browse/JDK-8035973 > > noreg-sqe because an SQE test is already in place. > > Thanks, > Jason From xuelei.fan at oracle.com Mon Mar 3 13:58:23 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 03 Mar 2014 21:58:23 +0800 Subject: Code review 8032473, Restructure JSSE regression test hierarchy in jdk test In-Reply-To: References: <53141372.1080207@oracle.com> <53146B79.3000006@oracle.com> Message-ID: <53148A7F.1030704@oracle.com> Just as you see, webrev is ugly. Here is the export changeset: http://cr.openjdk.java.net/~xuelei/8032473/update.export "hg import" should work. From the changeset, we can see the content changes in renames files. Xuelei On 3/3/2014 9:38 PM, Wang Weijun wrote: > Hi Xuelei > > Yes it's quite difficult to read the actual webrev so instead I try to apply jdk.patch to my repo and see what happens. The patch file cannot remove the old files so I cannot be sure the cleanup is clean. Is it possible you recreate the webrev with a changeset (instead of jdk.patch). I think it can be created with a plain webrev call without using the -r option. > > I just want to confirm: > > 1. No more file in old directory > 2. JPRT runs fine > 3. Number of test running not changed > > Also, the webrev shows no diff and it looks each file just have a new name and its content unchanged, but we know there are at least path to store changes. > > --Max > > On Mar 3, 2014, at 19:46, Xuelei Fan wrote: > >> webrev: http://cr.openjdk.java.net/~xuelei/8032473/webrev.00/ >> >> On 3/3/2014 1:54 PM, Wang Weijun wrote: >>> As Brad mentioned in the comment, do you need to update the test/TEST.groups file? >>> >> Yes. >> >>> Although not friendly to read, you do have a webrev somewhere? >>> >> Just made it ready. Please review the update. >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >> > From jason.uh at oracle.com Mon Mar 3 19:46:32 2014 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 03 Mar 2014 11:46:32 -0800 Subject: Request for Review: 8035973: NPE in ForwardBuilder In-Reply-To: <531485BE.4060206@oracle.com> References: <5310E9EE.3090400@oracle.com> <531485BE.4060206@oracle.com> Message-ID: <5314DC18.1070002@oracle.com> On 3/3/14 5:38 AM, Sean Mullan wrote: > On 02/28/2014 02:56 PM, Jason Uh wrote: >> Could I please get a review of this change? > > Looks fine to me, but the priority should be higher if this requires a > backport to 7u. Also, the bug should be labeled with "8-na" and "9-na" > since this is not an issue in 8 and 9. Thanks. Bumped priority up to P3 and added the labels. > --Sean > >> >> Just a simple fix for 7u-dev that adds a check for a null CertStore, in >> case URICertStore.getInstance returns null. >> >> webrev: http://cr.openjdk.java.net/~juh/8035973/webrev.00/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8035973 >> >> noreg-sqe because an SQE test is already in place. >> >> Thanks, >> Jason > From philipp.heckel at gmail.com Mon Mar 3 23:19:22 2014 From: philipp.heckel at gmail.com (Philipp Heckel) Date: Tue, 4 Mar 2014 00:19:22 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible Message-ID: Hello everyone, I apologize if this is not the right place so ask/report this. Please direct me to the correct place if it isn't. I recently noticed that that the current javax.crypto.CipherInputStream implementation in OpenJDK 6/7/8 is insecure when AEAD modes are used, e.g. Cipher.getInstance("AES/GCM/NoPadding") with the BC provider. In particular, it is possible to tamper with the ciphertext -- without any exceptions being passed on to the application. In an example at [1] (see "Test B"), I was able to decrypt an altered ciphertext to "Confirm 900$ pay" (original plaintext was "Confirm 100$ pay") by simply XORing the original ciphertext with 0x08 at index 8. The underlying GCM engine behaves correctly as "Test A" shows (a BadPaddingException "mac check in GCM failed" is thrown), but the j.c.CipherInputStream simply ignores this exception in the close() method: public void close() throws IOException { ... try { cipher.doFinal(); } catch (BadPaddingException ex) { /// <<<<<< When GCM tag verification fails, a BadPaddingException is thrown /// <<<<<< The CipherInputStream unfortunately ignores this exception! } ... } A discussion about this issue can be found in the Bouncy Castle mailing list [2], or in my blog post [3]. I hope I'm not the only one who thinks that this is a very serious security issue, because it gives developers a false sense of authenticated encryption -- where in fact at this stage AES/GCM is not better than AES/CTR when used with a CipherInputStream. I found this issue by chance, so there are probably many applications out there that are also vulnerable. Current workaround: Bouncy Castle provides its own org.bouncycastle.crypto.io.CipherInputStream that (unfortunately) is also broken in v1.50, but will be fixed in 1.51. David Hook provided a fix [4] in response to the discussion; the full class can be found at [5]. Best, Philipp [1] https://github.com/binwiederhier/cipherinputstream-aes-gcm/blob/e9759ca71557e5d1da26ae72f6ce5aac918e34b0/src/CipherInputStreamIssuesTests.java#L89 [2] http://bouncycastle.org/devmailarchive/msg13615.html [3] http://blog.philippheckel.com/2014/03/01/cipherinputstream-for-aead-modes-is-broken-in-jdk7-gcm/ [4] https://github.com/bcgit/bc-java/commit/933119114c96f703d1303a3c77d9ac405091270d [5] https://raw.github.com/bcgit/bc-java/933119114c96f703d1303a3c77d9ac405091270d/core/src/main/java/org/bouncycastle/crypto/io/CipherInputStream.java -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Mar 3 23:49:49 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 03 Mar 2014 15:49:49 -0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: Message-ID: <5315151D.6070504@oracle.com> I view this more as a major vulnerability in BC provider than javax.crypto.CipherInputStream class and this should be reported to BouncyCastle so they can fix their provider code. If you tried the same test with SunJCE provider, you will find that none of the decrypted data is returned to the caller when the tag doesn't match. If the providers weren't modified to not returning any of the decrypted data AFTER the tag is verified, the root cause is not fixed and you can simply use Cipher to get hold of the decrypted data instead. Thus, CipherInputStream class ignores AEADBadTagException isn't really the problem here, as the some of the decrypted data may have been returned to the caller before the tag is verified. Whether AEADBadTagException is ignored or not doesn't matter here. Regards, Valerie On 03/03/14 15:19, Philipp Heckel wrote: > Hello everyone, > > I apologize if this is not the right place so ask/report this. Please > direct me to the correct place if it isn't. > > I recently noticed that that the current > javax.crypto.CipherInputStream implementation in OpenJDK 6/7/8 is > insecure when AEAD modes are used, e.g. > Cipher.getInstance("AES/GCM/NoPadding") with the BC provider. In > particular, it is possible to tamper with the ciphertext -- without > any exceptions being passed on to the application. > > In an example at [1] (see "Test B"), I was able to decrypt an altered > ciphertext to "Confirm 900$ pay" (original plaintext was "Confirm 100$ > pay") by simply XORing the original ciphertext with 0x08 at index 8. > The underlying GCM engine behaves correctly as "Test A" shows (a > BadPaddingException "mac check inGCM failed" is thrown), but the > j.c.CipherInputStream simply ignores this exception in the close() method: > > public void close() throws IOException { > ... > try { > cipher.doFinal(); > } > catch (BadPaddingException ex) { > /// <<<<<< When GCM tag verification fails, a BadPaddingException > is thrown > /// <<<<<< The CipherInputStream unfortunately ignores this > exception! > } > ... > } > > A discussion about this issue can be found in the Bouncy Castle > mailing list [2], or in my blog post [3]. > > I hope I'm not the only one who thinks that this is a very serious > security issue, because it gives developers a false sense of > authenticated encryption -- where in fact at this stage AES/GCM is not > better than AES/CTR when used with a CipherInputStream. I found this > issue by chance, so there are probably many applications out there > that are also vulnerable. > > Current workaround: Bouncy Castle provides its own > org.bouncycastle.crypto.io.CipherInputStream that (unfortunately) is > also broken in v1.50, but will be fixed in 1.51. David Hook provided a > fix [4] in response to the discussion; the full class can be found at [5]. > > Best, > Philipp > > [1] > https://github.com/binwiederhier/cipherinputstream-aes-gcm/blob/e9759ca71557e5d1da26ae72f6ce5aac918e34b0/src/CipherInputStreamIssuesTests.java#L89 > [2] http://bouncycastle.org/devmailarchive/msg13615.html > [3] > http://blog.philippheckel.com/2014/03/01/cipherinputstream-for-aead-modes-is-broken-in-jdk7-gcm/ > [4] > https://github.com/bcgit/bc-java/commit/933119114c96f703d1303a3c77d9ac405091270d > [5] > https://raw.github.com/bcgit/bc-java/933119114c96f703d1303a3c77d9ac405091270d/core/src/main/java/org/bouncycastle/crypto/io/CipherInputStream.java From mhall at mhcomputing.net Mon Mar 3 23:55:55 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Mon, 3 Mar 2014 15:55:55 -0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <5315151D.6070504@oracle.com> References: <5315151D.6070504@oracle.com> Message-ID: <20140303235555.GB8587@mhcomputing.net> It's fair to say that returning unchecked data is a provider problem, but we should also try to find the explanation why the JRE swallows important cryptographic exceptions, as that's not usually recommended practice in Java. Matthew. On Mon, Mar 03, 2014 at 03:49:49PM -0800, Valerie (Yu-Ching) Peng wrote: > > I view this more as a major vulnerability in BC provider than > javax.crypto.CipherInputStream class and this should be reported to > BouncyCastle so they can fix their provider code. > > If you tried the same test with SunJCE provider, you will find that > none of the decrypted data is returned to the caller when the tag > doesn't match. If the providers weren't modified to not returning > any of the decrypted data AFTER the tag is verified, the root cause > is not fixed and you can simply use Cipher to get hold of the > decrypted data instead. > > Thus, CipherInputStream class ignores AEADBadTagException isn't > really the problem here, as the some of the decrypted data may have > been returned to the caller before the tag is verified. Whether > AEADBadTagException is ignored or not doesn't matter here. > > Regards, > Valerie From valerie.peng at oracle.com Tue Mar 4 01:17:04 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 03 Mar 2014 17:17:04 -0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <20140303235555.GB8587@mhcomputing.net> References: <5315151D.6070504@oracle.com> <20140303235555.GB8587@mhcomputing.net> Message-ID: <53152990.30809@oracle.com> Well, this is just my speculation. But I think the reason that CipherInputStream swallows BadPaddingException is as its javadoc class description had: *This class adheres strictly to the semantics, especially the failure semantics, of its ancestor classes java.io.FilterInputStream and java.io.InputStream.* This class has exactly those methods specified in its ancestor classes, and overrides them all. *Moreover, this class catches all exceptions that are not thrown by its ancestor classes.* In particular, the |skip| method skips, and the |available| method counts only data that have been processed by the encapsulated Cipher. Just my .02, Valerie On 03/03/14 15:55, Matthew Hall wrote: > It's fair to say that returning unchecked data is a provider problem, but we > should also try to find the explanation why the JRE swallows important > cryptographic exceptions, as that's not usually recommended practice in Java. > > Matthew. > > On Mon, Mar 03, 2014 at 03:49:49PM -0800, Valerie (Yu-Ching) Peng wrote: >> I view this more as a major vulnerability in BC provider than >> javax.crypto.CipherInputStream class and this should be reported to >> BouncyCastle so they can fix their provider code. >> >> If you tried the same test with SunJCE provider, you will find that >> none of the decrypted data is returned to the caller when the tag >> doesn't match. If the providers weren't modified to not returning >> any of the decrypted data AFTER the tag is verified, the root cause >> is not fixed and you can simply use Cipher to get hold of the >> decrypted data instead. >> >> Thus, CipherInputStream class ignores AEADBadTagException isn't >> really the problem here, as the some of the decrypted data may have >> been returned to the caller before the tag is verified. Whether >> AEADBadTagException is ignored or not doesn't matter here. >> >> Regards, >> Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhall at mhcomputing.net Tue Mar 4 01:37:26 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Mon, 3 Mar 2014 17:37:26 -0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <53152990.30809@oracle.com> References: <5315151D.6070504@oracle.com> <20140303235555.GB8587@mhcomputing.net> <53152990.30809@oracle.com> Message-ID: <20140304013726.GA8810@mhcomputing.net> On Mon, Mar 03, 2014 at 05:17:04PM -0800, Valerie (Yu-Ching) Peng wrote: > *Moreover, this class catches all exceptions that are not thrown by > its ancestor classes.* Then it should be able to throw an AEAD exception wrapped in an IOException, should it not? Matthew. From jdk-security-dev at whittington.net.nz Tue Mar 4 01:44:06 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Tue, 4 Mar 2014 14:44:06 +1300 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <5315151D.6070504@oracle.com> References: <5315151D.6070504@oracle.com> Message-ID: <5992A4C5-6019-4567-B91D-2ECBD216AE84@whittington.net.nz> On 4/03/2014, at 12:49 pm, Valerie (Yu-Ching) Peng wrote: > > I view this more as a major vulnerability in BC provider than javax.crypto.CipherInputStream class and this should be reported to BouncyCastle so they can fix their provider code. > > If you tried the same test with SunJCE provider, you will find that none of the decrypted data is returned to the caller when the tag doesn't match. If the providers weren't modified to not returning any of the decrypted data AFTER the tag is verified, the root cause is not fixed and you can simply use Cipher to get hold of the decrypted data instead. There are several things wrong with this thinking in my opinion (in no particular order): 1. It has serious and unexpected performance problems. The JDK 8 GCM implementation is effectively useless for any large scale encryption (such as large files that need to be protected at rest, or large volumes of moderately sized messages) due to it buffering all ciphertext during decrypt (this is leaving aside the hit of all the data copying in the implementation of that buffering, and the unnecessary buffering of AD). 2. Cipher is the wrong place in a security architecture to apply this kind of restriction - Cipher (as well as the BC AEADBlockCipher API and openssl cipher APIs) is framed in terms of a stream of ciphertext blocks in and a stream of plaintext blocks out, and all of the current mainstream AE modes utilise trailing authentication tags. It?s a natural and efficient pattern to apply that authentication at the conclusion of the ciphertext stream. From my POV handling of authentication belongs at a protocol level, built on the available cryptographic primitives - just as it is now when Cipher and Mac are used in a generic composition ala TLS, SSH. As a protocol designer that allows me to packetise my plaintext/ciphertext, implement a higher level AEAD framing mode, or utilise appropriate (i.e. not RAM) temporary storage for large decrypted plaintexts until they are fully authenticated. The support for AD in the Cipher API already implies a higher level protocol that is coordinating the authentication, so it seems odd for the Cipher to take a kind of moral custodian role by not relinquishing plaintext until authentication is complete. If you believe there should be a safer (from misuse) primitive (such as the NaCl secret box, or an incremental/framed AEAD mode as is being discussed on CFRG) then I?m all for that, but the API contract and performance characteristics of that API is distinct from that of the existing notion of a Cipher - degrading the only fast online authenticated cipher supported in the JDK to a slow, packet mode cipher is a poor bandaid over the lack of such an API, and prevents higher level designs from making more appropriate choices for their particular application. 3. It?s inconsistent with expectations and other behaviour. Third party JCE providers (such as BC) that reasonably implement the Cipher/AEADBadTagException API as documented and/or with natural expectations of the behaviour based on the published API documentation will behave significantly differently when used with CipherInputStream - CipherInputStream should operate against the published API of Cipher/AEADBadTagException, and not an internal JDK interpretation of how that should be implemented. > > Thus, CipherInputStream class ignores AEADBadTagException isn't really the problem here, as the some of the decrypted data may have been returned to the caller before the tag is verified. Whether AEADBadTagException is ignored or not doesn't matter here. Even if you accept that the Cipher instance should return no data until the tag is validated, CipherInputStream is still broken - it will silently treat an unauthenticated ciphertext with a nonzero plaintext length the same way it treats an authenticated zero-length ciphertext. i.e. it allows an attacker to forge the transmission of an ?empty? message merely by flipping a bit of the authenticated ciphertext in transit. If you add to that the long standing silent truncation of decrypted plaintexts in non-authenticated modes when padding is invalid (either by truncation or invalid key) using CipherInputStream is a minefield. cheers tim From philipp.heckel at gmail.com Tue Mar 4 07:49:28 2014 From: philipp.heckel at gmail.com (Philipp Heckel) Date: Tue, 4 Mar 2014 08:49:28 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <5315151D.6070504@oracle.com> References: <5315151D.6070504@oracle.com> Message-ID: Although Tim and Matthew already mentioned the main points, I'd like to voice my concerns as well -- in particular because I think that this is *not* a philosophical argument: Security must always be more important than the supposedly correct semantics of a class or method. If you tried the same test with SunJCE provider, you will find that none of > the decrypted data is returned to the caller when the tag doesn't match. If > the providers weren't modified to not returning any of the decrypted data > AFTER the tag is verified, the root cause is not fixed and you can simply > use Cipher to get hold of the decrypted data instead. > The whole purpose of Input/OutputStreams is to be able to avoid large buffers and/or temporary files of any sort. For modes in which the tag is appended to the ciphertext (including GCM), buffering all the data is simply unacceptable, since if would make processing of large files simply impossible. Using the Cipher class directly is not an option either, because many applications nest streams into one another. Chaining gzip+encryption is not uncommon. If you process large amount of data, again, manually unpacking/packing is not feasible. > Thus, CipherInputStream class ignores AEADBadTagException isn't really the > problem here, as the some of the decrypted data may have been returned to > the caller before the tag is verified. Whether AEADBadTagException is > ignored or not doesn't matter here. > Adding to what Matthew said: I think it does matter. Security-related exceptions should never be hidden from the developer! Adding an InvalidCipherTextIOException (like in BC) would not do any harm to existing code and the API, since these kind of exceptions must be handled anyway. Asked differently: Is there a particular reason why BadPaddingException and IllegalBlockSizeException are ignored? Are there known issues that would arise if they weren't ignored? Best, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Tue Mar 4 09:17:38 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 04 Mar 2014 10:17:38 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: <5315151D.6070504@oracle.com> Message-ID: <53159A32.8070104@redhat.com> On 03/04/2014 08:49 AM, Philipp Heckel wrote: > Although Tim and Matthew already mentioned the main points, I'd like to > voice my concerns as well -- in particular because I think that this is > *not* a philosophical argument: Security must always be more important > than the supposedly correct semantics of a class or method. You can't increase security by implementing incorrect semantics, you just get something that is broken. Your complaint about buffering shows that. :-) > The whole purpose of Input/OutputStreams is to be able to avoid large > buffers and/or temporary files of any sort. For modes in which the tag > is appended to the ciphertext (including GCM), buffering all the data is > simply unacceptable, since if would make processing of large files > simply impossible. The problem is that you cannot, in general, implement non-chunked integrity checks securely by returning unverified chunks and throwing an exception once you reach the end and detect that you've returned bad data somewhere along the way. > Using the Cipher class directly is not an option either, because many > applications nest streams into one another. Chaining gzip+encryption is > not uncommon. If you process large amount of data, again, manually > unpacking/packing is not feasible. And it's also not uncommon that you don't want to expose your decompression code to unsigned data, so AEAD without chunking is just a poor choice here. > Thus, CipherInputStream class ignores AEADBadTagException isn't > really the problem here, as the some of the decrypted data may have > been returned to the caller before the tag is verified. Whether > AEADBadTagException is ignored or not doesn't matter here. > > > Adding to what Matthew said: I think it does matter. Security-related > exceptions should never be hidden from the developer! Except when you have to do this to avoid creating an oracle. Since CipherInputStream is used with other ciphers, this might have been the reason why the cryptographic-related exceptions are swallowed. That being said, adding a warning that this happens to the CipherInputStream documentation seems prudent. -- Florian Weimer / Red Hat Product Security Team From philipp.heckel at gmail.com Tue Mar 4 21:56:17 2014 From: philipp.heckel at gmail.com (Philipp Heckel) Date: Tue, 4 Mar 2014 22:56:17 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <53159A32.8070104@redhat.com> References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> Message-ID: Thank you all for your comments. I must say this is a very interesting discussion. And I really hope that you keep an open mind when looking for a solution -- I am certainly trying to do the same! You can't increase security by implementing incorrect semantics, you just > get something that is broken. Your complaint about buffering shows that. > :-) *Semantics* That is very true. Maybe it's not entirely clear to me what the desired semantics of the class are, so please excuse my comment about the "supposedly correct semantics". Here's what I understand from the JavaDoc [1]. Please correct me if this is wrong or some points are missing: 1. The given Cipher object must be fully initialized 2. The read() methods in CipherInputStream must only return data processed by the underlying Cipher 3. The CipherInputStream adheres strictly to the semantics of FilterInputStream and InputStream 4. The CipherInputStream catches all exceptions not thrown by its ancestor classes *Interpretation* ad 1) Obviously a Cipher must be initialized for decryption. However, there are no constraints on what ciphers are supported. In particular, there is no mention authenticated encryption modes not being supported. ad 2) Also quite obvious for regular non-authenticating modes. Again, no mention of returned bytes having to be authenticated or AE at all. ad 3) FilterInputStream and InputStream have no special requirements with regard to how encrypted data is processed. ad 4) In my humble opinion, this is the only debatable comment, because if the JavaDoc is followed strictly (and blindly so), one must simply "ignore all exceptions other than IOException" -- not allowing the propagation of any of the mentioned exceptions (AEADBadTagException, BadPaddingException, IllegalBlockSizeException) to the application. For non-AEAD modes, this might make sense (as Florian mentioned: avoiding oracles), for AEAD modes, it does not necessarily make sense. *Gaps* Here's what I think is wrong with this: a. Authenticated encryption has not been considered when the JavaDoc was written; Re-thinking the CipherInputStream concepts with AE in mind is probably not a bad idea. And if that means having to slightly adjust the semantics so that they make sense for AEAD modes as well, why not? As long as it doesn't break any of the other ciphers/modes, of course. b. Developers would not expect this behavior -- even if there was a warning in the JavaDoc. Implementing encryption correctly is hard enough, this just makes efficient usage of AEAD impossible. > The problem is that you cannot, in general, implement non-chunked > integrity checks securely by returning unverified chunks and throwing an > exception once you reach the end and detect that you've returned bad data > somewhere along the way. I understand. However, that's how GCM is works: tag at the end, no "chunk-tags". Unless we what to change GCM, unverified data has to be returned to make streaming work at all, right? Or how else would one securely implement GCM for large files? The only options are to (a) buffer everything (which defeats the purpose of streaming), or to (b) create temp. files which is very inefficient. IMHO: I think it's much, much better to return unauthenticated data first and throw an exception when the stream is closed (+ add a warning in the JavaDoc) -- than to not authenticate data at all or buffer it (in RAM or on disk). And it's also not uncommon that you don't want to expose your decompression > code to unsigned data, so AEAD without chunking is just a poor choice here. See above. Except when you have to do this to avoid creating an oracle. Since > CipherInputStream is used with other ciphers, this might have been the > reason why the cryptographic-related exceptions are swallowed. > It might be really interesting to see if possible oracles were indeed the reason. Because right now, we don't actually know what the reason was -- maybe there was none and it's just a wording issue in the JavaDoc ... If that was indeed the reason, then there are two options: 1. Re-throw a generic "new IOException()" -- thereby swallowing the actual reason, but still considering AE 2. Follow Bouncy Castle's lead: Create a new constructor for AEAD ciphers and consciously treat them differently Just my two cents. Sorry for the long mail. I tried to keep it short. But I find this very important. Best regards, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd-2014 at eckenfels.net Tue Mar 4 22:16:03 2014 From: bernd-2014 at eckenfels.net (Bernd Eckenfels) Date: Tue, 4 Mar 2014 23:16:03 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> Message-ID: <20140304231603.00000885.bernd-2014@eckenfels.net> Am Tue, 4 Mar 2014 22:56:17 +0100 schrieb Philipp Heckel : > ad 3) FilterInputStream and InputStream have no special requirements > with regard to how encrypted data is processed. Actually there are examples in the JDK who does checksum after returning data. For example the GZIPInputStream. And that is exactly why I would expect CipherInputStream to do it as well. In case of GZipInputStream the trailer CRC is actually checked in the last read(), this has some advantages to the case when input streams are silently closed. But if I use a integrity checked stream I normally by definition make sure to read till the end and check the close(). Bernd BTW: thanks Florian to mention it might not be a good idea to uncompress unverified data. (but this point does not make me happy from a streaming perspective :) From weijun.wang at oracle.com Wed Mar 5 06:47:17 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 5 Mar 2014 14:47:17 +0800 Subject: Code review 8032473, Restructure JSSE regression test hierarchy in jdk test In-Reply-To: <53148A7F.1030704@oracle.com> References: <53141372.1080207@oracle.com> <53146B79.3000006@oracle.com> <53148A7F.1030704@oracle.com> Message-ID: Change looks fine, so does the closed repo. Hopefully you've already run both the automatic and manual tests. Thanks Max On Mar 3, 2014, at 21:58, Xuelei Fan wrote: > Just as you see, webrev is ugly. Here is the export changeset: > http://cr.openjdk.java.net/~xuelei/8032473/update.export > > "hg import" should work. From the changeset, we can see the content > changes in renames files. > > Xuelei > > On 3/3/2014 9:38 PM, Wang Weijun wrote: >> Hi Xuelei >> >> Yes it's quite difficult to read the actual webrev so instead I try to apply jdk.patch to my repo and see what happens. The patch file cannot remove the old files so I cannot be sure the cleanup is clean. Is it possible you recreate the webrev with a changeset (instead of jdk.patch). I think it can be created with a plain webrev call without using the -r option. >> >> I just want to confirm: >> >> 1. No more file in old directory >> 2. JPRT runs fine >> 3. Number of test running not changed >> >> Also, the webrev shows no diff and it looks each file just have a new name and its content unchanged, but we know there are at least path to store changes. >> >> --Max >> >> On Mar 3, 2014, at 19:46, Xuelei Fan wrote: >> >>> webrev: http://cr.openjdk.java.net/~xuelei/8032473/webrev.00/ >>> >>> On 3/3/2014 1:54 PM, Wang Weijun wrote: >>>> As Brad mentioned in the comment, do you need to update the test/TEST.groups file? >>>> >>> Yes. >>> >>>> Although not friendly to read, you do have a webrev somewhere? >>>> >>> Just made it ready. Please review the update. >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>> >> > From anthony.scarpino at oracle.com Wed Mar 5 06:56:52 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 04 Mar 2014 22:56:52 -0800 Subject: Code review request: 8036543 Parfait JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c Message-ID: <5316CAB4.7060704@oracle.com> Hi, I need a review for changes that cover JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c http://cr.openjdk.java.net/~ascarpino/8036543/webrev.00/ thanks Tony From xuelei.fan at oracle.com Wed Mar 5 07:21:20 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 05 Mar 2014 15:21:20 +0800 Subject: Code review 8032473, Restructure JSSE regression test hierarchy in jdk test In-Reply-To: References: <53141372.1080207@oracle.com> <53146B79.3000006@oracle.com> <53148A7F.1030704@oracle.com> Message-ID: <5316D070.7070102@oracle.com> On 3/5/2014 2:47 PM, Wang Weijun wrote: > Change looks fine, so does the closed repo. Thanks for the code review. > Hopefully you've already run both the automatic and manual tests. > Yes. I will integrate the fix as soon as possible. Xuelei > Thanks > Max > > On Mar 3, 2014, at 21:58, Xuelei Fan wrote: > >> Just as you see, webrev is ugly. Here is the export changeset: >> http://cr.openjdk.java.net/~xuelei/8032473/update.export >> >> "hg import" should work. From the changeset, we can see the content >> changes in renames files. >> >> Xuelei >> >> On 3/3/2014 9:38 PM, Wang Weijun wrote: >>> Hi Xuelei >>> >>> Yes it's quite difficult to read the actual webrev so instead I try to apply jdk.patch to my repo and see what happens. The patch file cannot remove the old files so I cannot be sure the cleanup is clean. Is it possible you recreate the webrev with a changeset (instead of jdk.patch). I think it can be created with a plain webrev call without using the -r option. >>> >>> I just want to confirm: >>> >>> 1. No more file in old directory >>> 2. JPRT runs fine >>> 3. Number of test running not changed >>> >>> Also, the webrev shows no diff and it looks each file just have a new name and its content unchanged, but we know there are at least path to store changes. >>> >>> --Max >>> >>> On Mar 3, 2014, at 19:46, Xuelei Fan wrote: >>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/8032473/webrev.00/ >>>> >>>> On 3/3/2014 1:54 PM, Wang Weijun wrote: >>>>> As Brad mentioned in the comment, do you need to update the test/TEST.groups file? >>>>> >>>> Yes. >>>> >>>>> Although not friendly to read, you do have a webrev somewhere? >>>>> >>>> Just made it ready. Please review the update. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>> >>> >> > From xuelei.fan at oracle.com Wed Mar 5 11:43:12 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 05 Mar 2014 19:43:12 +0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> Message-ID: <53170DD0.4030402@oracle.com> I think the implementation of GCM cipher should respect the specification of GCM mode. Before authentication tag get checked, no plaintext should be released to application. See section 7.0 of GCM spec (NIST SP-800-38D). Xuelei On 3/5/2014 5:56 AM, Philipp Heckel wrote: > Thank you all for your comments. I must say this is a very interesting > discussion. And I really hope that you keep an open mind when looking > for a solution -- I am certainly trying to do the same! > > You can't increase security by implementing incorrect semantics, you > just get something that is broken. Your complaint about buffering > shows that. :-) > > > *Semantics* > That is very true. Maybe it's not entirely clear to me what the desired > semantics of the class are, so please excuse my comment about the > "supposedly correct semantics". Here's what I understand from the > JavaDoc [1]. Please correct me if this is wrong or some points are missing: > > 1. The given Cipher object must be fully initialized > 2. The read() methods in CipherInputStream must only return data > processed by the underlying Cipher > 3. The CipherInputStream adheres strictly to the semantics of > FilterInputStream and InputStream > 4. The CipherInputStream catches all exceptions not thrown by its > ancestor classes > > *Interpretation* > ad 1) Obviously a Cipher must be initialized for decryption. However, > there are no constraints on what ciphers are supported. In particular, > there is no mention authenticated encryption modes not being supported. > > ad 2) Also quite obvious for regular non-authenticating modes. Again, no > mention of returned bytes having to be authenticated or AE at all. > > ad 3) FilterInputStream and InputStream have no special requirements > with regard to how encrypted data is processed. > > ad 4) In my humble opinion, this is the only debatable comment, because > if the JavaDoc is followed strictly (and blindly so), one must simply > "ignore all exceptions other than IOException" -- not allowing the > propagation of any of the mentioned exceptions (AEADBadTagException, > BadPaddingException, IllegalBlockSizeException) to the application. For > non-AEAD modes, this might make sense (as Florian mentioned: avoiding > oracles), for AEAD modes, it does not necessarily make sense. > > *Gaps* > Here's what I think is wrong with this: > > a. Authenticated encryption has not been considered when the JavaDoc was > written; Re-thinking the CipherInputStream concepts with AE in mind is > probably not a bad idea. And if that means having to slightly adjust the > semantics so that they make sense for AEAD modes as well, why not? As > long as it doesn't break any of the other ciphers/modes, of course. > > b. Developers would not expect this behavior -- even if there was a > warning in the JavaDoc. Implementing encryption correctly is hard > enough, this just makes efficient usage of AEAD impossible. > > > > The problem is that you cannot, in general, implement non-chunked > integrity checks securely by returning unverified chunks and > throwing an exception once you reach the end and detect that you've > returned bad data somewhere along the way. > > > I understand. However, that's how GCM is works: tag at the end, no > "chunk-tags". Unless we what to change GCM, unverified data has to be > returned to make streaming work at all, right? Or how else would one > securely implement GCM for large files? The only options are to (a) > buffer everything (which defeats the purpose of streaming), or to (b) > create temp. files which is very inefficient. > > IMHO: I think it's much, much better to return unauthenticated data > first and throw an exception when the stream is closed (+ add a warning > in the JavaDoc) -- than to not authenticate data at all or buffer it (in > RAM or on disk). > > And it's also not uncommon that you don't want to expose your > decompression code to unsigned data, so AEAD without chunking is > just a poor choice here. > > > See above. > > Except when you have to do this to avoid creating an oracle. Since > CipherInputStream is used with other ciphers, this might have been > the reason why the cryptographic-related exceptions are swallowed. > > > It might be really interesting to see if possible oracles were indeed > the reason. Because right now, we don't actually know what the reason > was -- maybe there was none and it's just a wording issue in the JavaDoc > ... > > If that was indeed the reason, then there are two options: > 1. Re-throw a generic "new IOException()" -- thereby swallowing the > actual reason, but still considering AE > 2. Follow Bouncy Castle's lead: Create a new constructor for AEAD > ciphers and consciously treat them differently > > Just my two cents. > Sorry for the long mail. I tried to keep it short. But I find this very > important. > > Best regards, > Philipp > From xuelei.fan at oracle.com Wed Mar 5 13:06:48 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 05 Mar 2014 21:06:48 +0800 Subject: Code review request, 8036676, Rename class name testEnabledProtocols to TestEnabledProtocols Message-ID: <53172168.3030808@oracle.com> Hi, Please review this simple test fix: http://cr.openjdk.java.net/~xuelei/8036676/webrev.00/ Updated to use capital letter to start a class name. Thanks, Xuelei From weijun.wang at oracle.com Wed Mar 5 13:14:29 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 5 Mar 2014 21:14:29 +0800 Subject: Code review request, 8036676, Rename class name testEnabledProtocols to TestEnabledProtocols In-Reply-To: <53172168.3030808@oracle.com> References: <53172168.3030808@oracle.com> Message-ID: <6A1C8194-9933-463F-8F87-73E6250A1E4A@oracle.com> Change looks fine. That was an awkward name. --Max On Mar 5, 2014, at 21:06, Xuelei Fan wrote: > Hi, > > Please review this simple test fix: > > http://cr.openjdk.java.net/~xuelei/8036676/webrev.00/ > > Updated to use capital letter to start a class name. > > Thanks, > Xuelei From anthony.scarpino at oracle.com Wed Mar 5 19:50:37 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 05 Mar 2014 11:50:37 -0800 Subject: Review Request for JDK-8033571: [parfait] warning from b128 for security/smartcardio/pcsc_md.c: JNI exception pending In-Reply-To: <52FD554D.7050207@oracle.com> References: <52FD554D.7050207@oracle.com> Message-ID: <5317800D.2070406@oracle.com> On 02/13/2014 03:29 PM, Valerie (Yu-Ching) Peng wrote: > > Can someone please review the fixes which checks for pending exceptions > in native code "pcsc_md.c"? > The fix is trivial scope-wise. > > Webrev: http://cr.openjdk.java.net/~valeriep/8033571/webrev.00/ > > Thanks, > Valerie In my change that's out for review, 8036543, I only checked for findFunction() returning null, while you used ExceptionCheck. Was there something you saw that caused you to check for an exception thrown rather than null? Either way the change looks good to me. Tony From valerie.peng at oracle.com Wed Mar 5 21:57:10 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 05 Mar 2014 13:57:10 -0800 Subject: Review Request for JDK-8033571: [parfait] warning from b128 for security/smartcardio/pcsc_md.c: JNI exception pending In-Reply-To: <5317800D.2070406@oracle.com> References: <52FD554D.7050207@oracle.com> <5317800D.2070406@oracle.com> Message-ID: <53179DB6.6080408@oracle.com> I just feel that using ExceptionCheck call (than null), it's more obvious that there is already a pending exception. So, for me, it offers more clarity, comparing to checking for null which some JNI calls return when errors are encountered (however, there may be no pending exceptions at least according to JNI spec, e.g. no corresponding "THROWS" paragraph. Thanks for the review, Valerie On 03/05/14 11:50, Anthony Scarpino wrote: > On 02/13/2014 03:29 PM, Valerie (Yu-Ching) Peng wrote: >> >> Can someone please review the fixes which checks for pending exceptions >> in native code "pcsc_md.c"? >> The fix is trivial scope-wise. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8033571/webrev.00/ >> >> Thanks, >> Valerie > > In my change that's out for review, 8036543, I only checked for > findFunction() returning null, while you used ExceptionCheck. Was > there something you saw that caused you to check for an exception > thrown rather than null? > > Either way the change looks good to me. > > Tony > From valerie.peng at oracle.com Wed Mar 5 23:52:16 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 05 Mar 2014 15:52:16 -0800 Subject: Code review request: 8036543 Parfait JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c In-Reply-To: <5316CAB4.7060704@oracle.com> References: <5316CAB4.7060704@oracle.com> Message-ID: <5317B8B0.7080009@oracle.com> line 133 - 138, I think it's better to take the ReleaseStringUTFChars() call of 'configDir' out of the block for 'functionName'. So we can ensure that both are released even if the code from 82-94 are somehow later altered. The rest looks fine. Thanks, Valerie On 03/04/14 22:56, Anthony Scarpino wrote: > Hi, > > I need a review for changes that cover JNI pending exceptions for > j2secmod.c, j2secmod_md.c, and p11_md.c > > http://cr.openjdk.java.net/~ascarpino/8036543/webrev.00/ > > thanks > > Tony From anthony.scarpino at oracle.com Thu Mar 6 00:02:27 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 05 Mar 2014 16:02:27 -0800 Subject: Code review request: 8036543 Parfait JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c In-Reply-To: <5317B8B0.7080009@oracle.com> References: <5316CAB4.7060704@oracle.com> <5317B8B0.7080009@oracle.com> Message-ID: <5317BB13.4070805@oracle.com> Sure.. I debated that piece of code before the review too. Tony On 03/05/2014 03:52 PM, Valerie (Yu-Ching) Peng wrote: > > > line 133 - 138, I think it's better to take the ReleaseStringUTFChars() > call of 'configDir' out of the block for 'functionName'. > So we can ensure that both are released even if the code from 82-94 are > somehow later altered. > > The rest looks fine. > Thanks, > Valerie > > On 03/04/14 22:56, Anthony Scarpino wrote: >> Hi, >> >> I need a review for changes that cover JNI pending exceptions for >> j2secmod.c, j2secmod_md.c, and p11_md.c >> >> http://cr.openjdk.java.net/~ascarpino/8036543/webrev.00/ >> >> thanks >> >> Tony > From valerie.peng at oracle.com Thu Mar 6 00:53:59 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 05 Mar 2014 16:53:59 -0800 Subject: Review Request for JDK-8030114: [parfait] warnings from b119 for jdk.src.share.native.sun.security.smartcardio: JNI exception pending In-Reply-To: <5307F235.4030401@oracle.com> References: <52FD63BE.9080004@oracle.com> <52FE28F7.5010408@redhat.com> <5307F235.4030401@oracle.com> Message-ID: <5317C727.6090302@oracle.com> I still need a reviewer for integrating the changes for 8030114... Any taker? Thanks, Valerie On 02/21/14 16:41, Valerie (Yu-Ching) Peng wrote: > > Good points, I have updated the webrev accordingly. > The current callers of > Java_sun_security_smartcardio_PCSC_SCardGetStatusChange seems to only > pass 1 reader at a time, so I just moved the free call to a separate > loop as part of cleanup. > > Webrev is updated at: > http://cr.openjdk.java.net/~valeriep/8030114/webrev.01/ > Thanks, > Valerie > > On 02/14/14 06:32, Florian Weimer wrote: >> On 02/14/2014 01:30 AM, Valerie (Yu-Ching) Peng wrote: >> >>> Can someone please review the fixes which checks for pending exceptions >>> in native code "pcsc.c"? >>> The fix is straightforward for all except the changes under >>> Java_sun_security_smartcardio_PCSC_SCardGetStatusChange(...) method >>> which is somewhat complicated due to the need to free up memories. >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8030114/webrev.00/ >> >> It seems to me there is a slight behavioral change in >> Java_sun_security_smartcardio_PCSC_SCardStatus. I think the >> ArrayIndexOutofBoundsException is no longer thrown if the status >> array is too short. >> >> The logic in Java_sun_security_smartcardio_PCSC_SCardGetStatusChange >> appears to be correct, but I wonder if it would be clearer to use >> calloc for allocation and avoid the interlocked i/j/k loop counters, >> at the cost of calling free on a few NULL pointers. >> > > From joe.darcy at oracle.com Thu Mar 6 01:35:59 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 05 Mar 2014 17:35:59 -0800 Subject: JDK 9 RFR of JDK-8036747: Fix unchecked lint warnings in java.security.Provider Message-ID: <5317D0FF.7060608@oracle.com> Hello, Please review the patch below which addresses JDK-8036747: Fix unchecked lint warnings in java.security.Provider In brief, java.security.Provider extends Properties which in extends Hashtable even though morally Properties are a Map. The implementations of new-in-JDK-8 methods like replaceAll(BiFunction function) need to have a public signature where K and V are replaced with "Object", but the actual function needs to operate over "String". The patch suppresses warnings related to several unchecked casts from Object-based functions to String-based functions. Thanks, -Joe diff -r 07d78a5dd853 src/share/classes/java/security/Provider.java --- a/src/share/classes/java/security/Provider.java Wed Mar 05 17:08:37 2014 -0800 +++ b/src/share/classes/java/security/Provider.java Wed Mar 05 17:30:04 2014 -0800 @@ -769,6 +769,7 @@ return super.replace(key, value); } + @SuppressWarnings("unchecked") // Function must actually operate over strings private void implReplaceAll(BiFunction function) { legacyChanged = true; if (legacyStrings == null) { @@ -779,7 +780,7 @@ super.replaceAll(function); } - + @SuppressWarnings("unchecked") // Function must actually operate over strings private Object implMerge(Object key, Object value, BiFunction remappingFunction) { if ((key instanceof String) && (value instanceof String)) { if (!checkLegacy(key)) { @@ -791,6 +792,7 @@ return super.merge(key, value, remappingFunction); } + @SuppressWarnings("unchecked") // Function must actually operate over strings private Object implCompute(Object key, BiFunction remappingFunction) { if (key instanceof String) { if (!checkLegacy(key)) { @@ -802,6 +804,7 @@ return super.compute(key, remappingFunction); } + @SuppressWarnings("unchecked") // Function must actually operate over strings private Object implComputeIfAbsent(Object key, Function mappingFunction) { if (key instanceof String) { if (!checkLegacy(key)) { @@ -813,6 +816,7 @@ return super.computeIfAbsent(key, mappingFunction); } + @SuppressWarnings("unchecked") // Function must actually operate over strings private Object implComputeIfPresent(Object key, BiFunction remappingFunction) { if (key instanceof String) { if (!checkLegacy(key)) { From xuelei.fan at oracle.com Thu Mar 6 05:22:30 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 06 Mar 2014 13:22:30 +0800 Subject: JDK 9 RFR of JDK-8036747: Fix unchecked lint warnings in java.security.Provider In-Reply-To: <5317D0FF.7060608@oracle.com> References: <5317D0FF.7060608@oracle.com> Message-ID: <53180616.7050300@oracle.com> Looks fine to me. Thanks, Joe! Xuelei On 3/6/2014 9:35 AM, Joe Darcy wrote: > Hello, > > Please review the patch below which addresses > > JDK-8036747: Fix unchecked lint warnings in java.security.Provider > > In brief, java.security.Provider extends Properties which in extends > Hashtable even though morally Properties are a > Map. > > The implementations of new-in-JDK-8 methods like > > replaceAll(BiFunction function) > > need to have a public signature where K and V are replaced with > "Object", but the actual function needs to operate over "String". > > The patch suppresses warnings related to several unchecked casts from > Object-based functions to String-based functions. > > Thanks, > > -Joe > > diff -r 07d78a5dd853 src/share/classes/java/security/Provider.java > --- a/src/share/classes/java/security/Provider.java Wed Mar 05 > 17:08:37 2014 -0800 > +++ b/src/share/classes/java/security/Provider.java Wed Mar 05 > 17:30:04 2014 -0800 > @@ -769,6 +769,7 @@ > return super.replace(key, value); > } > > + @SuppressWarnings("unchecked") // Function must actually operate > over strings > private void implReplaceAll(BiFunction Object, ? extends Object> function) { > legacyChanged = true; > if (legacyStrings == null) { > @@ -779,7 +780,7 @@ > super.replaceAll(function); > } > > - > + @SuppressWarnings("unchecked") // Function must actually operate > over strings > private Object implMerge(Object key, Object value, BiFunction super Object, ? super Object, ? extends Object> remappingFunction) { > if ((key instanceof String) && (value instanceof String)) { > if (!checkLegacy(key)) { > @@ -791,6 +792,7 @@ > return super.merge(key, value, remappingFunction); > } > > + @SuppressWarnings("unchecked") // Function must actually operate > over strings > private Object implCompute(Object key, BiFunction super Object, ? extends Object> remappingFunction) { > if (key instanceof String) { > if (!checkLegacy(key)) { > @@ -802,6 +804,7 @@ > return super.compute(key, remappingFunction); > } > > + @SuppressWarnings("unchecked") // Function must actually operate > over strings > private Object implComputeIfAbsent(Object key, Function Object, ? extends Object> mappingFunction) { > if (key instanceof String) { > if (!checkLegacy(key)) { > @@ -813,6 +816,7 @@ > return super.computeIfAbsent(key, mappingFunction); > } > > + @SuppressWarnings("unchecked") // Function must actually operate > over strings > private Object implComputeIfPresent(Object key, BiFunction Object, ? super Object, ? extends Object> remappingFunction) { > if (key instanceof String) { > if (!checkLegacy(key)) { > From valerie.peng at oracle.com Thu Mar 6 19:24:57 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 06 Mar 2014 11:24:57 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <531115DB.5080708@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> <52FD1A28.8050808@oracle.com> <5307D548.2080606@oracle.com> <531115DB.5080708@oracle.com> Message-ID: <5318CB89.2030808@oracle.com> Tony, I like this version better - a local "instance" session pool for P11Cipher is a bit excessive I think. One thing that I noticed with this change is that by switching to the ConcurrentLinkedQueue, you are retrieving sessions from the head and put them back at the end. This is different from the original approach of first-in-last-out. The subtlety in this is that it will take longer in order for sessions to pass their MAX_IDLE_TIME and be closed to shrink the pool size down. What is the synchronized(this) call for in the various debug code? I am still going through the rest of SessionManager.java file but should finish today. Thanks, Valerie On 02/28/14 15:03, Anthony Scarpino wrote: > So I ran a stress test creating a number of keys and did not see much > different memory wise. But what I did notice that the performance was > dependent on the number Cipher.init() calls. If each thread only has > one Cipher.init() call, it performed 5x better (170k vs 844k ops/m), > but as soon as you add any additional Cipher.init() calls the > performance dropped to equal without this change. > > When I changed the code to remove the local pool in P11Cipher, the > performance was lower, but still 4.5x faster (170k vs 768k ops/m). > > While there is some performance on the table from an performance > test/non-real world standpoint, it does keep session management in > SessionManager. I see value doing it this way given as it's an update > to the modern concurrent class rather than old List with synchronized > methods. Valerie, would be more comfortable with the solution? > > http://cr.openjdk.java.net/~ascarpino/7107611/webrev.02/ > > Tony > > On 02/21/2014 02:38 PM, Valerie (Yu-Ching) Peng wrote: >> >> Where can I find the updated webrev? >> >> As for the performance test, I think we can probably try a "worse-case" >> (say 5000 Cipher objects which we don't re-use, just create, do >> operation, and then discard) and "best-case" (same # of objects, but >> re-use) against both impls and see how much a difference we'd observe. >> >> Thanks, >> Valerie >> >> On 02/13/14 11:16, Anthony Scarpino wrote: >>> On 02/11/2014 02:18 PM, Valerie (Yu-Ching) Peng wrote: >>>> >>>> Please see comments inline. >>>> >>>> On 02/10/14 16:30, Anthony Scarpino wrote: >>>>> On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote: >>>>>> >>>>>> Well, there are some changes that look strange which I need more >>>>>> time to >>>>>> figure out. >>>>>> For example, the purpose for the 2 new pkg private methods of >>>>>> poll(Pool) >>>>>> and release(Pool, Session) of the static class Pool. >>>>> >>>>> New methods are for supporting local pools. >>>> >>>> Yes, I can tell that they are for supporting the local pools, but are >>>> they really necessary and why do they belong in class Pool as instance >>>> methods? >>>> For example, the Pool.release(Pool, Session) method seems >>>> redundant, the >>>> caller can simply just call the release method on the cachePool >>>> argument >>>> as it has nothing to do with the Pool object that it invokes upon. >>>> Secondly, the poll method also seems strange as the cachePool is used >>>> first and the actual Pool object is only acting as backup. It's >>>> kind of >>>> ambiguous on what it is expected to do unless you looked at its >>>> implementation. >>> >>> I didn't notice that these methods aren't even called in addition to >>> being pointless like you say. I'm removing them >>>> >>>>> >>>>>> >>>>>> Also, now that every P11Cipher "object" has its own session pool, >>>>>> will >>>>>> this have any impact on the overall memory usage. >>>>> >>>>> I would think the memory usage would mostly transfer the session from >>>>> SessionManager to P11Cipher. >>>> >>>> The session object itself may be transferred and does not matter, but >>>> the supporting structure, e.g. esp. the queue, is now present in every >>>> P11Cipher object. How much impact this has will depend on how >>>> List/ConcurrentLinkedQueue is implemented as well as the P11Cipher >>>> usages in the calling application. It's essential to verify that this >>>> change has NO significant impact on other apps such as some JSSE apps. >>> >>> Is there a perf test you'd recommend to try this? >>> >>>> Valerie >>>>> It is true that if many P11Cipher objects are created, that could be >>>>> more idle op session around if P11Cipher objects lingers. But the >>>>> object session stay in SessionManager, which is probably the bulk of >>>>> the memory usage. >>>>> >>>>>> If P11Cipher object is not re-used much and only have a short life >>>>>> span, >>>>>> what's the point of having a local session pool to re-use the >>>>>> sessions. >>>>> >>>>> If the P11Cipher object is created sparingly and short lived, >>>>> creating >>>>> one session for usage and then getting gc'ed, I would suspect crypto >>>>> performance isn't a top issue. But I could see that only >>>>> happening in >>>>> large crypto deployments using that methodology; however, I'm not >>>>> sure >>>>> that is wise development methodology to start with. You'd better >>>>> insight if such designs are common. >>>> >>>> >>>>> >>>>> >>>>> Tony >>>>> >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> >>>>>> >>>>>> On 02/03/14 10:24, Anthony Scarpino wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm requesting a review of these changes. It is mostly from the >>>>>>> patch >>>>>>> that Intel provided, but I have made some cosmetic changes. The >>>>>>> changes significantly improve performance in multithreaded >>>>>>> application >>>>>>> using pkcs11. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.00/ >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Tony >>>>>> >>>>> >>>> >>> >> >> > From philipp.heckel at gmail.com Thu Mar 6 20:14:06 2014 From: philipp.heckel at gmail.com (Philipp Heckel) Date: Thu, 6 Mar 2014 21:14:06 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <53170DD0.4030402@oracle.com> References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> Message-ID: Hello again, I think the implementation of GCM cipher should respect the > specification of GCM mode. Before authentication tag get checked, no > plaintext should be released to application. See section 7.0 of GCM spec > (NIST SP-800-38D). > Wow! Strictly speaking, it seems like the GCM spec actually says that: "In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise, FAIL is returned". So I guess we are at a deadlock: - Implementing it so that it can be used in practice (esp. for large files) does not comply with the specification, b/c it returns unauthenticated bytes and only throws a bad tag exception at the end - And implementing it as defined per specification is theoretically correct, but completely unusable for large files, because it requires a memory buffer of the size of the file Before this dies out entirely (again), here's what I understand is the status quo: - Using javax.crypto.CipherInputStream with a cipher in GCM mode and the BC provider is insecure, because tampering is possible! - Using javax.crypto.CipherInputStream with a cipher in GCM mode and the SunJCE provider (JDK8+) is secure, but cannot be used large files, because it will buffer all data until the tag is verified (as defined by the GCM spec) [1] - Using org.bouncycaslte.crypto.io.CipherInputStream with a cipher in GCM mode and the BC provider is secure and can be used for large files. However it does not work exactly like the GCM spec defined; namely, it returns unauthenticated data before the tag has been checked. Do you think it would be possible to at least mention possible issues like this in the JavaDoc for CipherInputStream? Thanks for the interesting discussion! Best Philipp [1] http://hg.openjdk.java.net/jdk8/build/jdk/file/687fd7c7986d/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Thu Mar 6 20:59:03 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 06 Mar 2014 12:59:03 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <5318CB89.2030808@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> <52FD1A28.8050808@oracle.com> <5307D548.2080606@oracle.com> <531115DB.5080708@oracle.com> <5318CB89.2030808@oracle.com> Message-ID: <5318E197.7070400@oracle.com> On 03/06/2014 11:24 AM, Valerie (Yu-Ching) Peng wrote: > Tony, > > I like this version better - a local "instance" session pool for > P11Cipher is a bit excessive I think. > > One thing that I noticed with this change is that by switching to the > ConcurrentLinkedQueue, you are retrieving sessions from the head and put > them back at the end. This is different from the original approach of > first-in-last-out. The subtlety in this is that it will take longer in > order for sessions to pass their MAX_IDLE_TIME and be closed to shrink > the pool size down. I didn't feel this was a big expense. Yes it does pull the oldest session first, but my thinking was the queue was to handle surges in usage. A possible extra session or two wasn't a big deal. If you prefer me to go to the original method, I can change their patch to use ConcurrentLinkedDeque, which does allow push and pop from both ends of the queue > What is the synchronized(this) call for in the various debug code? > I am still going through the rest of SessionManager.java file but should > finish today. Yes, two of those seem useless, the last one does set maxActiveSessions, so I should leave that in. > Thanks, > Valerie > > On 02/28/14 15:03, Anthony Scarpino wrote: >> So I ran a stress test creating a number of keys and did not see much >> different memory wise. But what I did notice that the performance was >> dependent on the number Cipher.init() calls. If each thread only has >> one Cipher.init() call, it performed 5x better (170k vs 844k ops/m), >> but as soon as you add any additional Cipher.init() calls the >> performance dropped to equal without this change. >> >> When I changed the code to remove the local pool in P11Cipher, the >> performance was lower, but still 4.5x faster (170k vs 768k ops/m). >> >> While there is some performance on the table from an performance >> test/non-real world standpoint, it does keep session management in >> SessionManager. I see value doing it this way given as it's an update >> to the modern concurrent class rather than old List with synchronized >> methods. Valerie, would be more comfortable with the solution? >> >> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.02/ >> >> Tony >> >> On 02/21/2014 02:38 PM, Valerie (Yu-Ching) Peng wrote: >>> >>> Where can I find the updated webrev? >>> >>> As for the performance test, I think we can probably try a "worse-case" >>> (say 5000 Cipher objects which we don't re-use, just create, do >>> operation, and then discard) and "best-case" (same # of objects, but >>> re-use) against both impls and see how much a difference we'd observe. >>> >>> Thanks, >>> Valerie >>> >>> On 02/13/14 11:16, Anthony Scarpino wrote: >>>> On 02/11/2014 02:18 PM, Valerie (Yu-Ching) Peng wrote: >>>>> >>>>> Please see comments inline. >>>>> >>>>> On 02/10/14 16:30, Anthony Scarpino wrote: >>>>>> On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>> >>>>>>> Well, there are some changes that look strange which I need more >>>>>>> time to >>>>>>> figure out. >>>>>>> For example, the purpose for the 2 new pkg private methods of >>>>>>> poll(Pool) >>>>>>> and release(Pool, Session) of the static class Pool. >>>>>> >>>>>> New methods are for supporting local pools. >>>>> >>>>> Yes, I can tell that they are for supporting the local pools, but are >>>>> they really necessary and why do they belong in class Pool as instance >>>>> methods? >>>>> For example, the Pool.release(Pool, Session) method seems >>>>> redundant, the >>>>> caller can simply just call the release method on the cachePool >>>>> argument >>>>> as it has nothing to do with the Pool object that it invokes upon. >>>>> Secondly, the poll method also seems strange as the cachePool is used >>>>> first and the actual Pool object is only acting as backup. It's >>>>> kind of >>>>> ambiguous on what it is expected to do unless you looked at its >>>>> implementation. >>>> >>>> I didn't notice that these methods aren't even called in addition to >>>> being pointless like you say. I'm removing them >>>>> >>>>>> >>>>>>> >>>>>>> Also, now that every P11Cipher "object" has its own session pool, >>>>>>> will >>>>>>> this have any impact on the overall memory usage. >>>>>> >>>>>> I would think the memory usage would mostly transfer the session from >>>>>> SessionManager to P11Cipher. >>>>> >>>>> The session object itself may be transferred and does not matter, but >>>>> the supporting structure, e.g. esp. the queue, is now present in every >>>>> P11Cipher object. How much impact this has will depend on how >>>>> List/ConcurrentLinkedQueue is implemented as well as the P11Cipher >>>>> usages in the calling application. It's essential to verify that this >>>>> change has NO significant impact on other apps such as some JSSE apps. >>>> >>>> Is there a perf test you'd recommend to try this? >>>> >>>>> Valerie >>>>>> It is true that if many P11Cipher objects are created, that could be >>>>>> more idle op session around if P11Cipher objects lingers. But the >>>>>> object session stay in SessionManager, which is probably the bulk of >>>>>> the memory usage. >>>>>> >>>>>>> If P11Cipher object is not re-used much and only have a short life >>>>>>> span, >>>>>>> what's the point of having a local session pool to re-use the >>>>>>> sessions. >>>>>> >>>>>> If the P11Cipher object is created sparingly and short lived, >>>>>> creating >>>>>> one session for usage and then getting gc'ed, I would suspect crypto >>>>>> performance isn't a top issue. But I could see that only >>>>>> happening in >>>>>> large crypto deployments using that methodology; however, I'm not >>>>>> sure >>>>>> that is wise development methodology to start with. You'd better >>>>>> insight if such designs are common. >>>>> >>>>> >>>>>> >>>>>> >>>>>> Tony >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 02/03/14 10:24, Anthony Scarpino wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm requesting a review of these changes. It is mostly from the >>>>>>>> patch >>>>>>>> that Intel provided, but I have made some cosmetic changes. The >>>>>>>> changes significantly improve performance in multithreaded >>>>>>>> application >>>>>>>> using pkcs11. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.00/ >>>>>>>> >>>>>>>> thanks >>>>>>>> >>>>>>>> Tony >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From bernd-2014 at eckenfels.net Thu Mar 6 21:01:57 2014 From: bernd-2014 at eckenfels.net (Bernd Eckenfels) Date: Thu, 6 Mar 2014 22:01:57 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> Message-ID: <20140306220157.0000642c.bernd-2014@eckenfels.net> Am Thu, 6 Mar 2014 21:14:06 +0100 schrieb Philipp Heckel : > - Using org.bouncycaslte.crypto.io.CipherInputStream with a cipher in > GCM mode and the BC provider is secure and can be used for large > files. However it does not work exactly like the GCM spec defined; > namely, it returns unauthenticated data before the tag has been > checked. My thinking was, that the "streamed" mode is usefull, but the "secure" mode is also usefull. At least for BC I would recommend to have two different cipher specs. A /GCM/ and a /GCMSTREAM/ mode. The later one would not be enabled in FIPS mode. (Ideally BC uses the same secure semantics with the JCE compatible spec). > Do you think it would be possible to at least mention possible issues > like this in the JavaDoc for CipherInputStream? I think this is very important to be mentioned that it suppresses padding and authentication exceptions in the Javadoc. Greetings Bernd From anthony.scarpino at oracle.com Thu Mar 6 22:37:34 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 06 Mar 2014 14:37:34 -0800 Subject: Code review request: 8036543 Parfait JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c In-Reply-To: <5317BB13.4070805@oracle.com> References: <5316CAB4.7060704@oracle.com> <5317B8B0.7080009@oracle.com> <5317BB13.4070805@oracle.com> Message-ID: <5318F8AE.5090801@oracle.com> webrev updated at: http://cr.openjdk.java.net/~ascarpino/8036543/webrev.01/ On 03/05/2014 04:02 PM, Anthony Scarpino wrote: > Sure.. I debated that piece of code before the review too. > > Tony > > On 03/05/2014 03:52 PM, Valerie (Yu-Ching) Peng wrote: >> >> >> line 133 - 138, I think it's better to take the ReleaseStringUTFChars() >> call of 'configDir' out of the block for 'functionName'. >> So we can ensure that both are released even if the code from 82-94 are >> somehow later altered. >> >> The rest looks fine. >> Thanks, >> Valerie >> >> On 03/04/14 22:56, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a review for changes that cover JNI pending exceptions for >>> j2secmod.c, j2secmod_md.c, and p11_md.c >>> >>> http://cr.openjdk.java.net/~ascarpino/8036543/webrev.00/ >>> >>> thanks >>> >>> Tony >> > From xuelei.fan at oracle.com Thu Mar 6 23:03:27 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 07 Mar 2014 07:03:27 +0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> Message-ID: <5318FEBF.7090103@oracle.com> On 3/7/2014 4:14 AM, Philipp Heckel wrote: > - Using org.bouncycaslte.crypto.io.CipherInputStream with a cipher in > GCM mode and the BC provider is secure and can be used for large files. > However it does not work exactly like the GCM spec defined; namely, it > returns unauthenticated data before the tag has been checked. In such a case, if the the bytes read from the stream (CipherInputStream) is used in applications (for example, save the bytes, and then close the stream. Even you can catch the exception, did the dev really program to rollback the previous actions, especially for large chunk of data? In some cases, one have to buffer something, here or there, this way or that way.), it cannot be granted that the bytes are the expected bytes, as the tag has not been checked. Therefore, it is not secure from my point. Xuelei From mhall at mhcomputing.net Thu Mar 6 23:44:27 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 6 Mar 2014 15:44:27 -0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <20140306220157.0000642c.bernd-2014@eckenfels.net> References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> <20140306220157.0000642c.bernd-2014@eckenfels.net> Message-ID: <20140306234427.GA21456@mhcomputing.net> On Thu, Mar 06, 2014 at 10:01:57PM +0100, Bernd Eckenfels wrote: > My thinking was, that the "streamed" mode is usefull, but the "secure" > mode is also usefull. At least for BC I would recommend to have two > different cipher specs. A /GCM/ and a /GCMSTREAM/ mode. The later one > would not be enabled in FIPS mode. (Ideally BC uses the same secure > semantics with the JCE compatible spec). Then you get very poor performance, with double-buffering, when the product is put into the FIPS mode. Matthew. From valerie.peng at oracle.com Fri Mar 7 00:12:56 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 06 Mar 2014 16:12:56 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <5318E197.7070400@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> <52FD1A28.8050808@oracle.com> <5307D548.2080606@oracle.com> <531115DB.5080708@oracle.com> <5318CB89.2030808@oracle.com> <5318E197.7070400@oracle.com> Message-ID: <53190F08.3020709@oracle.com> Last time when I was debugging/observing the session pools, it's not just one or two sessions in the queue. It's at least hundreds possibly thousands when I ran one of the SSL stress tests. 1) line 273, do you really mean to return when the oldestSession.isLive() returns false?? 2) line 275 is changed to "return". Wouldn't this mean that the debug statement on line 282-285 will rarely if ever be executed? I think the main performance boost that we gained here is because we switched from a synchronize everything approach to a very fine-grained-synchronization one. The concern that I have is that is whether we need additional synchronization will be required as there are several calls involving the "pool" field in the Pool.release(Session) method which have no additional synchronization involved... This seems a bit too loose? Regards, Valerie On 03/06/14 12:59, Anthony Scarpino wrote: > On 03/06/2014 11:24 AM, Valerie (Yu-Ching) Peng wrote: >> Tony, >> >> I like this version better - a local "instance" session pool for >> P11Cipher is a bit excessive I think. >> >> One thing that I noticed with this change is that by switching to the >> ConcurrentLinkedQueue, you are retrieving sessions from the head and put >> them back at the end. This is different from the original approach of >> first-in-last-out. The subtlety in this is that it will take longer in >> order for sessions to pass their MAX_IDLE_TIME and be closed to shrink >> the pool size down. > > I didn't feel this was a big expense. Yes it does pull the oldest > session first, but my thinking was the queue was to handle surges in > usage. A possible extra session or two wasn't a big deal. If you > prefer me to go to the original method, I can change their patch to > use ConcurrentLinkedDeque, which does allow push and pop from both > ends of the queue > >> What is the synchronized(this) call for in the various debug code? >> I am still going through the rest of SessionManager.java file but should >> finish today. > > Yes, two of those seem useless, the last one does set > maxActiveSessions, so I should leave that in. > > >> Thanks, >> Valerie >> >> On 02/28/14 15:03, Anthony Scarpino wrote: >>> So I ran a stress test creating a number of keys and did not see much >>> different memory wise. But what I did notice that the performance was >>> dependent on the number Cipher.init() calls. If each thread only has >>> one Cipher.init() call, it performed 5x better (170k vs 844k ops/m), >>> but as soon as you add any additional Cipher.init() calls the >>> performance dropped to equal without this change. >>> >>> When I changed the code to remove the local pool in P11Cipher, the >>> performance was lower, but still 4.5x faster (170k vs 768k ops/m). >>> >>> While there is some performance on the table from an performance >>> test/non-real world standpoint, it does keep session management in >>> SessionManager. I see value doing it this way given as it's an update >>> to the modern concurrent class rather than old List with synchronized >>> methods. Valerie, would be more comfortable with the solution? >>> >>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.02/ >>> >>> Tony >>> >>> On 02/21/2014 02:38 PM, Valerie (Yu-Ching) Peng wrote: >>>> >>>> Where can I find the updated webrev? >>>> >>>> As for the performance test, I think we can probably try a >>>> "worse-case" >>>> (say 5000 Cipher objects which we don't re-use, just create, do >>>> operation, and then discard) and "best-case" (same # of objects, but >>>> re-use) against both impls and see how much a difference we'd observe. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 02/13/14 11:16, Anthony Scarpino wrote: >>>>> On 02/11/2014 02:18 PM, Valerie (Yu-Ching) Peng wrote: >>>>>> >>>>>> Please see comments inline. >>>>>> >>>>>> On 02/10/14 16:30, Anthony Scarpino wrote: >>>>>>> On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>>> >>>>>>>> Well, there are some changes that look strange which I need more >>>>>>>> time to >>>>>>>> figure out. >>>>>>>> For example, the purpose for the 2 new pkg private methods of >>>>>>>> poll(Pool) >>>>>>>> and release(Pool, Session) of the static class Pool. >>>>>>> >>>>>>> New methods are for supporting local pools. >>>>>> >>>>>> Yes, I can tell that they are for supporting the local pools, but >>>>>> are >>>>>> they really necessary and why do they belong in class Pool as >>>>>> instance >>>>>> methods? >>>>>> For example, the Pool.release(Pool, Session) method seems >>>>>> redundant, the >>>>>> caller can simply just call the release method on the cachePool >>>>>> argument >>>>>> as it has nothing to do with the Pool object that it invokes upon. >>>>>> Secondly, the poll method also seems strange as the cachePool is >>>>>> used >>>>>> first and the actual Pool object is only acting as backup. It's >>>>>> kind of >>>>>> ambiguous on what it is expected to do unless you looked at its >>>>>> implementation. >>>>> >>>>> I didn't notice that these methods aren't even called in addition to >>>>> being pointless like you say. I'm removing them >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Also, now that every P11Cipher "object" has its own session pool, >>>>>>>> will >>>>>>>> this have any impact on the overall memory usage. >>>>>>> >>>>>>> I would think the memory usage would mostly transfer the session >>>>>>> from >>>>>>> SessionManager to P11Cipher. >>>>>> >>>>>> The session object itself may be transferred and does not matter, >>>>>> but >>>>>> the supporting structure, e.g. esp. the queue, is now present in >>>>>> every >>>>>> P11Cipher object. How much impact this has will depend on how >>>>>> List/ConcurrentLinkedQueue is implemented as well as the P11Cipher >>>>>> usages in the calling application. It's essential to verify that >>>>>> this >>>>>> change has NO significant impact on other apps such as some JSSE >>>>>> apps. >>>>> >>>>> Is there a perf test you'd recommend to try this? >>>>> >>>>>> Valerie >>>>>>> It is true that if many P11Cipher objects are created, that >>>>>>> could be >>>>>>> more idle op session around if P11Cipher objects lingers. But the >>>>>>> object session stay in SessionManager, which is probably the >>>>>>> bulk of >>>>>>> the memory usage. >>>>>>> >>>>>>>> If P11Cipher object is not re-used much and only have a short life >>>>>>>> span, >>>>>>>> what's the point of having a local session pool to re-use the >>>>>>>> sessions. >>>>>>> >>>>>>> If the P11Cipher object is created sparingly and short lived, >>>>>>> creating >>>>>>> one session for usage and then getting gc'ed, I would suspect >>>>>>> crypto >>>>>>> performance isn't a top issue. But I could see that only >>>>>>> happening in >>>>>>> large crypto deployments using that methodology; however, I'm not >>>>>>> sure >>>>>>> that is wise development methodology to start with. You'd better >>>>>>> insight if such designs are common. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Tony >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 02/03/14 10:24, Anthony Scarpino wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm requesting a review of these changes. It is mostly from the >>>>>>>>> patch >>>>>>>>> that Intel provided, but I have made some cosmetic changes. The >>>>>>>>> changes significantly improve performance in multithreaded >>>>>>>>> application >>>>>>>>> using pkcs11. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.00/ >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> >>>>>>>>> Tony >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From valerie.peng at oracle.com Fri Mar 7 00:32:36 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 06 Mar 2014 16:32:36 -0800 Subject: Code review request: 8036543 Parfait JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c In-Reply-To: <5318F8AE.5090801@oracle.com> References: <5316CAB4.7060704@oracle.com> <5317B8B0.7080009@oracle.com> <5317BB13.4070805@oracle.com> <5318F8AE.5090801@oracle.com> Message-ID: <531913A4.4020008@oracle.com> How about line 223, there may be a pending exception thrown as well and this is inside a loop? Valerie On 03/06/14 14:37, Anthony Scarpino wrote: > webrev updated at: > http://cr.openjdk.java.net/~ascarpino/8036543/webrev.01/ > > On 03/05/2014 04:02 PM, Anthony Scarpino wrote: >> Sure.. I debated that piece of code before the review too. >> >> Tony >> >> On 03/05/2014 03:52 PM, Valerie (Yu-Ching) Peng wrote: >>> >>> >>> line 133 - 138, I think it's better to take the ReleaseStringUTFChars() >>> call of 'configDir' out of the block for 'functionName'. >>> So we can ensure that both are released even if the code from 82-94 are >>> somehow later altered. >>> >>> The rest looks fine. >>> Thanks, >>> Valerie >>> >>> On 03/04/14 22:56, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I need a review for changes that cover JNI pending exceptions for >>>> j2secmod.c, j2secmod_md.c, and p11_md.c >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8036543/webrev.00/ >>>> >>>> thanks >>>> >>>> Tony >>> >> > From bernd-2014 at eckenfels.net Fri Mar 7 01:33:58 2014 From: bernd-2014 at eckenfels.net (Bernd Eckenfels) Date: Fri, 7 Mar 2014 02:33:58 +0100 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <20140306234427.GA21456@mhcomputing.net> References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> <20140306220157.0000642c.bernd-2014@eckenfels.net> <20140306234427.GA21456@mhcomputing.net> Message-ID: <20140307023358.00002d84.bernd-2014@eckenfels.net> Hello Matthew, List, Am Thu, 6 Mar 2014 15:44:27 -0800 schrieb Matthew Hall : > On Thu, Mar 06, 2014 at 10:01:57PM +0100, Bernd Eckenfels wrote: > > My thinking was, that the "streamed" mode is usefull, but the > > "secure" mode is also usefull. At least for BC I would recommend to > > have two different cipher specs. A /GCM/ and a /GCMSTREAM/ mode. > > The later one would not be enabled in FIPS mode. (Ideally BC uses > > the same secure semantics with the JCE compatible spec). > > Then you get very poor performance, with double-buffering, when the > product is put into the FIPS mode. Indeed, the "closed box" mode of the JCE Cipher where no unauthenticated bytes are released has worse performance (large footprint, no parallel stream processing), but there is a reason to do it this way (like Florian, Valerie and Xuelei pointed out). That is, why I want to keep the non-compliant mode of BC (especially as it does not sound like Oracle/OpenJDK want to ship it). For BC it would be wise to actually use a cipher identifier which is different from the JCE one if the semantic is different (some argue better, some argue worse). If I know my steps which deal with the stream are safe (for example I write the result to a temp file which gets deleted if close fails verification) I can request the "unsafe" mode. If I implement something like a "telnet" application I better make sure commands are not executed before the trailer is verified (and therefore I use the normal Cipher spec with the internal buffering of JDK8 provider). In those situations the segments are typically small (think JSSE/TLS). A small general comment: GCM is so hyped, and in other crypto system implementations it really looks like a very good choice. But in the Java world the missing native support (with resulting poor performance) and this issue about compliance makes it a very bad choice. And I think this also applies to ciphers. IMHO a JEP to improve this situation is very much needed. Gruss Bernd From jason.uh at oracle.com Fri Mar 7 02:25:57 2014 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 06 Mar 2014 18:25:57 -0800 Subject: [9] Request for Review: 8036844: test failures due to wrong keystore paths Message-ID: <53192E35.4020609@oracle.com> Please review this fix for 8036844, which updates the path to a keystore used in a couple of tests. The path is no longer accurate after the recent changes to the JSSE test hierarchy. This webrev also includes a patch from Max for an enhancement to printssl.sh to correctly handle a failure in PrintSSL. webrev: http://cr.openjdk.java.net/~juh/8036844/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8036844 Jason From weijun.wang at oracle.com Fri Mar 7 02:38:04 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 7 Mar 2014 10:38:04 +0800 Subject: [9] Request for Review: 8036844: test failures due to wrong keystore paths In-Reply-To: <53192E35.4020609@oracle.com> References: <53192E35.4020609@oracle.com> Message-ID: Change looks fine. *Xuelei*: Remember to run all tests next time. At least a JPRT. Thanks Max On Mar 7, 2014, at 10:25, Jason Uh wrote: > Please review this fix for 8036844, which updates the path to a keystore used in a couple of tests. The path is no longer accurate after the recent changes to the JSSE test hierarchy. This webrev also includes a patch from Max for an enhancement to printssl.sh to correctly handle a failure in PrintSSL. > > webrev: http://cr.openjdk.java.net/~juh/8036844/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8036844 > > Jason From anthony.scarpino at oracle.com Fri Mar 7 03:21:23 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 06 Mar 2014 19:21:23 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <53190F08.3020709@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> <52FD1A28.8050808@oracle.com> <5307D548.2080606@oracle.com> <531115DB.5080708@oracle.com> <5318CB89.2030808@oracle.com> <5318E197.7070400@oracle.com> <53190F08.3020709@oracle.com> Message-ID: <53193B33.8060304@oracle.com> On 03/06/2014 04:12 PM, Valerie (Yu-Ching) Peng wrote: > > Last time when I was debugging/observing the session pools, it's not > just one or two sessions in the queue. It's at least hundreds possibly > thousands when I ran one of the SSL stress tests. > > 1) line 273, do you really mean to return when the > oldestSession.isLive() returns false?? Yeah, got that backwards > 2) line 275 is changed to "return". Wouldn't this mean that the debug > statement on line 282-285 will rarely if ever be executed? replacing with a break should fix that > I think the main performance boost that we gained here is because we > switched from a synchronize everything approach to a very > fine-grained-synchronization one. The concern that I have is that is > whether we need additional synchronization will be required as there are > several calls involving the "pool" field in the Pool.release(Session) > method which have no additional synchronization involved... This seems a > bit too loose? I think it's fine, My checking if a session is old uses a peek, leaving the entry in the queue. Then if it is old and I want to return it, pool.remove() is thread safe, so it returns false if the entry is gone and I can exit the loop because the queue has changed significantly and the closing of the session is skipped. Only the thread that removed the session from the queue can close it. It does get complicated because the original version kept at least one session in the queue, i tried to keep that in this version. Ideally I would have run through the queue closing all old session even if that closed all op sessions; nevertheless, the above the peek keeps us from running into a problem. I've run this on a stress test with 256 threads for 10 minutes using AES and didn't have any exceptions or errors. I updated the webrev and with the change to use ConcurrentLinkedDeque instead. http://cr.openjdk.java.net/~ascarpino/7107611/webrev.03/ > > Regards, > Valerie > > On 03/06/14 12:59, Anthony Scarpino wrote: >> On 03/06/2014 11:24 AM, Valerie (Yu-Ching) Peng wrote: >>> Tony, >>> >>> I like this version better - a local "instance" session pool for >>> P11Cipher is a bit excessive I think. >>> >>> One thing that I noticed with this change is that by switching to the >>> ConcurrentLinkedQueue, you are retrieving sessions from the head and put >>> them back at the end. This is different from the original approach of >>> first-in-last-out. The subtlety in this is that it will take longer in >>> order for sessions to pass their MAX_IDLE_TIME and be closed to shrink >>> the pool size down. >> >> I didn't feel this was a big expense. Yes it does pull the oldest >> session first, but my thinking was the queue was to handle surges in >> usage. A possible extra session or two wasn't a big deal. If you >> prefer me to go to the original method, I can change their patch to >> use ConcurrentLinkedDeque, which does allow push and pop from both >> ends of the queue >> >>> What is the synchronized(this) call for in the various debug code? >>> I am still going through the rest of SessionManager.java file but should >>> finish today. >> >> Yes, two of those seem useless, the last one does set >> maxActiveSessions, so I should leave that in. >> >> >>> Thanks, >>> Valerie >>> >>> On 02/28/14 15:03, Anthony Scarpino wrote: >>>> So I ran a stress test creating a number of keys and did not see much >>>> different memory wise. But what I did notice that the performance was >>>> dependent on the number Cipher.init() calls. If each thread only has >>>> one Cipher.init() call, it performed 5x better (170k vs 844k ops/m), >>>> but as soon as you add any additional Cipher.init() calls the >>>> performance dropped to equal without this change. >>>> >>>> When I changed the code to remove the local pool in P11Cipher, the >>>> performance was lower, but still 4.5x faster (170k vs 768k ops/m). >>>> >>>> While there is some performance on the table from an performance >>>> test/non-real world standpoint, it does keep session management in >>>> SessionManager. I see value doing it this way given as it's an update >>>> to the modern concurrent class rather than old List with synchronized >>>> methods. Valerie, would be more comfortable with the solution? >>>> >>>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.02/ >>>> >>>> Tony >>>> >>>> On 02/21/2014 02:38 PM, Valerie (Yu-Ching) Peng wrote: >>>>> >>>>> Where can I find the updated webrev? >>>>> >>>>> As for the performance test, I think we can probably try a >>>>> "worse-case" >>>>> (say 5000 Cipher objects which we don't re-use, just create, do >>>>> operation, and then discard) and "best-case" (same # of objects, but >>>>> re-use) against both impls and see how much a difference we'd observe. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 02/13/14 11:16, Anthony Scarpino wrote: >>>>>> On 02/11/2014 02:18 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>> >>>>>>> Please see comments inline. >>>>>>> >>>>>>> On 02/10/14 16:30, Anthony Scarpino wrote: >>>>>>>> On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>>>> >>>>>>>>> Well, there are some changes that look strange which I need more >>>>>>>>> time to >>>>>>>>> figure out. >>>>>>>>> For example, the purpose for the 2 new pkg private methods of >>>>>>>>> poll(Pool) >>>>>>>>> and release(Pool, Session) of the static class Pool. >>>>>>>> >>>>>>>> New methods are for supporting local pools. >>>>>>> >>>>>>> Yes, I can tell that they are for supporting the local pools, but >>>>>>> are >>>>>>> they really necessary and why do they belong in class Pool as >>>>>>> instance >>>>>>> methods? >>>>>>> For example, the Pool.release(Pool, Session) method seems >>>>>>> redundant, the >>>>>>> caller can simply just call the release method on the cachePool >>>>>>> argument >>>>>>> as it has nothing to do with the Pool object that it invokes upon. >>>>>>> Secondly, the poll method also seems strange as the cachePool is >>>>>>> used >>>>>>> first and the actual Pool object is only acting as backup. It's >>>>>>> kind of >>>>>>> ambiguous on what it is expected to do unless you looked at its >>>>>>> implementation. >>>>>> >>>>>> I didn't notice that these methods aren't even called in addition to >>>>>> being pointless like you say. I'm removing them >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Also, now that every P11Cipher "object" has its own session pool, >>>>>>>>> will >>>>>>>>> this have any impact on the overall memory usage. >>>>>>>> >>>>>>>> I would think the memory usage would mostly transfer the session >>>>>>>> from >>>>>>>> SessionManager to P11Cipher. >>>>>>> >>>>>>> The session object itself may be transferred and does not matter, >>>>>>> but >>>>>>> the supporting structure, e.g. esp. the queue, is now present in >>>>>>> every >>>>>>> P11Cipher object. How much impact this has will depend on how >>>>>>> List/ConcurrentLinkedQueue is implemented as well as the P11Cipher >>>>>>> usages in the calling application. It's essential to verify that >>>>>>> this >>>>>>> change has NO significant impact on other apps such as some JSSE >>>>>>> apps. >>>>>> >>>>>> Is there a perf test you'd recommend to try this? >>>>>> >>>>>>> Valerie >>>>>>>> It is true that if many P11Cipher objects are created, that >>>>>>>> could be >>>>>>>> more idle op session around if P11Cipher objects lingers. But the >>>>>>>> object session stay in SessionManager, which is probably the >>>>>>>> bulk of >>>>>>>> the memory usage. >>>>>>>> >>>>>>>>> If P11Cipher object is not re-used much and only have a short life >>>>>>>>> span, >>>>>>>>> what's the point of having a local session pool to re-use the >>>>>>>>> sessions. >>>>>>>> >>>>>>>> If the P11Cipher object is created sparingly and short lived, >>>>>>>> creating >>>>>>>> one session for usage and then getting gc'ed, I would suspect >>>>>>>> crypto >>>>>>>> performance isn't a top issue. But I could see that only >>>>>>>> happening in >>>>>>>> large crypto deployments using that methodology; however, I'm not >>>>>>>> sure >>>>>>>> that is wise development methodology to start with. You'd better >>>>>>>> insight if such designs are common. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Tony >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/03/14 10:24, Anthony Scarpino wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'm requesting a review of these changes. It is mostly from the >>>>>>>>>> patch >>>>>>>>>> that Intel provided, but I have made some cosmetic changes. The >>>>>>>>>> changes significantly improve performance in multithreaded >>>>>>>>>> application >>>>>>>>>> using pkcs11. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.00/ >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> >>>>>>>>>> Tony >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From anthony.scarpino at oracle.com Fri Mar 7 03:38:38 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 06 Mar 2014 19:38:38 -0800 Subject: Code review request: 8036543 Parfait JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c In-Reply-To: <531913A4.4020008@oracle.com> References: <5316CAB4.7060704@oracle.com> <5317B8B0.7080009@oracle.com> <5317BB13.4070805@oracle.com> <5318F8AE.5090801@oracle.com> <531913A4.4020008@oracle.com> Message-ID: <53193F3E.9020707@oracle.com> Don't think parfait caught that one.. updated.... http://cr.openjdk.java.net/~ascarpino/8036543/webrev.02/ On 03/06/2014 04:32 PM, Valerie (Yu-Ching) Peng wrote: > > How about line 223, there may be a pending exception thrown as well and > this is inside a loop? > Valerie > > On 03/06/14 14:37, Anthony Scarpino wrote: >> webrev updated at: >> http://cr.openjdk.java.net/~ascarpino/8036543/webrev.01/ >> >> On 03/05/2014 04:02 PM, Anthony Scarpino wrote: >>> Sure.. I debated that piece of code before the review too. >>> >>> Tony >>> >>> On 03/05/2014 03:52 PM, Valerie (Yu-Ching) Peng wrote: >>>> >>>> >>>> line 133 - 138, I think it's better to take the ReleaseStringUTFChars() >>>> call of 'configDir' out of the block for 'functionName'. >>>> So we can ensure that both are released even if the code from 82-94 are >>>> somehow later altered. >>>> >>>> The rest looks fine. >>>> Thanks, >>>> Valerie >>>> >>>> On 03/04/14 22:56, Anthony Scarpino wrote: >>>>> Hi, >>>>> >>>>> I need a review for changes that cover JNI pending exceptions for >>>>> j2secmod.c, j2secmod_md.c, and p11_md.c >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/8036543/webrev.00/ >>>>> >>>>> thanks >>>>> >>>>> Tony >>>> >>> >> > From weijun.wang at oracle.com Fri Mar 7 07:31:49 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 7 Mar 2014 15:31:49 +0800 Subject: RFR 8035963: The failed Kerberos tests due to timeouts Message-ID: Hi All Please take a review of http://cr.openjdk.java.net/~weijun/8035963/webrev.00/ I've added a ratio variable to these timeout related tests. The ratio is now set to 2 (one exception, 3 for BadKdc2). This is mainly an experiment to how if they can be more stable when running slower. We will need to do some observation for a period of time. BTW, some of them are placed into ProblemList.txt for solaris-sparc. I remember there was a time when solaris-sparc machines run slow because of a hotspot change. Anyway, they are all liberated at the moment to join the experiment. FYI: The tests run fine on my desktop (Mac Mini) with a ratio of 0.4. JPRT runs fine. The windows-i586 job runs the slowest: -------------------------------------------------- TEST: sun/security/krb5/auto/BadKdc1.java build: 1.594 seconds compile: 1.594 seconds main: 89.433 seconds TEST RESULT: Passed. Execution successful -------------------------------------------------- TEST: sun/security/krb5/auto/BadKdc2.java build: 0.031 seconds compile: 0.031 seconds main: 133.423 seconds TEST RESULT: Passed. Execution successful -------------------------------------------------- TEST: sun/security/krb5/auto/BadKdc3.java build: 0.031 seconds compile: 0.031 seconds main: 73.681 seconds TEST RESULT: Passed. Execution successful -------------------------------------------------- TEST: sun/security/krb5/auto/BadKdc4.java build: 0.031 seconds compile: 0.031 seconds main: 169.443 seconds TEST RESULT: Passed. Execution successful -------------------------------------------------- TEST: sun/security/krb5/auto/MaxRetries.java compile: 0.062 seconds build: 0.0 seconds main: 170.49 seconds TEST RESULT: Passed. Execution successful -------------------------------------------------- TEST: sun/security/krb5/auto/TcpTimeout.java compile: 0.047 seconds build: 0.0 seconds main: 43.192 seconds TEST RESULT: Passed. Execution successful -------------------------------------------------- Thanks Max From valerie.peng at oracle.com Fri Mar 7 17:54:49 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 07 Mar 2014 09:54:49 -0800 Subject: Code review request: 8036543 Parfait JNI pending exceptions for j2secmod.c, j2secmod_md.c, and p11_md.c In-Reply-To: <53193F3E.9020707@oracle.com> References: <5316CAB4.7060704@oracle.com> <5317B8B0.7080009@oracle.com> <5317BB13.4070805@oracle.com> <5318F8AE.5090801@oracle.com> <531913A4.4020008@oracle.com> <53193F3E.9020707@oracle.com> Message-ID: <531A07E9.2050404@oracle.com> Yeah, I think Parfait is still under improvement on this. Just prefer that we fix whatever we can identify which may lead to pending exceptions and hopefully we can address all possible problems in one shot. Should save us much more time with only one round of investigation/impl/testing/review/integration. Changes look good. Thanks, Valerie On 03/06/14 19:38, Anthony Scarpino wrote: > Don't think parfait caught that one.. updated.... > http://cr.openjdk.java.net/~ascarpino/8036543/webrev.02/ > > On 03/06/2014 04:32 PM, Valerie (Yu-Ching) Peng wrote: >> >> How about line 223, there may be a pending exception thrown as well and >> this is inside a loop? >> Valerie >> >> On 03/06/14 14:37, Anthony Scarpino wrote: >>> webrev updated at: >>> http://cr.openjdk.java.net/~ascarpino/8036543/webrev.01/ >>> >>> On 03/05/2014 04:02 PM, Anthony Scarpino wrote: >>>> Sure.. I debated that piece of code before the review too. >>>> >>>> Tony >>>> >>>> On 03/05/2014 03:52 PM, Valerie (Yu-Ching) Peng wrote: >>>>> >>>>> >>>>> line 133 - 138, I think it's better to take the >>>>> ReleaseStringUTFChars() >>>>> call of 'configDir' out of the block for 'functionName'. >>>>> So we can ensure that both are released even if the code from >>>>> 82-94 are >>>>> somehow later altered. >>>>> >>>>> The rest looks fine. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 03/04/14 22:56, Anthony Scarpino wrote: >>>>>> Hi, >>>>>> >>>>>> I need a review for changes that cover JNI pending exceptions for >>>>>> j2secmod.c, j2secmod_md.c, and p11_md.c >>>>>> >>>>>> http://cr.openjdk.java.net/~ascarpino/8036543/webrev.00/ >>>>>> >>>>>> thanks >>>>>> >>>>>> Tony >>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Fri Mar 7 18:34:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Mar 2014 18:34:40 +0000 Subject: RFR 8035963: The failed Kerberos tests due to timeouts In-Reply-To: References: Message-ID: <531A1140.8060108@oracle.com> On 07/03/2014 07:31, Wang Weijun wrote: > Hi All > > Please take a review of > > http://cr.openjdk.java.net/~weijun/8035963/webrev.00/ > > I've added a ratio variable to these timeout related tests. The ratio is now set to 2 (one exception, 3 for BadKdc2). This is mainly an experiment to how if they can be more stable when running slower. We will need to do some observation for a period of time. > I don't know these tests but from what I can figure out then the changes look reasonable. Style wise then I guess I probably would have added a setter/getter for the ration rather than access it as a field but that is a minor point. One suggestion is to adding @build lines to each of the BadKdc{1,2,3} tests as otherwise BadKdc will be compiled implicitly (this comments isn't specific to the current patch because I see there is already a dependency). -Alan From valerie.peng at oracle.com Fri Mar 7 23:15:16 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 07 Mar 2014 15:15:16 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <53193B33.8060304@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> <52FD1A28.8050808@oracle.com> <5307D548.2080606@oracle.com> <531115DB.5080708@oracle.com> <5318CB89.2030808@oracle.com> <5318E197.7070400@oracle.com> <53190F08.3020709@oracle.com> <53193B33.8060304@oracle.com> Message-ID: <531A5304.7030109@oracle.com> line 280 still has "mgr.activeSessions", shouldn't it be "mgr.activeSessions.get()"? That's all. Thanks, Valerie On 03/06/14 19:21, Anthony Scarpino wrote: > On 03/06/2014 04:12 PM, Valerie (Yu-Ching) Peng wrote: >> >> Last time when I was debugging/observing the session pools, it's not >> just one or two sessions in the queue. It's at least hundreds possibly >> thousands when I ran one of the SSL stress tests. >> >> 1) line 273, do you really mean to return when the >> oldestSession.isLive() returns false?? > > Yeah, got that backwards > >> 2) line 275 is changed to "return". Wouldn't this mean that the debug >> statement on line 282-285 will rarely if ever be executed? > > replacing with a break should fix that > >> I think the main performance boost that we gained here is because we >> switched from a synchronize everything approach to a very >> fine-grained-synchronization one. The concern that I have is that is >> whether we need additional synchronization will be required as there are >> several calls involving the "pool" field in the Pool.release(Session) >> method which have no additional synchronization involved... This seems a >> bit too loose? > > I think it's fine, My checking if a session is old uses a peek, > leaving the entry in the queue. Then if it is old and I want to > return it, pool.remove() is thread safe, so it returns false if the > entry is gone and I can exit the loop because the queue has changed > significantly and the closing of the session is skipped. Only the > thread that removed the session from the queue can close it. > > It does get complicated because the original version kept at least one > session in the queue, i tried to keep that in this version. Ideally I > would have run through the queue closing all old session even if that > closed all op sessions; nevertheless, the above the peek keeps us from > running into a problem. > > I've run this on a stress test with 256 threads for 10 minutes using > AES and didn't have any exceptions or errors. > > I updated the webrev and with the change to use ConcurrentLinkedDeque > instead. > http://cr.openjdk.java.net/~ascarpino/7107611/webrev.03/ > >> >> Regards, >> Valerie >> >> On 03/06/14 12:59, Anthony Scarpino wrote: >>> On 03/06/2014 11:24 AM, Valerie (Yu-Ching) Peng wrote: >>>> Tony, >>>> >>>> I like this version better - a local "instance" session pool for >>>> P11Cipher is a bit excessive I think. >>>> >>>> One thing that I noticed with this change is that by switching to the >>>> ConcurrentLinkedQueue, you are retrieving sessions from the head >>>> and put >>>> them back at the end. This is different from the original approach of >>>> first-in-last-out. The subtlety in this is that it will take longer in >>>> order for sessions to pass their MAX_IDLE_TIME and be closed to shrink >>>> the pool size down. >>> >>> I didn't feel this was a big expense. Yes it does pull the oldest >>> session first, but my thinking was the queue was to handle surges in >>> usage. A possible extra session or two wasn't a big deal. If you >>> prefer me to go to the original method, I can change their patch to >>> use ConcurrentLinkedDeque, which does allow push and pop from both >>> ends of the queue >>> >>>> What is the synchronized(this) call for in the various debug code? >>>> I am still going through the rest of SessionManager.java file but >>>> should >>>> finish today. >>> >>> Yes, two of those seem useless, the last one does set >>> maxActiveSessions, so I should leave that in. >>> >>> >>>> Thanks, >>>> Valerie >>>> >>>> On 02/28/14 15:03, Anthony Scarpino wrote: >>>>> So I ran a stress test creating a number of keys and did not see much >>>>> different memory wise. But what I did notice that the performance >>>>> was >>>>> dependent on the number Cipher.init() calls. If each thread only has >>>>> one Cipher.init() call, it performed 5x better (170k vs 844k ops/m), >>>>> but as soon as you add any additional Cipher.init() calls the >>>>> performance dropped to equal without this change. >>>>> >>>>> When I changed the code to remove the local pool in P11Cipher, the >>>>> performance was lower, but still 4.5x faster (170k vs 768k ops/m). >>>>> >>>>> While there is some performance on the table from an performance >>>>> test/non-real world standpoint, it does keep session management in >>>>> SessionManager. I see value doing it this way given as it's an >>>>> update >>>>> to the modern concurrent class rather than old List with synchronized >>>>> methods. Valerie, would be more comfortable with the solution? >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.02/ >>>>> >>>>> Tony >>>>> >>>>> On 02/21/2014 02:38 PM, Valerie (Yu-Ching) Peng wrote: >>>>>> >>>>>> Where can I find the updated webrev? >>>>>> >>>>>> As for the performance test, I think we can probably try a >>>>>> "worse-case" >>>>>> (say 5000 Cipher objects which we don't re-use, just create, do >>>>>> operation, and then discard) and "best-case" (same # of objects, but >>>>>> re-use) against both impls and see how much a difference we'd >>>>>> observe. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 02/13/14 11:16, Anthony Scarpino wrote: >>>>>>> On 02/11/2014 02:18 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>>> >>>>>>>> Please see comments inline. >>>>>>>> >>>>>>>> On 02/10/14 16:30, Anthony Scarpino wrote: >>>>>>>>> On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote: >>>>>>>>>> >>>>>>>>>> Well, there are some changes that look strange which I need more >>>>>>>>>> time to >>>>>>>>>> figure out. >>>>>>>>>> For example, the purpose for the 2 new pkg private methods of >>>>>>>>>> poll(Pool) >>>>>>>>>> and release(Pool, Session) of the static class Pool. >>>>>>>>> >>>>>>>>> New methods are for supporting local pools. >>>>>>>> >>>>>>>> Yes, I can tell that they are for supporting the local pools, but >>>>>>>> are >>>>>>>> they really necessary and why do they belong in class Pool as >>>>>>>> instance >>>>>>>> methods? >>>>>>>> For example, the Pool.release(Pool, Session) method seems >>>>>>>> redundant, the >>>>>>>> caller can simply just call the release method on the cachePool >>>>>>>> argument >>>>>>>> as it has nothing to do with the Pool object that it invokes upon. >>>>>>>> Secondly, the poll method also seems strange as the cachePool is >>>>>>>> used >>>>>>>> first and the actual Pool object is only acting as backup. It's >>>>>>>> kind of >>>>>>>> ambiguous on what it is expected to do unless you looked at its >>>>>>>> implementation. >>>>>>> >>>>>>> I didn't notice that these methods aren't even called in >>>>>>> addition to >>>>>>> being pointless like you say. I'm removing them >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, now that every P11Cipher "object" has its own session >>>>>>>>>> pool, >>>>>>>>>> will >>>>>>>>>> this have any impact on the overall memory usage. >>>>>>>>> >>>>>>>>> I would think the memory usage would mostly transfer the session >>>>>>>>> from >>>>>>>>> SessionManager to P11Cipher. >>>>>>>> >>>>>>>> The session object itself may be transferred and does not matter, >>>>>>>> but >>>>>>>> the supporting structure, e.g. esp. the queue, is now present in >>>>>>>> every >>>>>>>> P11Cipher object. How much impact this has will depend on how >>>>>>>> List/ConcurrentLinkedQueue is implemented as well as the P11Cipher >>>>>>>> usages in the calling application. It's essential to verify that >>>>>>>> this >>>>>>>> change has NO significant impact on other apps such as some JSSE >>>>>>>> apps. >>>>>>> >>>>>>> Is there a perf test you'd recommend to try this? >>>>>>> >>>>>>>> Valerie >>>>>>>>> It is true that if many P11Cipher objects are created, that >>>>>>>>> could be >>>>>>>>> more idle op session around if P11Cipher objects lingers. But >>>>>>>>> the >>>>>>>>> object session stay in SessionManager, which is probably the >>>>>>>>> bulk of >>>>>>>>> the memory usage. >>>>>>>>> >>>>>>>>>> If P11Cipher object is not re-used much and only have a short >>>>>>>>>> life >>>>>>>>>> span, >>>>>>>>>> what's the point of having a local session pool to re-use the >>>>>>>>>> sessions. >>>>>>>>> >>>>>>>>> If the P11Cipher object is created sparingly and short lived, >>>>>>>>> creating >>>>>>>>> one session for usage and then getting gc'ed, I would suspect >>>>>>>>> crypto >>>>>>>>> performance isn't a top issue. But I could see that only >>>>>>>>> happening in >>>>>>>>> large crypto deployments using that methodology; however, I'm not >>>>>>>>> sure >>>>>>>>> that is wise development methodology to start with. You'd better >>>>>>>>> insight if such designs are common. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Tony >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/03/14 10:24, Anthony Scarpino wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'm requesting a review of these changes. It is mostly from >>>>>>>>>>> the >>>>>>>>>>> patch >>>>>>>>>>> that Intel provided, but I have made some cosmetic changes. >>>>>>>>>>> The >>>>>>>>>>> changes significantly improve performance in multithreaded >>>>>>>>>>> application >>>>>>>>>>> using pkcs11. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ascarpino/7107611/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> >>>>>>>>>>> Tony >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From jdk-security-dev at whittington.net.nz Sun Mar 9 09:50:27 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Sun, 9 Mar 2014 22:50:27 +1300 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> Message-ID: <3880118C-8813-4A19-85EE-6E9EAB156A97@whittington.net.nz> On 7/03/2014, at 9:14 am, Philipp Heckel wrote: > - Using javax.crypto.CipherInputStream with a cipher in GCM mode and the SunJCE provider (JDK8+) is secure, but cannot be used large files, because it will buffer all data until the tag is verified (as defined by the GCM spec) [1] This (the part about it being secure) is not correct - when using javax.crypto.CipherInputStream with a cipher in GCM mode and the SunJCE provider (JDK8+) any tampering with the ciphertext will silently treat the result as a 0 byte authenticated stream. cheers tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdk-security-dev at whittington.net.nz Sun Mar 9 18:31:23 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Mon, 10 Mar 2014 07:31:23 +1300 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <3880118C-8813-4A19-85EE-6E9EAB156A97@whittington.net.nz> References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> <3880118C-8813-4A19-85EE-6E9EAB156A97@whittington.net.nz> Message-ID: <03F3B840-1D5E-4D50-87CC-99DFCE1A6E12@whittington.net.nz> On 9/03/2014, at 10:50 pm, Tim Whittington wrote: > > On 7/03/2014, at 9:14 am, Philipp Heckel wrote: > >> - Using javax.crypto.CipherInputStream with a cipher in GCM mode and the SunJCE provider (JDK8+) is secure, but cannot be used large files, because it will buffer all data until the tag is verified (as defined by the GCM spec) [1] > > This (the part about it being secure) is not correct - when using javax.crypto.CipherInputStream with a cipher in GCM mode and the SunJCE provider (JDK8+) any tampering with the ciphertext will silently treat the result as a 0 byte authenticated stream. > Sorry, I should have been clearer here - this problem occurs with any provider (and any AE mode) not just the SunJCE GCM implementation. tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Mar 10 00:12:48 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 10 Mar 2014 08:12:48 +0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <03F3B840-1D5E-4D50-87CC-99DFCE1A6E12@whittington.net.nz> References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> <3880118C-8813-4A19-85EE-6E9EAB156A97@whittington.net.nz> <03F3B840-1D5E-4D50-87CC-99DFCE1A6E12@whittington.net.nz> Message-ID: <531D0380.8040808@oracle.com> On 3/10/2014 2:31 AM, Tim Whittington wrote: > > On 9/03/2014, at 10:50 pm, Tim Whittington > > wrote: > >> >> On 7/03/2014, at 9:14 am, Philipp Heckel > > wrote: >> >>> - Using javax.crypto.CipherInputStream with a cipher in GCM mode and >>> the SunJCE provider (JDK8+) is secure, but cannot be used large >>> files, because it will buffer all data until the tag is verified (as >>> defined by the GCM spec) [1] >> >> This (the part about it being secure) is not correct - when using >> javax.crypto.CipherInputStream with a cipher in GCM mode and the >> SunJCE provider (JDK8+) any tampering with the ciphertext will >> silently treat the result as a 0 byte authenticated stream. >> > > Sorry, I should have been clearer here - this problem occurs with any > provider (and any AE mode) not just the SunJCE GCM implementation. > It only happens before the authentication tag get checked. If the authN tag get read, the tampering can be detected. Your concerns happen to any mode, even CBC mode. Better to make an improvement here if possible. Thanks, Xuelei From weijun.wang at oracle.com Mon Mar 10 07:35:50 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 10 Mar 2014 15:35:50 +0800 Subject: RFR 8036971: krb5.conf does not accept directive lines before the first section Message-ID: <690C8FB2-3D51-41FE-8778-DDBCD7E04FA5@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8036971/webrev.00/ bug is https://bugs.openjdk.java.net/browse/JDK-8036971 Before the enhancement JDK-8029994 is available, a bug fix is needed. Thanks Max From jdk-security-dev at whittington.net.nz Mon Mar 10 07:37:08 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Mon, 10 Mar 2014 20:37:08 +1300 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: <531D0380.8040808@oracle.com> References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> <3880118C-8813-4A19-85EE-6E9EAB156A97@whittington.net.nz> <03F3B840-1D5E-4D50-87CC-99DFCE1A6E12@whittington.net.nz> <531D0380.8040808@oracle.com> Message-ID: On 10/03/2014, at 1:12 pm, Xuelei Fan wrote: > On 3/10/2014 2:31 AM, Tim Whittington wrote: >> >> On 9/03/2014, at 10:50 pm, Tim Whittington >> > > wrote: >> >>> >>> On 7/03/2014, at 9:14 am, Philipp Heckel >> > wrote: >>> >>>> - Using javax.crypto.CipherInputStream with a cipher in GCM mode and >>>> the SunJCE provider (JDK8+) is secure, but cannot be used large >>>> files, because it will buffer all data until the tag is verified (as >>>> defined by the GCM spec) [1] >>> >>> This (the part about it being secure) is not correct - when using >>> javax.crypto.CipherInputStream with a cipher in GCM mode and the >>> SunJCE provider (JDK8+) any tampering with the ciphertext will >>> silently treat the result as a 0 byte authenticated stream. >>> >> >> Sorry, I should have been clearer here - this problem occurs with any >> provider (and any AE mode) not just the SunJCE GCM implementation. >> > It only happens before the authentication tag get checked. If the authN > tag get read, the tampering can be detected. > > Your concerns happen to any mode, even CBC mode. Better to make an > improvement here if possible. I don?t quite understand what you?re saying here - what I?m saying is that the auth tag is read, the tampering is detected, and then CipherInputStream suppresses the AEADBadTagException, resulting in the reader of the stream interpreting it as a valid (but empty) ciphertext. i.e. the code snippet below should print: Via CipherInputStream: ciphertext is invalid Via Cipher: ciphertext is invalid but instead it prints: Via CipherInputStream: ciphertext is valid and -1 bytes long Via Cipher: ciphertext is invalid If you repeat the test with a 0 byte plaintext, and without tampering with the ciphertext, it will print: Via CipherInputStream: ciphertext is valid and -1 bytes long Via Cipher: ciphertext is valid and 0 bytes long Notice that when using CipherInputStream, a tampered ciphertext and a 0 byte valid ciphertext produce the same result, while Cipher behaves correctly by failing the auth on the tampered one. This behaviour is what I was saying is insecure - that javax.crypto.CipherInputStream does similar questionable things for bad padding in CBC mode makes no difference. From the JavaDoc of InputStream.read(byte[]): IOException is thrown "If the first byte cannot be read for any reason other than the end of the file?. (The first byte in this case is the first byte in the stream that would be placed at b[0]). In my opinion, an AEADBadTagException thrown by a Cipher that prevents it from returning any bytes is such a reason, and as such should cause an IOException to be thrown. tim ?? Cipher c = Cipher.getInstance("AES/GCM/NoPadding", "SunJCE"); c.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(new byte[16], "AES"), new GCMParameterSpec(128, new byte[16])); byte[] ct = c.doFinal(new byte[100]); c.init(Cipher.DECRYPT_MODE, new SecretKeySpec(new byte[16], "AES"), new GCMParameterSpec(128, new byte[16])); ct[ct.length - 1] = (byte)(ct[ct.length - 1] + 1); byte[] read = new byte[1000]; InputStream in = new javax.crypto.CipherInputStream(new ByteArrayInputStream(ct), c); try { int size = in.read(read); System.out.println("Via CipherInputStream: ciphertext is valid and " + size + " bytes long"); } catch (IOException e) { System.errr.println("Via CipherInputStream: ciphertext is invalid"); } finally { in.close(); } try { byte[] pt = c.doFinal(ct); System.out.println("Via Cipher: ciphertext is valid and " + pt.length + " bytes long"); } catch (AEADBadTagException e) { System.err.println("Via CipherInputStream: ciphertext is invalid"); } From xuelei.fan at oracle.com Mon Mar 10 08:29:25 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 10 Mar 2014 16:29:25 +0800 Subject: RFR 8036971: krb5.conf does not accept directive lines before the first section In-Reply-To: <690C8FB2-3D51-41FE-8778-DDBCD7E04FA5@oracle.com> References: <690C8FB2-3D51-41FE-8778-DDBCD7E04FA5@oracle.com> Message-ID: <531D77E5.9070205@oracle.com> Looks fine to me. Xuelei On 3/10/2014 3:35 PM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8036971/webrev.00/ > > bug is > > https://bugs.openjdk.java.net/browse/JDK-8036971 > > Before the enhancement JDK-8029994 is available, a bug fix is needed. > > Thanks > Max > From xuelei.fan at oracle.com Mon Mar 10 08:53:04 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 10 Mar 2014 16:53:04 +0800 Subject: CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible In-Reply-To: References: <5315151D.6070504@oracle.com> <53159A32.8070104@redhat.com> <53170DD0.4030402@oracle.com> <3880118C-8813-4A19-85EE-6E9EAB156A97@whittington.net.nz> <03F3B840-1D5E-4D50-87CC-99DFCE1A6E12@whittington.net.nz> <531D0380.8040808@oracle.com> Message-ID: <531D7D70.8070803@oracle.com> Hi Tim, Sorry, I should have been cleaner on this point. What I wanted to express is that I understood your concerns. Thanks for the detailed description and examples. Thanks, Xuelei On 3/10/2014 3:37 PM, Tim Whittington wrote: > > On 10/03/2014, at 1:12 pm, Xuelei Fan wrote: > >> On 3/10/2014 2:31 AM, Tim Whittington wrote: >>> >>> On 9/03/2014, at 10:50 pm, Tim Whittington >>> >> > wrote: >>> >>>> >>>> On 7/03/2014, at 9:14 am, Philipp Heckel >>> > wrote: >>>> >>>>> - Using javax.crypto.CipherInputStream with a cipher in GCM mode and >>>>> the SunJCE provider (JDK8+) is secure, but cannot be used large >>>>> files, because it will buffer all data until the tag is verified (as >>>>> defined by the GCM spec) [1] >>>> >>>> This (the part about it being secure) is not correct - when using >>>> javax.crypto.CipherInputStream with a cipher in GCM mode and the >>>> SunJCE provider (JDK8+) any tampering with the ciphertext will >>>> silently treat the result as a 0 byte authenticated stream. >>>> >>> >>> Sorry, I should have been clearer here - this problem occurs with any >>> provider (and any AE mode) not just the SunJCE GCM implementation. >>> >> It only happens before the authentication tag get checked. If the authN >> tag get read, the tampering can be detected. >> >> Your concerns happen to any mode, even CBC mode. Better to make an >> improvement here if possible. > > I don?t quite understand what you?re saying here - what I?m saying is that the auth tag is read, the tampering is detected, and then CipherInputStream suppresses the AEADBadTagException, resulting in the reader of the stream interpreting it as a valid (but empty) ciphertext. > > i.e. the code snippet below should print: > > Via CipherInputStream: ciphertext is invalid > Via Cipher: ciphertext is invalid > > but instead it prints: > > Via CipherInputStream: ciphertext is valid and -1 bytes long > Via Cipher: ciphertext is invalid > > If you repeat the test with a 0 byte plaintext, and without tampering with the ciphertext, it will print: > > Via CipherInputStream: ciphertext is valid and -1 bytes long > Via Cipher: ciphertext is valid and 0 bytes long > > Notice that when using CipherInputStream, a tampered ciphertext and a 0 byte valid ciphertext produce the same result, while Cipher behaves correctly by failing the auth on the tampered one. > This behaviour is what I was saying is insecure - that javax.crypto.CipherInputStream does similar questionable things for bad padding in CBC mode makes no difference. > > From the JavaDoc of InputStream.read(byte[]): IOException is thrown "If the first byte cannot be read for any reason other than the end of the file?. > (The first byte in this case is the first byte in the stream that would be placed at b[0]). > In my opinion, an AEADBadTagException thrown by a Cipher that prevents it from returning any bytes is such a reason, and as such should cause an IOException to be thrown. > > tim > > > ?? > > Cipher c = Cipher.getInstance("AES/GCM/NoPadding", "SunJCE"); > c.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(new byte[16], "AES"), new GCMParameterSpec(128, new byte[16])); > byte[] ct = c.doFinal(new byte[100]); > > c.init(Cipher.DECRYPT_MODE, new SecretKeySpec(new byte[16], "AES"), new GCMParameterSpec(128, new byte[16])); > ct[ct.length - 1] = (byte)(ct[ct.length - 1] + 1); > > byte[] read = new byte[1000]; > InputStream in = new javax.crypto.CipherInputStream(new ByteArrayInputStream(ct), c); > try > { > int size = in.read(read); > System.out.println("Via CipherInputStream: ciphertext is valid and " + size + " bytes long"); > } > catch (IOException e) > { > System.errr.println("Via CipherInputStream: ciphertext is invalid"); > } > finally > { > in.close(); > } > > try > { > byte[] pt = c.doFinal(ct); > System.out.println("Via Cipher: ciphertext is valid and " + pt.length + " bytes long"); > } > catch (AEADBadTagException e) > { > System.err.println("Via CipherInputStream: ciphertext is invalid"); > } > > From sean.mullan at oracle.com Mon Mar 10 19:00:41 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Mar 2014 15:00:41 -0400 Subject: [9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert In-Reply-To: <5310E965.1080803@oracle.com> References: <5310E965.1080803@oracle.com> Message-ID: <531E0BD9.1080300@oracle.com> Hi Jason, Sorry for the delay in reviewing this. On 02/28/2014 02:54 PM, Jason Uh wrote: > Hi Sean, > > Could I please get a review of this change? This fix allows a certpath > to be validated when a certificate issued by a version 1 trusted cert > has a validity period that doesn't fall within the validity of the > issuer. Trust anchors whose validity do contain the issued cert's > validity period will be prioritized above those that do not. > > webrev: http://cr.openjdk.java.net/~juh/8021804/webrev.00/ > bug: http://bugs.openjdk.java.net/browse/JDK-8021804 In PKIXCertPathValidator, I would remove the call to X509CertSelector.setValidityPeriod on line 98 and just match on the subject and SKID when trying to find a matching trust anchor. Most of the other changes are not necessary I think. At this point you are just trying to find a matching root. In most cases there will only be one possible choice, so unless there are 2 V1 roots with the same subject name and a different public key (ex: due to key rollover). Maybe trying to match on the validity period would help select the right root in the key rollover case, but I'm not sure the extra code is worth it for this rare case (and V1 roots are becoming much less common). And even if it does select the wrong root the first time, the code should fail quickly (when the signature on the cert issued by the root fails), and then proceed to try the next one (and then succeed). --Sean From jason.uh at oracle.com Tue Mar 11 00:00:24 2014 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 10 Mar 2014 17:00:24 -0700 Subject: [9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert In-Reply-To: <531E0BD9.1080300@oracle.com> References: <5310E965.1080803@oracle.com> <531E0BD9.1080300@oracle.com> Message-ID: <531E5218.2080806@oracle.com> Thanks, Sean. I've simplified my changes to only removing the call to setValidityPeriod. http://cr.openjdk.java.net/~juh/8021804/webrev.01 Jason On 3/10/14 12:00 PM, Sean Mullan wrote: > Hi Jason, > > Sorry for the delay in reviewing this. > > On 02/28/2014 02:54 PM, Jason Uh wrote: >> Hi Sean, >> >> Could I please get a review of this change? This fix allows a certpath >> to be validated when a certificate issued by a version 1 trusted cert >> has a validity period that doesn't fall within the validity of the >> issuer. Trust anchors whose validity do contain the issued cert's >> validity period will be prioritized above those that do not. >> >> webrev: http://cr.openjdk.java.net/~juh/8021804/webrev.00/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8021804 > > In PKIXCertPathValidator, I would remove the call to > X509CertSelector.setValidityPeriod on line 98 and just match on the > subject and SKID when trying to find a matching trust anchor. Most of > the other changes are not necessary I think. At this point you are just > trying to find a matching root. In most cases there will only be one > possible choice, so unless there are 2 V1 roots with the same subject > name and a different public key (ex: due to key rollover). Maybe trying > to match on the validity period would help select the right root in the > key rollover case, but I'm not sure the extra code is worth it for this > rare case (and V1 roots are becoming much less common). And even if it > does select the wrong root the first time, the code should fail quickly > (when the signature on the cert issued by the root fails), and then > proceed to try the next one (and then succeed). > > --Sean > > > > > From weijun.wang at oracle.com Tue Mar 11 09:54:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 11 Mar 2014 17:54:34 +0800 Subject: RFR 8035963: The failed Kerberos tests due to timeouts In-Reply-To: References: Message-ID: <9766CC2E-E724-4DFC-8D1D-04963B36BEA1@oracle.com> Ping again. --Max On Mar 7, 2014, at 15:31, Wang Weijun wrote: > Hi All > > Please take a review of > > http://cr.openjdk.java.net/~weijun/8035963/webrev.00/ > > I've added a ratio variable to these timeout related tests. The ratio is now set to 2 (one exception, 3 for BadKdc2). This is mainly an experiment to how if they can be more stable when running slower. We will need to do some observation for a period of time. > > BTW, some of them are placed into ProblemList.txt for solaris-sparc. I remember there was a time when solaris-sparc machines run slow because of a hotspot change. Anyway, they are all liberated at the moment to join the experiment. > > FYI: The tests run fine on my desktop (Mac Mini) with a ratio of 0.4. > > JPRT runs fine. The windows-i586 job runs the slowest: > > -------------------------------------------------- > TEST: sun/security/krb5/auto/BadKdc1.java > build: 1.594 seconds > compile: 1.594 seconds > main: 89.433 seconds > TEST RESULT: Passed. Execution successful > -------------------------------------------------- > TEST: sun/security/krb5/auto/BadKdc2.java > build: 0.031 seconds > compile: 0.031 seconds > main: 133.423 seconds > TEST RESULT: Passed. Execution successful > -------------------------------------------------- > TEST: sun/security/krb5/auto/BadKdc3.java > build: 0.031 seconds > compile: 0.031 seconds > main: 73.681 seconds > TEST RESULT: Passed. Execution successful > -------------------------------------------------- > TEST: sun/security/krb5/auto/BadKdc4.java > build: 0.031 seconds > compile: 0.031 seconds > main: 169.443 seconds > TEST RESULT: Passed. Execution successful > -------------------------------------------------- > TEST: sun/security/krb5/auto/MaxRetries.java > compile: 0.062 seconds > build: 0.0 seconds > main: 170.49 seconds > TEST RESULT: Passed. Execution successful > -------------------------------------------------- > TEST: sun/security/krb5/auto/TcpTimeout.java > compile: 0.047 seconds > build: 0.0 seconds > main: 43.192 seconds > TEST RESULT: Passed. Execution successful > -------------------------------------------------- > > Thanks > Max > From xuelei.fan at oracle.com Tue Mar 11 11:32:40 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Mar 2014 19:32:40 +0800 Subject: RFR 8035963: The failed Kerberos tests due to timeouts In-Reply-To: <9766CC2E-E724-4DFC-8D1D-04963B36BEA1@oracle.com> References: <9766CC2E-E724-4DFC-8D1D-04963B36BEA1@oracle.com> Message-ID: <531EF458.6070705@oracle.com> Do you want to consider Alan's suggestion? Xuelei On 3/11/2014 5:54 PM, Wang Weijun wrote: > Ping again. > > --Max > > On Mar 7, 2014, at 15:31, Wang Weijun wrote: > >> Hi All >> >> Please take a review of >> >> http://cr.openjdk.java.net/~weijun/8035963/webrev.00/ >> >> I've added a ratio variable to these timeout related tests. The ratio is now set to 2 (one exception, 3 for BadKdc2). This is mainly an experiment to how if they can be more stable when running slower. We will need to do some observation for a period of time. >> >> BTW, some of them are placed into ProblemList.txt for solaris-sparc. I remember there was a time when solaris-sparc machines run slow because of a hotspot change. Anyway, they are all liberated at the moment to join the experiment. >> >> FYI: The tests run fine on my desktop (Mac Mini) with a ratio of 0.4. >> >> JPRT runs fine. The windows-i586 job runs the slowest: >> >> -------------------------------------------------- >> TEST: sun/security/krb5/auto/BadKdc1.java >> build: 1.594 seconds >> compile: 1.594 seconds >> main: 89.433 seconds >> TEST RESULT: Passed. Execution successful >> -------------------------------------------------- >> TEST: sun/security/krb5/auto/BadKdc2.java >> build: 0.031 seconds >> compile: 0.031 seconds >> main: 133.423 seconds >> TEST RESULT: Passed. Execution successful >> -------------------------------------------------- >> TEST: sun/security/krb5/auto/BadKdc3.java >> build: 0.031 seconds >> compile: 0.031 seconds >> main: 73.681 seconds >> TEST RESULT: Passed. Execution successful >> -------------------------------------------------- >> TEST: sun/security/krb5/auto/BadKdc4.java >> build: 0.031 seconds >> compile: 0.031 seconds >> main: 169.443 seconds >> TEST RESULT: Passed. Execution successful >> -------------------------------------------------- >> TEST: sun/security/krb5/auto/MaxRetries.java >> compile: 0.062 seconds >> build: 0.0 seconds >> main: 170.49 seconds >> TEST RESULT: Passed. Execution successful >> -------------------------------------------------- >> TEST: sun/security/krb5/auto/TcpTimeout.java >> compile: 0.047 seconds >> build: 0.0 seconds >> main: 43.192 seconds >> TEST RESULT: Passed. Execution successful >> -------------------------------------------------- >> >> Thanks >> Max >> > From weijun.wang at oracle.com Tue Mar 11 12:27:09 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 11 Mar 2014 20:27:09 +0800 Subject: RFR 8035963: The failed Kerberos tests due to timeouts In-Reply-To: <531EF458.6070705@oracle.com> References: <9766CC2E-E724-4DFC-8D1D-04963B36BEA1@oracle.com> <531EF458.6070705@oracle.com> Message-ID: <8421BD4E-FDE5-41D5-AC49-5E206F05B2B5@oracle.com> I'll add the setter/getter. As for @compile, every test inside krb5/auto depends on other files (Context, Action, KDC,...), I don't think it's necessary to list them everywhere. Thanks Max > On Mar 11, 2014, at 19:32, Xuelei Fan wrote: > > Do you want to consider Alan's suggestion? > > Xuelei > >> On 3/11/2014 5:54 PM, Wang Weijun wrote: >> Ping again. >> >> --Max >> >>> On Mar 7, 2014, at 15:31, Wang Weijun wrote: >>> >>> Hi All >>> >>> Please take a review of >>> >>> http://cr.openjdk.java.net/~weijun/8035963/webrev.00/ >>> >>> I've added a ratio variable to these timeout related tests. The ratio is now set to 2 (one exception, 3 for BadKdc2). This is mainly an experiment to how if they can be more stable when running slower. We will need to do some observation for a period of time. >>> >>> BTW, some of them are placed into ProblemList.txt for solaris-sparc. I remember there was a time when solaris-sparc machines run slow because of a hotspot change. Anyway, they are all liberated at the moment to join the experiment. >>> >>> FYI: The tests run fine on my desktop (Mac Mini) with a ratio of 0.4. >>> >>> JPRT runs fine. The windows-i586 job runs the slowest: >>> >>> -------------------------------------------------- >>> TEST: sun/security/krb5/auto/BadKdc1.java >>> build: 1.594 seconds >>> compile: 1.594 seconds >>> main: 89.433 seconds >>> TEST RESULT: Passed. Execution successful >>> -------------------------------------------------- >>> TEST: sun/security/krb5/auto/BadKdc2.java >>> build: 0.031 seconds >>> compile: 0.031 seconds >>> main: 133.423 seconds >>> TEST RESULT: Passed. Execution successful >>> -------------------------------------------------- >>> TEST: sun/security/krb5/auto/BadKdc3.java >>> build: 0.031 seconds >>> compile: 0.031 seconds >>> main: 73.681 seconds >>> TEST RESULT: Passed. Execution successful >>> -------------------------------------------------- >>> TEST: sun/security/krb5/auto/BadKdc4.java >>> build: 0.031 seconds >>> compile: 0.031 seconds >>> main: 169.443 seconds >>> TEST RESULT: Passed. Execution successful >>> -------------------------------------------------- >>> TEST: sun/security/krb5/auto/MaxRetries.java >>> compile: 0.062 seconds >>> build: 0.0 seconds >>> main: 170.49 seconds >>> TEST RESULT: Passed. Execution successful >>> -------------------------------------------------- >>> TEST: sun/security/krb5/auto/TcpTimeout.java >>> compile: 0.047 seconds >>> build: 0.0 seconds >>> main: 43.192 seconds >>> TEST RESULT: Passed. Execution successful >>> -------------------------------------------------- >>> >>> Thanks >>> Max > From xuelei.fan at oracle.com Tue Mar 11 12:42:11 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Mar 2014 20:42:11 +0800 Subject: RFR 8035963: The failed Kerberos tests due to timeouts In-Reply-To: <8421BD4E-FDE5-41D5-AC49-5E206F05B2B5@oracle.com> References: <9766CC2E-E724-4DFC-8D1D-04963B36BEA1@oracle.com> <531EF458.6070705@oracle.com> <8421BD4E-FDE5-41D5-AC49-5E206F05B2B5@oracle.com> Message-ID: <531F04A3.4030109@oracle.com> OK. Fine to me. Xuelei On 3/11/2014 8:27 PM, Wang Weijun wrote: > I'll add the setter/getter. As for @compile, every test inside krb5/auto depends on other files (Context, Action, KDC,...), I don't think it's necessary to list them everywhere. > > Thanks > Max > >> On Mar 11, 2014, at 19:32, Xuelei Fan wrote: >> >> Do you want to consider Alan's suggestion? >> >> Xuelei >> >>> On 3/11/2014 5:54 PM, Wang Weijun wrote: >>> Ping again. >>> >>> --Max >>> >>>> On Mar 7, 2014, at 15:31, Wang Weijun wrote: >>>> >>>> Hi All >>>> >>>> Please take a review of >>>> >>>> http://cr.openjdk.java.net/~weijun/8035963/webrev.00/ >>>> >>>> I've added a ratio variable to these timeout related tests. The ratio is now set to 2 (one exception, 3 for BadKdc2). This is mainly an experiment to how if they can be more stable when running slower. We will need to do some observation for a period of time. >>>> >>>> BTW, some of them are placed into ProblemList.txt for solaris-sparc. I remember there was a time when solaris-sparc machines run slow because of a hotspot change. Anyway, they are all liberated at the moment to join the experiment. >>>> >>>> FYI: The tests run fine on my desktop (Mac Mini) with a ratio of 0.4. >>>> >>>> JPRT runs fine. The windows-i586 job runs the slowest: >>>> >>>> -------------------------------------------------- >>>> TEST: sun/security/krb5/auto/BadKdc1.java >>>> build: 1.594 seconds >>>> compile: 1.594 seconds >>>> main: 89.433 seconds >>>> TEST RESULT: Passed. Execution successful >>>> -------------------------------------------------- >>>> TEST: sun/security/krb5/auto/BadKdc2.java >>>> build: 0.031 seconds >>>> compile: 0.031 seconds >>>> main: 133.423 seconds >>>> TEST RESULT: Passed. Execution successful >>>> -------------------------------------------------- >>>> TEST: sun/security/krb5/auto/BadKdc3.java >>>> build: 0.031 seconds >>>> compile: 0.031 seconds >>>> main: 73.681 seconds >>>> TEST RESULT: Passed. Execution successful >>>> -------------------------------------------------- >>>> TEST: sun/security/krb5/auto/BadKdc4.java >>>> build: 0.031 seconds >>>> compile: 0.031 seconds >>>> main: 169.443 seconds >>>> TEST RESULT: Passed. Execution successful >>>> -------------------------------------------------- >>>> TEST: sun/security/krb5/auto/MaxRetries.java >>>> compile: 0.062 seconds >>>> build: 0.0 seconds >>>> main: 170.49 seconds >>>> TEST RESULT: Passed. Execution successful >>>> -------------------------------------------------- >>>> TEST: sun/security/krb5/auto/TcpTimeout.java >>>> compile: 0.047 seconds >>>> build: 0.0 seconds >>>> main: 43.192 seconds >>>> TEST RESULT: Passed. Execution successful >>>> -------------------------------------------------- >>>> >>>> Thanks >>>> Max >> From sean.mullan at oracle.com Tue Mar 11 21:59:24 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Mar 2014 17:59:24 -0400 Subject: [9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert In-Reply-To: <531E5218.2080806@oracle.com> References: <5310E965.1080803@oracle.com> <531E0BD9.1080300@oracle.com> <531E5218.2080806@oracle.com> Message-ID: <531F873C.2000003@oracle.com> In the test, you should probably call PKIXParameters.setValidity with a fixed date so that the test won't start failing in 2024. Yes, I know that's a long time away! Check out other tests to see examples. Otherwise, fix looks good and you can push without a re-review. --Sean On 03/10/2014 08:00 PM, Jason Uh wrote: > Thanks, Sean. I've simplified my changes to only removing the call to > setValidityPeriod. > > http://cr.openjdk.java.net/~juh/8021804/webrev.01 > > Jason > > On 3/10/14 12:00 PM, Sean Mullan wrote: >> Hi Jason, >> >> Sorry for the delay in reviewing this. >> >> On 02/28/2014 02:54 PM, Jason Uh wrote: >>> Hi Sean, >>> >>> Could I please get a review of this change? This fix allows a certpath >>> to be validated when a certificate issued by a version 1 trusted cert >>> has a validity period that doesn't fall within the validity of the >>> issuer. Trust anchors whose validity do contain the issued cert's >>> validity period will be prioritized above those that do not. >>> >>> webrev: http://cr.openjdk.java.net/~juh/8021804/webrev.00/ >>> bug: http://bugs.openjdk.java.net/browse/JDK-8021804 >> >> In PKIXCertPathValidator, I would remove the call to >> X509CertSelector.setValidityPeriod on line 98 and just match on the >> subject and SKID when trying to find a matching trust anchor. Most of >> the other changes are not necessary I think. At this point you are just >> trying to find a matching root. In most cases there will only be one >> possible choice, so unless there are 2 V1 roots with the same subject >> name and a different public key (ex: due to key rollover). Maybe trying >> to match on the validity period would help select the right root in the >> key rollover case, but I'm not sure the extra code is worth it for this >> rare case (and V1 roots are becoming much less common). And even if it >> does select the wrong root the first time, the code should fail quickly >> (when the signature on the cert issued by the root fails), and then >> proceed to try the next one (and then succeed). >> >> --Sean >> >> >> >> >> > From jason.uh at oracle.com Tue Mar 11 22:30:49 2014 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 11 Mar 2014 15:30:49 -0700 Subject: [9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert In-Reply-To: <531F873C.2000003@oracle.com> References: <5310E965.1080803@oracle.com> <531E0BD9.1080300@oracle.com> <531E5218.2080806@oracle.com> <531F873C.2000003@oracle.com> Message-ID: <531F8E99.2030301@oracle.com> Thanks, Sean. I'll push with a set date. On 3/11/14 2:59 PM, Sean Mullan wrote: > In the test, you should probably call PKIXParameters.setValidity with a > fixed date so that the test won't start failing in 2024. Yes, I know > that's a long time away! Check out other tests to see examples. > > Otherwise, fix looks good and you can push without a re-review. > > --Sean > > On 03/10/2014 08:00 PM, Jason Uh wrote: >> Thanks, Sean. I've simplified my changes to only removing the call to >> setValidityPeriod. >> >> http://cr.openjdk.java.net/~juh/8021804/webrev.01 >> >> Jason >> >> On 3/10/14 12:00 PM, Sean Mullan wrote: >>> Hi Jason, >>> >>> Sorry for the delay in reviewing this. >>> >>> On 02/28/2014 02:54 PM, Jason Uh wrote: >>>> Hi Sean, >>>> >>>> Could I please get a review of this change? This fix allows a certpath >>>> to be validated when a certificate issued by a version 1 trusted cert >>>> has a validity period that doesn't fall within the validity of the >>>> issuer. Trust anchors whose validity do contain the issued cert's >>>> validity period will be prioritized above those that do not. >>>> >>>> webrev: http://cr.openjdk.java.net/~juh/8021804/webrev.00/ >>>> bug: http://bugs.openjdk.java.net/browse/JDK-8021804 >>> >>> In PKIXCertPathValidator, I would remove the call to >>> X509CertSelector.setValidityPeriod on line 98 and just match on the >>> subject and SKID when trying to find a matching trust anchor. Most of >>> the other changes are not necessary I think. At this point you are just >>> trying to find a matching root. In most cases there will only be one >>> possible choice, so unless there are 2 V1 roots with the same subject >>> name and a different public key (ex: due to key rollover). Maybe trying >>> to match on the validity period would help select the right root in the >>> key rollover case, but I'm not sure the extra code is worth it for this >>> rare case (and V1 roots are becoming much less common). And even if it >>> does select the wrong root the first time, the code should fail quickly >>> (when the signature on the cert issued by the root fails), and then >>> proceed to try the next one (and then succeed). >>> >>> --Sean >>> >>> >>> >>> >>> >> > From jason.uh at oracle.com Wed Mar 12 00:26:07 2014 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 11 Mar 2014 17:26:07 -0700 Subject: [9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert In-Reply-To: <531F873C.2000003@oracle.com> References: <5310E965.1080803@oracle.com> <531E0BD9.1080300@oracle.com> <531E5218.2080806@oracle.com> <531F873C.2000003@oracle.com> Message-ID: <531FA99F.2020303@oracle.com> Hi Sean, After taking another look at the test, I wanted to make one minor simplification. I've removed the CRL from the test and disabled revocation because they weren't adding anything important to the test (which still passes). I'll push if you're okay with that. If you want to take a look: http://cr.openjdk.java.net/~juh/8021804/webrev.02 Jason On 3/11/14 2:59 PM, Sean Mullan wrote: > In the test, you should probably call PKIXParameters.setValidity with a > fixed date so that the test won't start failing in 2024. Yes, I know > that's a long time away! Check out other tests to see examples. > > Otherwise, fix looks good and you can push without a re-review. > > --Sean > > On 03/10/2014 08:00 PM, Jason Uh wrote: >> Thanks, Sean. I've simplified my changes to only removing the call to >> setValidityPeriod. >> >> http://cr.openjdk.java.net/~juh/8021804/webrev.01 >> >> Jason >> >> On 3/10/14 12:00 PM, Sean Mullan wrote: >>> Hi Jason, >>> >>> Sorry for the delay in reviewing this. >>> >>> On 02/28/2014 02:54 PM, Jason Uh wrote: >>>> Hi Sean, >>>> >>>> Could I please get a review of this change? This fix allows a certpath >>>> to be validated when a certificate issued by a version 1 trusted cert >>>> has a validity period that doesn't fall within the validity of the >>>> issuer. Trust anchors whose validity do contain the issued cert's >>>> validity period will be prioritized above those that do not. >>>> >>>> webrev: http://cr.openjdk.java.net/~juh/8021804/webrev.00/ >>>> bug: http://bugs.openjdk.java.net/browse/JDK-8021804 >>> >>> In PKIXCertPathValidator, I would remove the call to >>> X509CertSelector.setValidityPeriod on line 98 and just match on the >>> subject and SKID when trying to find a matching trust anchor. Most of >>> the other changes are not necessary I think. At this point you are just >>> trying to find a matching root. In most cases there will only be one >>> possible choice, so unless there are 2 V1 roots with the same subject >>> name and a different public key (ex: due to key rollover). Maybe trying >>> to match on the validity period would help select the right root in the >>> key rollover case, but I'm not sure the extra code is worth it for this >>> rare case (and V1 roots are becoming much less common). And even if it >>> does select the wrong root the first time, the code should fail quickly >>> (when the signature on the cert issued by the root fails), and then >>> proceed to try the next one (and then succeed). >>> >>> --Sean >>> >>> >>> >>> >>> >> > From weijun.wang at oracle.com Wed Mar 12 07:45:33 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 12 Mar 2014 15:45:33 +0800 Subject: Is there a way to provide a default toString() to an interface? Message-ID: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> Hi All I have an interface that wraps an integer, like this interface Wrapper { int getX(); } Why cannot I add a default toString method default String toString() { return "This is " + getX(); } The error is error: default method toString in interface DSAPublicKey overrides a member of java.lang.Object default String toString() { Is there any other way to do it? I do not want to rename it to getString() and let all child classes call it in their toString(). Thanks Max P.S. security-dev@ guys, I want to move toString() back to {DSA|RSA|EC}PublicKey so that we get the same strings for SunPKCS11 and SunJCE. From john.r.rose at oracle.com Wed Mar 12 08:02:05 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 12 Mar 2014 01:02:05 -0700 Subject: Is there a way to provide a default toString() to an interface? In-Reply-To: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> References: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> Message-ID: <3BD338FF-EE7A-47A4-9885-3D1C5613202D@oracle.com> On Mar 12, 2014, at 12:45 AM, Wang Weijun wrote: > I do not want to rename it to getString() and let all child classes call it in their toString(). It is probably best to define a *static* method to hold the default implementation, so that the only candidate for overriding is toString itself. See MethodHandleInfo and InfoFromMemberName (in java.lang.invoke) for one example of this pattern. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Wed Mar 12 08:55:27 2014 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 12 Mar 2014 12:55:27 +0400 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> Message-ID: <532020FF.8070004@oracle.com> Hi Max, 1. DerInputStream.readVector() method is used to decode sets and sequences that can be encoded with indefinite length. If I understand correctly, currently we don't support indefinite length for octet string. According to Xuelei, BER (that supports indefinite length method) is still a popular format, PKCS#7 is BER based, and JDK accepts PKCS#7 records. I think that's why it needs to support indefinite length. If I understand correctly, DerInputStream parses DER sequentially. For example, if there are two DER sequences, the second one will be parsed when the first one is done. If we want the data have already been converted to definite length when a DerInputStream is created, I think we will probably need to re-work all DER parsing classes to parse all the data at first. It probably can be done in DerInputStream, DerValue or DerInputBuffer class. Currently DerInputBuffer does not take care about DER tags at all. I think it will be significant change, and it can affect performance, and use more memory. Do you want to re-work current API this way? 2. In DerValue.init() method, if fullyBuffered is not true, it tries to read all available data. Then, it checks tags and length. I think it is more flexible to let it try to do this regardless fullyBuffered flag. Did I miss anything? 3. DerIndefLenConverter.convert() method process passed data, and return newData: ... // parse and set up the vectors of all the indefinite-lengths while (dataPos < dataSize) { parseTag(); ... } ... newData = new byte[dataSize + numOfTotalLenBytes + unused]; ... // write out the new byte array replacing all the indefinite-lengths // and EOCs while (dataPos < dataSize) { writeTag(); writeLengthAndValue(); } System.arraycopy(indefData, dataSize, newData, dataSize + numOfTotalLenBytes, unused); return newData; ... The tag should be invariant, I think "if (tag != in.read())" added to make sure that it is. Artem On 02/26/2014 01:54 PM, Wang Weijun wrote: > Hi Artem > > The code change looks fine. It seems all your s/getLength/getDefiniteLength/ substitutions are those that only works with a definite length. > > However, I do find the indefinite length support not satisfying. Just not sure if it's worth fixing. For example: > > 1. No idea why DerImputStream::readVector supports indefinite length. Shouldn't the data already have already been converted to definite length when a DerImputStream is created? Or maybe it's created from a DerInputBuffer that has not been converted? Then why don't getOctetString do the same? > > 2. In DerValue::init, if fullyBuffered is not true, then indefinite length should not be supported > > 3. In the same method above, I have no idea why "if (tag != in.read())" is checked after the conversion. Is it possible to be false? > > Thanks > Max > > On Feb 26, 2014, at 15:41, Artem Smotrakov wrote: > >> Hi Sean, >> >> Thank you for your feedback. >> >> It was confusing to me that the impl supports indefinite-length encoding for DER. According to [1], indefinite-length method shall be used for DER: >> >> ... >> 10.1 >> Length forms >> The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with 8.1.3.2 b).] >> ... >> >> But then I found a couple of bugs for support of indefinite-length (for example [2]). Probably it is needed for real applications. >> >> I updated the diff: >> - added getDefiniteLength() methods that throw IOException in case of indefinite-length encoding >> - getLength() method, which can return a negative value, is used to decode sequences, sets in DerInputStream >> - getLength() method is also used in constructor and init() method of DerValue class that check for indefinite-length encoding >> >> Tested with available regression, JCK and SQE tests. >> >> Please take a look: >> >> http://cr.openjdk.java.net/~asmotrak/8028591/webrev.01/ >> >> [1] Information technology ? ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.690 >> [2] https://bugs.openjdk.java.net/browse/JDK-4119673: Need to support indefinite length DER encodings >> >> Artem >> >> On 02/05/2014 06:37 PM, Sean Mullan wrote: >>> Hi Artem, >>> >>> The specific fix looks fine, but there are many other calls to getLength() in DerInputStream that subsequently initialize an array with the return value, and could also cause the same issue. It seems to me that a better fix would be to pass a flag to the getLength method (or create a new method) and if the flag is true, throw an IOException if an indefinite length encoding is used (instead of returning -1). Then, for the encodings where it is illegal to use the indefinite-length method, change the code to call the method with the flag set to true. >>> >>> --Sean >>> >>> On 01/30/2014 03:47 AM, Artem Smotrakov wrote: >>>> Please review this fix for 9: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8028591 >>>> http://cr.openjdk.java.net/~asmotrak/8028591/webrev.00/ >>>> >>>> >>>> getLength() method is used to get a length of bit string. The method can >>>> return a negative value that means indefinite-length encoding that is >>>> not allowed in DER. Currently a negative value is not checked. As a >>>> result, NegativeArraySizeException can occur. >>>> >>>> I added the following checks in >>>> sun.security.util.DerInputStream.getUnalignedBitString() method: >>>> 1. IOException is thrown if getLength() method returns a negative value. >>>> 2. Empty BitArray is returned if getLength() method returns zero. >>>> >>>> I think that an empty bit string should be encoded as "03 01 00" in DER. >>>> I am not sure, but probably "03 00" is valid one as well. I tried both >>>> ones with OpenSSL asn1parse, and both ones were parsed successfully: >>>> >>>> hexdump -C emtpy_bit_string_1 >>>> 00000000 03 01 00 |...| >>>> 00000003 >>>> openssl asn1parse -inform der -in emtpy_bit_string_1 >>>> 0:d=0 hl=2 l= 1 prim: BIT STRING >>>> >>>> hexdump -C emtpy_bit_string_2 >>>> 00000000 03 00 |..| >>>> 00000002 >>>> openssl asn1parse -inform der -in emtpy_bit_string_2 >>>> 0:d=0 hl=2 l= 0 prim: BIT STRING >>>> >>>> 3. IOException is thrown if number of calculated valid bits is negative. >>>> >>>> Added a test case for >>>> test/java/security/cert/X509Certificate/X509BadCertificate.java >>>> (bad-cert-2.pem is corrupted self-signed certificate). Tested with >>>> available regression, SQE and JCK tests. >>>> >>>> Artem From weijun.wang at oracle.com Wed Mar 12 10:14:15 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 12 Mar 2014 18:14:15 +0800 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <532020FF.8070004@oracle.com> References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> <532020FF.8070004@oracle.com> Message-ID: First, let me clarify again that your webrev is fine. All items below are unrelated and we can address it with another bug if necessary. On Mar 12, 2014, at 16:55, Artem Smotrakov wrote: > Hi Max, > > 1. DerInputStream.readVector() method is used to decode sets and sequences that can be encoded with indefinite length. If I understand correctly, currently we don't support indefinite length for octet string. > > According to Xuelei, BER (that supports indefinite length method) is still a popular format, PKCS#7 is BER based, and JDK accepts PKCS#7 records. I think that's why it needs to support indefinite length. I don't know about the details in PKCS #7. Does it say a set/sequence can have indefinite length, but not octet string? My previous confusion was that we only support readVector() with indef len but notgetOctetString(). > > If I understand correctly, DerInputStream parses DER sequentially. For example, if there are two DER sequences, the second one will be parsed when the first one is done. If we want the data have already been converted to definite length when a DerInputStream is created, I think we will probably need to re-work all DER parsing classes to parse all the data at first. It probably can be done in DerInputStream, DerValue or DerInputBuffer class. Currently DerInputBuffer does not take care about DER tags at all. > > I think it will be significant change, and it can affect performance, and use more memory. Do you want to re-work current API this way? No. What I observed is that when a DerInputStream is constructed from a byte[], the init() method already convert indef len to def len, so there is no need to care about it in those getXXX() methods. However, a DerInputStream object can also be created with a DerInputBuffer and there is no conversion there. This makes the internal state inconsistent. > > 2. In DerValue.init() method, if fullyBuffered is not true, it tries to read all available data. Then, it checks tags and length. I think it is more flexible to let it try to do this regardless fullyBuffered flag. Did I miss anything? If fullyBuffered is not true, in.available() will be meaningless and the result of indef->def conversion is not predictable. I honestly believe that reading an indef len encoded data in streaming mode is quite difficult. > > 3. DerIndefLenConverter.convert() method process passed data, and return newData: > > ... > // parse and set up the vectors of all the indefinite-lengths > while (dataPos < dataSize) { > parseTag(); > ... > } > ... > newData = new byte[dataSize + numOfTotalLenBytes + unused]; > ... > // write out the new byte array replacing all the indefinite-lengths > // and EOCs > while (dataPos < dataSize) { > writeTag(); > writeLengthAndValue(); > } > System.arraycopy(indefData, dataSize, > newData, dataSize + numOfTotalLenBytes, unused); > > return newData; > ... > > The tag should be invariant, I think "if (tag != in.read())" added to make sure that it is. My understanding is that since EOC is used to end an existing indef len structure, it cannot appear as the 1st tag in the BER. Therefore the 1st writeTag() always write a non-EOC tag into the 1st byte of output, which is also the 1st byte of the input, so there is no need to check. Can you show me a counter-example? ;-) Thanks Max > > Artem > > On 02/26/2014 01:54 PM, Wang Weijun wrote: >> Hi Artem >> >> The code change looks fine. It seems all your s/getLength/getDefiniteLength/ substitutions are those that only works with a definite length. >> >> However, I do find the indefinite length support not satisfying. Just not sure if it's worth fixing. For example: >> >> 1. No idea why DerImputStream::readVector supports indefinite length. Shouldn't the data already have already been converted to definite length when a DerImputStream is created? Or maybe it's created from a DerInputBuffer that has not been converted? Then why don't getOctetString do the same? >> >> 2. In DerValue::init, if fullyBuffered is not true, then indefinite length should not be supported >> >> 3. In the same method above, I have no idea why "if (tag != in.read())" is checked after the conversion. Is it possible to be false? >> >> Thanks >> Max >> >> On Feb 26, 2014, at 15:41, Artem Smotrakov wrote: >> >>> Hi Sean, >>> >>> Thank you for your feedback. >>> >>> It was confusing to me that the impl supports indefinite-length encoding for DER. According to [1], indefinite-length method shall be used for DER: >>> >>> ... >>> 10.1 >>> Length forms >>> The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with 8.1.3.2 b).] >>> ... >>> >>> But then I found a couple of bugs for support of indefinite-length (for example [2]). Probably it is needed for real applications. >>> >>> I updated the diff: >>> - added getDefiniteLength() methods that throw IOException in case of indefinite-length encoding >>> - getLength() method, which can return a negative value, is used to decode sequences, sets in DerInputStream >>> - getLength() method is also used in constructor and init() method of DerValue class that check for indefinite-length encoding >>> >>> Tested with available regression, JCK and SQE tests. >>> >>> Please take a look: >>> >>> http://cr.openjdk.java.net/~asmotrak/8028591/webrev.01/ >>> >>> [1] Information technology ? ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.690 >>> [2] https://bugs.openjdk.java.net/browse/JDK-4119673: Need to support indefinite length DER encodings >>> >>> Artem >>> >>> On 02/05/2014 06:37 PM, Sean Mullan wrote: >>>> Hi Artem, >>>> >>>> The specific fix looks fine, but there are many other calls to getLength() in DerInputStream that subsequently initialize an array with the return value, and could also cause the same issue. It seems to me that a better fix would be to pass a flag to the getLength method (or create a new method) and if the flag is true, throw an IOException if an indefinite length encoding is used (instead of returning -1). Then, for the encodings where it is illegal to use the indefinite-length method, change the code to call the method with the flag set to true. >>>> >>>> --Sean >>>> >>>> On 01/30/2014 03:47 AM, Artem Smotrakov wrote: >>>>> Please review this fix for 9: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8028591 >>>>> http://cr.openjdk.java.net/~asmotrak/8028591/webrev.00/ >>>>> >>>>> >>>>> getLength() method is used to get a length of bit string. The method can >>>>> return a negative value that means indefinite-length encoding that is >>>>> not allowed in DER. Currently a negative value is not checked. As a >>>>> result, NegativeArraySizeException can occur. >>>>> >>>>> I added the following checks in >>>>> sun.security.util.DerInputStream.getUnalignedBitString() method: >>>>> 1. IOException is thrown if getLength() method returns a negative value. >>>>> 2. Empty BitArray is returned if getLength() method returns zero. >>>>> >>>>> I think that an empty bit string should be encoded as "03 01 00" in DER. >>>>> I am not sure, but probably "03 00" is valid one as well. I tried both >>>>> ones with OpenSSL asn1parse, and both ones were parsed successfully: >>>>> >>>>> hexdump -C emtpy_bit_string_1 >>>>> 00000000 03 01 00 |...| >>>>> 00000003 >>>>> openssl asn1parse -inform der -in emtpy_bit_string_1 >>>>> 0:d=0 hl=2 l= 1 prim: BIT STRING >>>>> >>>>> hexdump -C emtpy_bit_string_2 >>>>> 00000000 03 00 |..| >>>>> 00000002 >>>>> openssl asn1parse -inform der -in emtpy_bit_string_2 >>>>> 0:d=0 hl=2 l= 0 prim: BIT STRING >>>>> >>>>> 3. IOException is thrown if number of calculated valid bits is negative. >>>>> >>>>> Added a test case for >>>>> test/java/security/cert/X509Certificate/X509BadCertificate.java >>>>> (bad-cert-2.pem is corrupted self-signed certificate). Tested with >>>>> available regression, SQE and JCK tests. >>>>> >>>>> Artem > From xuelei.fan at oracle.com Wed Mar 12 11:22:20 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 12 Mar 2014 19:22:20 +0800 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> <532020FF.8070004@oracle.com> Message-ID: <5320436C.7090103@oracle.com> On 3/12/2014 6:14 PM, Wang Weijun wrote: >> > According to Xuelei, BER (that supports indefinite length method) is still a popular format, PKCS#7 is BER based, and JDK accepts PKCS#7 records. I think that's why it needs to support indefinite length. > I don't know about the details in PKCS #7. Does it say a set/sequence can have indefinite length, but not octet string? > >From PKCS#7: ============ The standard is designed such that the enhanced content types can be prepared defined in a single pass using indefinite?-length BER encoding, and processed in a single [RSA78]. pass in any BER encoding. BTW, X.509 cert and CRL are also not necessary DER fully encoded. See my previous reply in the same thread. Xuelei From artem.smotrakov at oracle.com Wed Mar 12 11:24:52 2014 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 12 Mar 2014 15:24:52 +0400 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> <532020FF.8070004@oracle.com> Message-ID: <53204404.10205@oracle.com> On 03/12/2014 02:14 PM, Wang Weijun wrote: > First, let me clarify again that your webrev is fine. All items below are unrelated and we can address it with another bug if necessary. Ok, thank you. > > On Mar 12, 2014, at 16:55, Artem Smotrakov wrote: > >> Hi Max, >> >> 1. DerInputStream.readVector() method is used to decode sets and sequences that can be encoded with indefinite length. If I understand correctly, currently we don't support indefinite length for octet string. >> >> According to Xuelei, BER (that supports indefinite length method) is still a popular format, PKCS#7 is BER based, and JDK accepts PKCS#7 records. I think that's why it needs to support indefinite length. > I don't know about the details in PKCS #7. Does it say a set/sequence can have indefinite length, but not octet string? My previous confusion was that we only support readVector() with indef len but notgetOctetString(). I think that octet string can have indefinite length. I found the following in RFC 2315 (PKCS #7: Cryptographic Message Syntax): The values produced according to this document are intended to be BER-encoded, which means that the values would typically be represented as octet strings https://tools.ietf.org/html/rfc2315 > >> If I understand correctly, DerInputStream parses DER sequentially. For example, if there are two DER sequences, the second one will be parsed when the first one is done. If we want the data have already been converted to definite length when a DerInputStream is created, I think we will probably need to re-work all DER parsing classes to parse all the data at first. It probably can be done in DerInputStream, DerValue or DerInputBuffer class. Currently DerInputBuffer does not take care about DER tags at all. >> >> I think it will be significant change, and it can affect performance, and use more memory. Do you want to re-work current API this way? > No. What I observed is that when a DerInputStream is constructed from a byte[], the init() method already convert indef len to def len, so there is no need to care about it in those getXXX() methods. However, a DerInputStream object can also be created with a DerInputBuffer and there is no conversion there. This makes the internal state inconsistent. > >> 2. In DerValue.init() method, if fullyBuffered is not true, it tries to read all available data. Then, it checks tags and length. I think it is more flexible to let it try to do this regardless fullyBuffered flag. Did I miss anything? > If fullyBuffered is not true, in.available() will be meaningless and the result of indef->def conversion is not predictable. I honestly believe that reading an indef len encoded data in streaming mode is quite difficult. > >> 3. DerIndefLenConverter.convert() method process passed data, and return newData: >> >> ... >> // parse and set up the vectors of all the indefinite-lengths >> while (dataPos < dataSize) { >> parseTag(); >> ... >> } >> ... >> newData = new byte[dataSize + numOfTotalLenBytes + unused]; >> ... >> // write out the new byte array replacing all the indefinite-lengths >> // and EOCs >> while (dataPos < dataSize) { >> writeTag(); >> writeLengthAndValue(); >> } >> System.arraycopy(indefData, dataSize, >> newData, dataSize + numOfTotalLenBytes, unused); >> >> return newData; >> ... >> >> The tag should be invariant, I think "if (tag != in.read())" added to make sure that it is. > My understanding is that since EOC is used to end an existing indef len structure, it cannot appear as the 1st tag in the BER. Therefore the 1st writeTag() always write a non-EOC tag into the 1st byte of output, which is also the 1st byte of the input, so there is no need to check. > > Can you show me a counter-example? ;-) I guess this check was added to make sure that tag value is the same before DerIndefLenConverter.convert() invocation and after that. If the check fails, appropriate IOException is thrown immediately. Probably if there were not this check, and tags differed, it would cause some failure later. But we want to check this situation right away. Artem > > Thanks > Max > >> Artem >> >> On 02/26/2014 01:54 PM, Wang Weijun wrote: >>> Hi Artem >>> >>> The code change looks fine. It seems all your s/getLength/getDefiniteLength/ substitutions are those that only works with a definite length. >>> >>> However, I do find the indefinite length support not satisfying. Just not sure if it's worth fixing. For example: >>> >>> 1. No idea why DerImputStream::readVector supports indefinite length. Shouldn't the data already have already been converted to definite length when a DerImputStream is created? Or maybe it's created from a DerInputBuffer that has not been converted? Then why don't getOctetString do the same? >>> >>> 2. In DerValue::init, if fullyBuffered is not true, then indefinite length should not be supported >>> >>> 3. In the same method above, I have no idea why "if (tag != in.read())" is checked after the conversion. Is it possible to be false? >>> >>> Thanks >>> Max >>> >>> On Feb 26, 2014, at 15:41, Artem Smotrakov wrote: >>> >>>> Hi Sean, >>>> >>>> Thank you for your feedback. >>>> >>>> It was confusing to me that the impl supports indefinite-length encoding for DER. According to [1], indefinite-length method shall be used for DER: >>>> >>>> ... >>>> 10.1 >>>> Length forms >>>> The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with 8.1.3.2 b).] >>>> ... >>>> >>>> But then I found a couple of bugs for support of indefinite-length (for example [2]). Probably it is needed for real applications. >>>> >>>> I updated the diff: >>>> - added getDefiniteLength() methods that throw IOException in case of indefinite-length encoding >>>> - getLength() method, which can return a negative value, is used to decode sequences, sets in DerInputStream >>>> - getLength() method is also used in constructor and init() method of DerValue class that check for indefinite-length encoding >>>> >>>> Tested with available regression, JCK and SQE tests. >>>> >>>> Please take a look: >>>> >>>> http://cr.openjdk.java.net/~asmotrak/8028591/webrev.01/ >>>> >>>> [1] Information technology ? ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.690 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-4119673: Need to support indefinite length DER encodings >>>> >>>> Artem >>>> >>>> On 02/05/2014 06:37 PM, Sean Mullan wrote: >>>>> Hi Artem, >>>>> >>>>> The specific fix looks fine, but there are many other calls to getLength() in DerInputStream that subsequently initialize an array with the return value, and could also cause the same issue. It seems to me that a better fix would be to pass a flag to the getLength method (or create a new method) and if the flag is true, throw an IOException if an indefinite length encoding is used (instead of returning -1). Then, for the encodings where it is illegal to use the indefinite-length method, change the code to call the method with the flag set to true. >>>>> >>>>> --Sean >>>>> >>>>> On 01/30/2014 03:47 AM, Artem Smotrakov wrote: >>>>>> Please review this fix for 9: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8028591 >>>>>> http://cr.openjdk.java.net/~asmotrak/8028591/webrev.00/ >>>>>> >>>>>> >>>>>> getLength() method is used to get a length of bit string. The method can >>>>>> return a negative value that means indefinite-length encoding that is >>>>>> not allowed in DER. Currently a negative value is not checked. As a >>>>>> result, NegativeArraySizeException can occur. >>>>>> >>>>>> I added the following checks in >>>>>> sun.security.util.DerInputStream.getUnalignedBitString() method: >>>>>> 1. IOException is thrown if getLength() method returns a negative value. >>>>>> 2. Empty BitArray is returned if getLength() method returns zero. >>>>>> >>>>>> I think that an empty bit string should be encoded as "03 01 00" in DER. >>>>>> I am not sure, but probably "03 00" is valid one as well. I tried both >>>>>> ones with OpenSSL asn1parse, and both ones were parsed successfully: >>>>>> >>>>>> hexdump -C emtpy_bit_string_1 >>>>>> 00000000 03 01 00 |...| >>>>>> 00000003 >>>>>> openssl asn1parse -inform der -in emtpy_bit_string_1 >>>>>> 0:d=0 hl=2 l= 1 prim: BIT STRING >>>>>> >>>>>> hexdump -C emtpy_bit_string_2 >>>>>> 00000000 03 00 |..| >>>>>> 00000002 >>>>>> openssl asn1parse -inform der -in emtpy_bit_string_2 >>>>>> 0:d=0 hl=2 l= 0 prim: BIT STRING >>>>>> >>>>>> 3. IOException is thrown if number of calculated valid bits is negative. >>>>>> >>>>>> Added a test case for >>>>>> test/java/security/cert/X509Certificate/X509BadCertificate.java >>>>>> (bad-cert-2.pem is corrupted self-signed certificate). Tested with >>>>>> available regression, SQE and JCK tests. >>>>>> >>>>>> Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Mar 12 11:26:25 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 12 Mar 2014 19:26:25 +0800 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <5320436C.7090103@oracle.com> References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> <532020FF.8070004@oracle.com> <5320436C.7090103@oracle.com> Message-ID: <53204461.6070705@oracle.com> On 3/12/2014 7:22 PM, Xuelei Fan wrote: > On 3/12/2014 6:14 PM, Wang Weijun wrote: >>>> According to Xuelei, BER (that supports indefinite length method) is still a popular format, PKCS#7 is BER based, and JDK accepts PKCS#7 records. I think that's why it needs to support indefinite length. >> I don't know about the details in PKCS #7. Does it say a set/sequence can have indefinite length, but not octet string? >> > From PKCS#7: > ============ > The standard is designed such that the enhanced content types can be > prepared defined in a single pass using indefinite?-length BER encoding, > and processed in a single [RSA78]. pass in any BER encoding. > Ooops, bad copy and past: - and processed in a single [RSA78]. pass in any BER encoding. + and processed in a single pass in any BER encoding. > > BTW, X.509 cert and CRL are also not necessary DER fully encoded. See > my previous reply in the same thread. > > > Xuelei > From sean.mullan at oracle.com Wed Mar 12 12:34:15 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Mar 2014 08:34:15 -0400 Subject: [9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert In-Reply-To: <531FA99F.2020303@oracle.com> References: <5310E965.1080803@oracle.com> <531E0BD9.1080300@oracle.com> <531E5218.2080806@oracle.com> <531F873C.2000003@oracle.com> <531FA99F.2020303@oracle.com> Message-ID: <53205447.3040204@oracle.com> Looks good. Thanks, Sean On 03/11/2014 08:26 PM, Jason Uh wrote: > Hi Sean, > > After taking another look at the test, I wanted to make one minor > simplification. I've removed the CRL from the test and disabled > revocation because they weren't adding anything important to the test > (which still passes). I'll push if you're okay with that. > > If you want to take a look: > http://cr.openjdk.java.net/~juh/8021804/webrev.02 > > Jason > > On 3/11/14 2:59 PM, Sean Mullan wrote: >> In the test, you should probably call PKIXParameters.setValidity with a >> fixed date so that the test won't start failing in 2024. Yes, I know >> that's a long time away! Check out other tests to see examples. >> >> Otherwise, fix looks good and you can push without a re-review. >> >> --Sean >> >> On 03/10/2014 08:00 PM, Jason Uh wrote: >>> Thanks, Sean. I've simplified my changes to only removing the call to >>> setValidityPeriod. >>> >>> http://cr.openjdk.java.net/~juh/8021804/webrev.01 >>> >>> Jason >>> >>> On 3/10/14 12:00 PM, Sean Mullan wrote: >>>> Hi Jason, >>>> >>>> Sorry for the delay in reviewing this. >>>> >>>> On 02/28/2014 02:54 PM, Jason Uh wrote: >>>>> Hi Sean, >>>>> >>>>> Could I please get a review of this change? This fix allows a certpath >>>>> to be validated when a certificate issued by a version 1 trusted cert >>>>> has a validity period that doesn't fall within the validity of the >>>>> issuer. Trust anchors whose validity do contain the issued cert's >>>>> validity period will be prioritized above those that do not. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~juh/8021804/webrev.00/ >>>>> bug: http://bugs.openjdk.java.net/browse/JDK-8021804 >>>> >>>> In PKIXCertPathValidator, I would remove the call to >>>> X509CertSelector.setValidityPeriod on line 98 and just match on the >>>> subject and SKID when trying to find a matching trust anchor. Most of >>>> the other changes are not necessary I think. At this point you are just >>>> trying to find a matching root. In most cases there will only be one >>>> possible choice, so unless there are 2 V1 roots with the same subject >>>> name and a different public key (ex: due to key rollover). Maybe trying >>>> to match on the validity period would help select the right root in the >>>> key rollover case, but I'm not sure the extra code is worth it for this >>>> rare case (and V1 roots are becoming much less common). And even if it >>>> does select the wrong root the first time, the code should fail quickly >>>> (when the signature on the cert issued by the root fails), and then >>>> proceed to try the next one (and then succeed). >>>> >>>> --Sean >>>> >>>> >>>> >>>> >>>> >>> >> > From brian.goetz at oracle.com Wed Mar 12 15:57:41 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Mar 2014 11:57:41 -0400 Subject: Is there a way to provide a default toString() to an interface? In-Reply-To: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> References: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> Message-ID: <532083F5.8060906@oracle.com> This is a common question. The short answer is "no". The short explanation of "why not", is that if there's a conflict between a superCLASS method and a superINTERFACE method, the class method wins. Since Object is a class, the toString (or hashCode, or equals) in Object will win over any default. (The error is there to call your attention to the fact that this is a method that cannot be inherited by any subtype; without the error, you'd be posting an even more annoyed message when you discovered (probably much later) that the implementation was not being inherited.) But of course you can ask "well, why is this the rule?" This rule wasn't chosen arbitrarily; alternate rulesets were investigated, some of which might have enabled this usage pattern. But they were dramatically more complicated, and had poorer compatibility characteristics, for very little incremental expressiveness. This current ruleset is simple and 100% compatible (any method inherited under 7 works exactly the same way under 8.) Looking at it from the other side, I understand why one would want to write a default method for equals/hashCode/toString, but in reality this is a pretty bad idea. The reason is that these methods are inextricably bound to an object's state. And the state lives in classes, not interfaces; the class should be the one providing these methods. If we allowed you to inherit these methods from an interface, it would still only work predictably for inheritance patterns that are strictly single-inheritance, such as if we wrote AbstractList as an interface (which we could, because it has no state). But in the general case, interfaces are not used that way, and the weirdness that would ensue because some library class three libraries and nine levels of inheritance up added an equals method and that was inherited by your application and subtly changed its behavior would be a nightmare. So, summarizing: - It would dramatically complicate inheritance rules to enable this, and - Its a bad idea anyway. Now, if you have a complicated toString() method you want to put in an interface, you can do this: interface Wrapper { default String wrapperAsString() { ... } } class X implements Wrapper { String toString() { return wrapperAsString(); } } But the class has to opt-into this being the toString implementation. Same with equals/hashCode. On 3/12/2014 3:45 AM, Wang Weijun wrote: > Hi All > > I have an interface that wraps an integer, like this > > interface Wrapper { > int getX(); > } > > Why cannot I add a default toString method > > default String toString() { > return "This is " + getX(); > } > > The error is > > error: default method toString in interface DSAPublicKey overrides a member of java.lang.Object > default String toString() { > > Is there any other way to do it? I do not want to rename it to getString() and let all child classes call it in their toString(). > > Thanks > Max > > P.S. security-dev@ guys, I want to move toString() back to {DSA|RSA|EC}PublicKey so that we get the same strings for SunPKCS11 and SunJCE. > From weijun.wang at oracle.com Thu Mar 13 02:18:18 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 13 Mar 2014 10:18:18 +0800 Subject: RFR 8037262: typo in error message in KrbAsReq.authenticate() Message-ID: Tiny webrev at http://cr.openjdk.java.net/~weijun/8037262/webrev.00/ Thanks Max From sean.mullan at oracle.com Thu Mar 13 12:32:52 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Mar 2014 08:32:52 -0400 Subject: RFR 8037262: typo in error message in KrbAsReq.authenticate() In-Reply-To: References: Message-ID: <5321A574.7020602@oracle.com> Looks ok, although I noticed another typo: 409 * AP-REP will need to be generated. Should that also be AP-REQ? --Sean On 03/12/2014 10:18 PM, Wang Weijun wrote: > Tiny webrev at > > http://cr.openjdk.java.net/~weijun/8037262/webrev.00/ > > Thanks > Max > From weijun.wang at oracle.com Thu Mar 13 13:45:42 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 13 Mar 2014 21:45:42 +0800 Subject: RFR 8037262: typo in error message in KrbAsReq.authenticate() In-Reply-To: <5321A574.7020602@oracle.com> References: <5321A574.7020602@oracle.com> Message-ID: <294A0838-709A-4151-B0BC-3E8941363806@oracle.com> On Mar 13, 2014, at 20:32, Sean Mullan wrote: > Looks ok, although I noticed another typo: > > 409 * AP-REP will need to be generated. > > Should that also be AP-REQ? No. This method is called by the acceptor when parsing an AP-REQ token. If true (mutual auth required), the acceptor would need to send back a response, i.e. an AP-REP. Thanks Max > > --Sean > > On 03/12/2014 10:18 PM, Wang Weijun wrote: >> Tiny webrev at >> >> http://cr.openjdk.java.net/~weijun/8037262/webrev.00/ >> >> Thanks >> Max >> > From jason.uh at oracle.com Thu Mar 13 18:16:34 2014 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 13 Mar 2014 11:16:34 -0700 Subject: RFR 8037262: typo in error message in KrbAsReq.authenticate() In-Reply-To: References: Message-ID: <5321F602.5000801@oracle.com> 383 * is part of this this AP-REQ. "this" is repeated. Jason On 3/12/14 7:18 PM, Wang Weijun wrote: > Tiny webrev at > > http://cr.openjdk.java.net/~weijun/8037262/webrev.00/ > > Thanks > Max > From rajan.halade at oracle.com Fri Mar 14 20:07:28 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 14 Mar 2014 13:07:28 -0700 Subject: RFR 8033271: Manual security tests have @ignore rather than @run main/manual Message-ID: <53236180.40404@oracle.com> Please review this fix: http://cr.openjdk.java.net/~wetmore/8033271/webrev.01/ I removed @ignore from all these tests and marked them with manual for now. These tests will be considered for automation as a separate effort and will be executed manually for now. Thanks, Rajan From valerie.peng at oracle.com Fri Mar 14 22:11:52 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 14 Mar 2014 15:11:52 -0700 Subject: Code Review Request: 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending Message-ID: <53237EA8.10506@oracle.com> Max, Can you please help reviewing the fix for 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending? I ended up re-factoring the code to clean things up. So, the changes are somewhat extensive. I have also replaced the debug callbacks with native printf calls. The webrev is: http://cr.openjdk.java.net/~valeriep/8031003/webrev.00/ Thanks, Valerie From xuelei.fan at oracle.com Fri Mar 14 23:39:21 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 15 Mar 2014 07:39:21 +0800 Subject: RFR 8033271: Manual security tests have @ignore rather than @run main/manual In-Reply-To: <53236180.40404@oracle.com> References: <53236180.40404@oracle.com> Message-ID: <53239329.6030007@oracle.com> I like the changes. I'm afraid the lines following the @summary tag will be joined into one line during testing. We had such bad experiences in a lot JSSE tests. Would you like put the manual testing comment into a separated commend block? For example, change the update * @summary Ensure authentication via GSS-API/Kerberos v5 works. - * @ignore see runwjaas.csh for instructions for how to run this test - */ -/* - * Can set logging to FINEST to view exchange. + * Set logging to FINEST to view exchange. + * See runwjaas.csh for instructions for how to run this test + * + * @run main/manual AuthOnly To * @summary Ensure authentication via GSS-API/Kerberos v5 works. - * @ignore see runwjaas.csh for instructions for how to run this test + * @run main/manual AuthOnly */ /* - * Can set logging to FINEST to view exchange. + * Set logging to FINEST to view exchange. + * See runwjaas.csh for instructions for how to run this test */ Thanks, Xuelei On 3/15/2014 4:07 AM, Rajan Halade wrote: > Please review this fix: > > http://cr.openjdk.java.net/~wetmore/8033271/webrev.01/ > > I removed @ignore from all these tests and marked them with manual for > now. These tests will be considered for automation as a separate effort > and will be executed manually for now. > > Thanks, > Rajan > From rajan.halade at oracle.com Sat Mar 15 00:52:23 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 14 Mar 2014 17:52:23 -0700 Subject: RFR 8033271: Manual security tests have @ignore rather than @run main/manual In-Reply-To: <53239329.6030007@oracle.com> References: <53236180.40404@oracle.com> <53239329.6030007@oracle.com> Message-ID: <5323A447.8030607@oracle.com> Thanks Xuelei for your comment. I updated all tests as per your suggestion - http://cr.openjdk.java.net/~wetmore/8033271/webrev.02/ Please review again. Thanks, Rajan On 3/14/2014 16:39, Xuelei Fan wrote: > I like the changes. I'm afraid the lines following the @summary tag will > be joined into one line during testing. We had such bad experiences in > a lot JSSE tests. Would you like put the manual testing comment into a > separated commend block? > > For example, change the update > > * @summary Ensure authentication via GSS-API/Kerberos v5 works. > - * @ignore see runwjaas.csh for instructions for how to run this test > - */ > -/* > - * Can set logging to FINEST to view exchange. > + * Set logging to FINEST to view exchange. > + * See runwjaas.csh for instructions for how to run this test > + * > + * @run main/manual AuthOnly > > To > > * @summary Ensure authentication via GSS-API/Kerberos v5 works. > - * @ignore see runwjaas.csh for instructions for how to run this test > + * @run main/manual AuthOnly > */ > > /* > - * Can set logging to FINEST to view exchange. > + * Set logging to FINEST to view exchange. > + * See runwjaas.csh for instructions for how to run this test > */ > > Thanks, > Xuelei > > On 3/15/2014 4:07 AM, Rajan Halade wrote: >> Please review this fix: >> >> http://cr.openjdk.java.net/~wetmore/8033271/webrev.01/ >> >> I removed @ignore from all these tests and marked them with manual for >> now. These tests will be considered for automation as a separate effort >> and will be executed manually for now. >> >> Thanks, >> Rajan >> From xuelei.fan at oracle.com Sat Mar 15 01:36:17 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 15 Mar 2014 09:36:17 +0800 Subject: RFR 8033271: Manual security tests have @ignore rather than @run main/manual In-Reply-To: <5323A447.8030607@oracle.com> References: <53236180.40404@oracle.com> <53239329.6030007@oracle.com> <5323A447.8030607@oracle.com> Message-ID: <5323AE91.6000309@oracle.com> Minimal comments: test/sun/security/smartcardio/TestAll.java ========================================== Looks like there is no actual update. test/sun/security/smartcardio/* =============================== - 32 //This test requires special hardware. + 32 // This test requires special hardware. Looks nicer if there is leading space. test/sun/security/smartcardio/TestConnectAgain.java =================================================== - 29 * @run main/manual TestTransmit + 29 * @run main/manual TestConnectAgain Maybe a typo here. Would you please make the update? test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java =================================================== - 35 * JSSE supports algorithm constraints with CR 6916074, - 36 * need to update this test case in JDK 7 soon + + 35 * JSSE supports algorithm constraints with CR 6916074, need to + 36 * update this test case in JDK 7 soon Would you mind add a blank line and join the two line accordingly? Otherwise, looks fine to me. Thanks, Xuelei On 3/15/2014 8:52 AM, Rajan Halade wrote: > Thanks Xuelei for your comment. I updated all tests as per your > suggestion - > > http://cr.openjdk.java.net/~wetmore/8033271/webrev.02/ > > Please review again. > > Thanks, > Rajan > On 3/14/2014 16:39, Xuelei Fan wrote: >> I like the changes. I'm afraid the lines following the @summary tag will >> be joined into one line during testing. We had such bad experiences in >> a lot JSSE tests. Would you like put the manual testing comment into a >> separated commend block? >> >> For example, change the update >> >> * @summary Ensure authentication via GSS-API/Kerberos v5 works. >> - * @ignore see runwjaas.csh for instructions for how to run this test >> - */ >> -/* >> - * Can set logging to FINEST to view exchange. >> + * Set logging to FINEST to view exchange. >> + * See runwjaas.csh for instructions for how to run this test >> + * >> + * @run main/manual AuthOnly >> >> To >> >> * @summary Ensure authentication via GSS-API/Kerberos v5 works. >> - * @ignore see runwjaas.csh for instructions for how to run this test >> + * @run main/manual AuthOnly >> */ >> >> /* >> - * Can set logging to FINEST to view exchange. >> + * Set logging to FINEST to view exchange. >> + * See runwjaas.csh for instructions for how to run this test >> */ >> >> Thanks, >> Xuelei >> >> On 3/15/2014 4:07 AM, Rajan Halade wrote: >>> Please review this fix: >>> >>> http://cr.openjdk.java.net/~wetmore/8033271/webrev.01/ >>> >>> I removed @ignore from all these tests and marked them with manual for >>> now. These tests will be considered for automation as a separate effort >>> and will be executed manually for now. >>> >>> Thanks, >>> Rajan >>> > From xuelei.fan at oracle.com Mon Mar 17 08:34:12 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Mar 2014 16:34:12 +0800 Subject: Code review request 8037346, Need to terminate server process if client runs into problems Message-ID: <5326B384.6050800@oracle.com> Hi, Please review this test fix: webrev: http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ Tests fix. If client runs into problems, the server side may be blocked on socket.accept(). This fix set SO_TIMEOUT to 5 seconds for each server socket, so that if client runs into problems, the server will terminate itself within 5 seconds. Thanks, Xuelei From weijun.wang at oracle.com Mon Mar 17 08:47:36 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 17 Mar 2014 16:47:36 +0800 Subject: Code Review Request: 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending In-Reply-To: <53237EA8.10506@oracle.com> References: <53237EA8.10506@oracle.com> Message-ID: NativeUtil.h: 88: How about puts(s) or printf("%s", s) (in case s includes "%")? NativeUtil.c: 514-516: not necessary? 539-543: Why not TRACEn here? 639-659: It looks like if cbytes == NULL then the function returns NULL with no exception throwing and this would break something in GSSLibStub.c. But actually cbytes will never be NULL there, right? How about remove the cbytes == NULL check at all? 644: I have no idea why cbytes->length != 0 is checked. Why cannot it be an empty string? GSSLibStub.c: 92: This need not be a jboolean, just use an int. 536: I guess getJavaString on 529 already released outNameBuf? 1103: This is not only "cleanup", it is "error". 1105: Not safe to releaseName/releaseCred here? Thanks Max On Mar 15, 2014, at 6:11, Valerie (Yu-Ching) Peng wrote: > Max, > > Can you please help reviewing the fix for 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending? > > I ended up re-factoring the code to clean things up. So, the changes are somewhat extensive. I have also replaced the debug callbacks with native printf calls. > > The webrev is: > http://cr.openjdk.java.net/~valeriep/8031003/webrev.00/ > > Thanks, > Valerie From weijun.wang at oracle.com Mon Mar 17 08:59:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 17 Mar 2014 16:59:34 +0800 Subject: Code review request 8037346, Need to terminate server process if client runs into problems In-Reply-To: <5326B384.6050800@oracle.com> References: <5326B384.6050800@oracle.com> Message-ID: <6EA8C36D-89DB-4711-A232-610A4AD5D857@oracle.com> What is the problem now? Test fails after 120 seconds of default timeout? This SO_TIMEOUT could be useful to make sure a test fails early, but I am not sure if the value is big enough. If the failure is rare, I would choose 30 seconds. --Max On Mar 17, 2014, at 16:34, Xuelei Fan wrote: > Hi, > > Please review this test fix: > > webrev: http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ > > Tests fix. If client runs into problems, the server side may be blocked > on socket.accept(). This fix set SO_TIMEOUT to 5 seconds for each > server socket, so that if client runs into problems, the server will > terminate itself within 5 seconds. > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon Mar 17 09:06:27 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Mar 2014 17:06:27 +0800 Subject: Code review request 8037346, Need to terminate server process if client runs into problems In-Reply-To: <6EA8C36D-89DB-4711-A232-610A4AD5D857@oracle.com> References: <5326B384.6050800@oracle.com> <6EA8C36D-89DB-4711-A232-610A4AD5D857@oracle.com> Message-ID: <5326BB13.9090207@oracle.com> On 3/17/2014 4:59 PM, Wang Weijun wrote: > What is the problem now? Test fails after 120 seconds of default timeout? > These test are for shell script tests. The bug reported stated the server did not terminated on Windows. I think may be shell script test is not controlled by the default timeout, or it get run manually. > This SO_TIMEOUT could be useful to make sure a test fails early, but I am not sure if the value is big enough. If the failure is rare, I would choose 30 seconds. > 30 seconds is OK. Xuelei > --Max > > On Mar 17, 2014, at 16:34, Xuelei Fan wrote: > >> Hi, >> >> Please review this test fix: >> >> webrev: http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ >> >> Tests fix. If client runs into problems, the server side may be blocked >> on socket.accept(). This fix set SO_TIMEOUT to 5 seconds for each >> server socket, so that if client runs into problems, the server will >> terminate itself within 5 seconds. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Mon Mar 17 09:16:12 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 17 Mar 2014 17:16:12 +0800 Subject: Code review request 8037346, Need to terminate server process if client runs into problems In-Reply-To: <5326BB13.9090207@oracle.com> References: <5326B384.6050800@oracle.com> <6EA8C36D-89DB-4711-A232-610A4AD5D857@oracle.com> <5326BB13.9090207@oracle.com> Message-ID: On Mar 17, 2014, at 17:06, Xuelei Fan wrote: > On 3/17/2014 4:59 PM, Wang Weijun wrote: >> What is the problem now? Test fails after 120 seconds of default timeout? >> > These test are for shell script tests. The bug reported stated the > server did not terminated on Windows. I think may be shell script test > is not controlled by the default timeout, or it get run manually. I guess the tests are written in shell because of that $HOSTNAME? Is it possible to get that info inside Java? > >> This SO_TIMEOUT could be useful to make sure a test fails early, but I am not sure if the value is big enough. If the failure is rare, I would choose 30 seconds. >> > 30 seconds is OK. Good. --Max > > Xuelei > >> --Max >> >> On Mar 17, 2014, at 16:34, Xuelei Fan wrote: >> >>> Hi, >>> >>> Please review this test fix: >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ >>> >>> Tests fix. If client runs into problems, the server side may be blocked >>> on socket.accept(). This fix set SO_TIMEOUT to 5 seconds for each >>> server socket, so that if client runs into problems, the server will >>> terminate itself within 5 seconds. >>> >>> Thanks, >>> Xuelei >> > From xuelei.fan at oracle.com Mon Mar 17 09:17:19 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Mar 2014 17:17:19 +0800 Subject: Code review request 8037346, Need to terminate server process if client runs into problems In-Reply-To: <5326BB13.9090207@oracle.com> References: <5326B384.6050800@oracle.com> <6EA8C36D-89DB-4711-A232-610A4AD5D857@oracle.com> <5326BB13.9090207@oracle.com> Message-ID: <5326BD9F.40009@oracle.com> Update to use 30 seconds: http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ Thanks, Xuelei On 3/17/2014 5:06 PM, Xuelei Fan wrote: > On 3/17/2014 4:59 PM, Wang Weijun wrote: >> What is the problem now? Test fails after 120 seconds of default timeout? >> > These test are for shell script tests. The bug reported stated the > server did not terminated on Windows. I think may be shell script test > is not controlled by the default timeout, or it get run manually. > >> This SO_TIMEOUT could be useful to make sure a test fails early, but I am not sure if the value is big enough. If the failure is rare, I would choose 30 seconds. >> > 30 seconds is OK. > > Xuelei > >> --Max >> >> On Mar 17, 2014, at 16:34, Xuelei Fan wrote: >> >>> Hi, >>> >>> Please review this test fix: >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ >>> >>> Tests fix. If client runs into problems, the server side may be blocked >>> on socket.accept(). This fix set SO_TIMEOUT to 5 seconds for each >>> server socket, so that if client runs into problems, the server will >>> terminate itself within 5 seconds. >>> >>> Thanks, >>> Xuelei >> > From xuelei.fan at oracle.com Mon Mar 17 09:21:53 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Mar 2014 17:21:53 +0800 Subject: Code review request 8037346, Need to terminate server process if client runs into problems In-Reply-To: References: <5326B384.6050800@oracle.com> <6EA8C36D-89DB-4711-A232-610A4AD5D857@oracle.com> <5326BB13.9090207@oracle.com> Message-ID: <5326BEB1.6040204@oracle.com> On 3/17/2014 5:16 PM, Wang Weijun wrote: > > On Mar 17, 2014, at 17:06, Xuelei Fan wrote: > >> On 3/17/2014 4:59 PM, Wang Weijun wrote: >>> What is the problem now? Test fails after 120 seconds of default timeout? >>> >> These test are for shell script tests. The bug reported stated the >> server did not terminated on Windows. I think may be shell script test >> is not controlled by the default timeout, or it get run manually. > > I guess the tests are written in shell because of that $HOSTNAME? Is it possible to get that info inside Java? > I did not dig it further. Looks like it is possible. I will not address the improvement this time. Xuelei >> >>> This SO_TIMEOUT could be useful to make sure a test fails early, but I am not sure if the value is big enough. If the failure is rare, I would choose 30 seconds. >>> >> 30 seconds is OK. > > Good. > > --Max > >> >> Xuelei >> >>> --Max >>> >>> On Mar 17, 2014, at 16:34, Xuelei Fan wrote: >>> >>>> Hi, >>>> >>>> Please review this test fix: >>>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ >>>> >>>> Tests fix. If client runs into problems, the server side may be blocked >>>> on socket.accept(). This fix set SO_TIMEOUT to 5 seconds for each >>>> server socket, so that if client runs into problems, the server will >>>> terminate itself within 5 seconds. >>>> >>>> Thanks, >>>> Xuelei >>> >> > From weijun.wang at oracle.com Mon Mar 17 09:22:48 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 17 Mar 2014 17:22:48 +0800 Subject: Code review request 8037346, Need to terminate server process if client runs into problems In-Reply-To: <5326BD9F.40009@oracle.com> References: <5326B384.6050800@oracle.com> <6EA8C36D-89DB-4711-A232-610A4AD5D857@oracle.com> <5326BB13.9090207@oracle.com> <5326BD9F.40009@oracle.com> Message-ID: Looks good now. Thanks. --Max On Mar 17, 2014, at 17:17, Xuelei Fan wrote: > Update to use 30 seconds: > > http://cr.openjdk.java.net/~xuelei/8037346/webrev.00/ From rajan.halade at oracle.com Mon Mar 17 20:17:17 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 17 Mar 2014 13:17:17 -0700 Subject: RFR 8033271: Manual security tests have @ignore rather than @run main/manual In-Reply-To: <5323AE91.6000309@oracle.com> References: <53236180.40404@oracle.com> <53239329.6030007@oracle.com> <5323A447.8030607@oracle.com> <5323AE91.6000309@oracle.com> Message-ID: <5327584D.8010909@oracle.com> Thanks again! Updated review with corrections - http://cr.openjdk.java.net/~wetmore/8033271/webrev.03/ - Rajan On 3/14/2014 18:36, Xuelei Fan wrote: > Minimal comments: > > test/sun/security/smartcardio/TestAll.java > ========================================== > Looks like there is no actual update. > > > test/sun/security/smartcardio/* > =============================== > - 32 //This test requires special hardware. > + 32 // This test requires special hardware. > > Looks nicer if there is leading space. > > > test/sun/security/smartcardio/TestConnectAgain.java > =================================================== > - 29 * @run main/manual TestTransmit > + 29 * @run main/manual TestConnectAgain > > Maybe a typo here. Would you please make the update? > > > test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java > =================================================== > - 35 * JSSE supports algorithm constraints with CR 6916074, > - 36 * need to update this test case in JDK 7 soon > + > + 35 * JSSE supports algorithm constraints with CR 6916074, need to > + 36 * update this test case in JDK 7 soon > > Would you mind add a blank line and join the two line accordingly? > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > From xuelei.fan at oracle.com Mon Mar 17 23:05:17 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 18 Mar 2014 07:05:17 +0800 Subject: RFR 8033271: Manual security tests have @ignore rather than @run main/manual In-Reply-To: <5327584D.8010909@oracle.com> References: <53236180.40404@oracle.com> <53239329.6030007@oracle.com> <5323A447.8030607@oracle.com> <5323AE91.6000309@oracle.com> <5327584D.8010909@oracle.com> Message-ID: <53277FAD.7070403@oracle.com> Looks fine to me. Thank you, Rajan! Xuelei On 3/18/2014 4:17 AM, Rajan Halade wrote: > Thanks again! Updated review with corrections - > > http://cr.openjdk.java.net/~wetmore/8033271/webrev.03/ > > - Rajan > > On 3/14/2014 18:36, Xuelei Fan wrote: >> Minimal comments: >> >> test/sun/security/smartcardio/TestAll.java >> ========================================== >> Looks like there is no actual update. >> >> >> test/sun/security/smartcardio/* >> =============================== >> - 32 //This test requires special hardware. >> + 32 // This test requires special hardware. >> >> Looks nicer if there is leading space. >> >> >> test/sun/security/smartcardio/TestConnectAgain.java >> =================================================== >> - 29 * @run main/manual TestTransmit >> + 29 * @run main/manual TestConnectAgain >> >> Maybe a typo here. Would you please make the update? >> >> >> test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java >> =================================================== >> - 35 * JSSE supports algorithm constraints with CR 6916074, >> - 36 * need to update this test case in JDK 7 soon >> + >> + 35 * JSSE supports algorithm constraints with CR 6916074, need to >> + 36 * update this test case in JDK 7 soon >> >> Would you mind add a blank line and join the two line accordingly? >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> > From bradford.wetmore at oracle.com Tue Mar 18 20:46:38 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 18 Mar 2014 13:46:38 -0700 Subject: RFR 8033271: Manual security tests have @ignore rather than @run main/manual In-Reply-To: <53277FAD.7070403@oracle.com> References: <53236180.40404@oracle.com> <53239329.6030007@oracle.com> <5323A447.8030607@oracle.com> <5323AE91.6000309@oracle.com> <5327584D.8010909@oracle.com> <53277FAD.7070403@oracle.com> Message-ID: <5328B0AE.6010505@oracle.com> Rajan, All of the tests I looked at have incorrectly modified copyright information. Please fix and then I can push. Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights reserved. should be: Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. Not: * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. Brad On 3/17/2014 4:05 PM, Xuelei Fan wrote: > Looks fine to me. Thank you, Rajan! > > Xuelei > > On 3/18/2014 4:17 AM, Rajan Halade wrote: >> Thanks again! Updated review with corrections - >> >> http://cr.openjdk.java.net/~wetmore/8033271/webrev.03/ >> >> - Rajan >> >> On 3/14/2014 18:36, Xuelei Fan wrote: >>> Minimal comments: >>> >>> test/sun/security/smartcardio/TestAll.java >>> ========================================== >>> Looks like there is no actual update. >>> >>> >>> test/sun/security/smartcardio/* >>> =============================== >>> - 32 //This test requires special hardware. >>> + 32 // This test requires special hardware. >>> >>> Looks nicer if there is leading space. >>> >>> >>> test/sun/security/smartcardio/TestConnectAgain.java >>> =================================================== >>> - 29 * @run main/manual TestTransmit >>> + 29 * @run main/manual TestConnectAgain >>> >>> Maybe a typo here. Would you please make the update? >>> >>> >>> test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java >>> =================================================== >>> - 35 * JSSE supports algorithm constraints with CR 6916074, >>> - 36 * need to update this test case in JDK 7 soon >>> + >>> + 35 * JSSE supports algorithm constraints with CR 6916074, need to >>> + 36 * update this test case in JDK 7 soon >>> >>> Would you mind add a blank line and join the two line accordingly? >>> >>> Otherwise, looks fine to me. >>> >>> Thanks, >>> Xuelei >>> >>> >> > From zaiyao.liu at oracle.com Wed Mar 19 11:55:30 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 19 Mar 2014 19:55:30 +0800 Subject: Can you give some suggestion about how build a Hacked JDK for The Malformed Certificates tests Message-ID: <532985B2.5010806@oracle.com> Hi team, I am developing The Malformed Certificates tests, this test exist to test JDK's SSL ability to withstand attack in the form of deliberately 1.3 million malformed ASN.1-encoded data. Detail please refer test plan: http://wiki.se.oracle.com/display/JPG/Malformed+Certificates+Test+Plan The idea is to "attack" an JDK SSL/SMIME process by sending it intentionally malformed certificates (or malformed SMIME messages), and ensure that the process under attack does not: * crash * leak * accept any of the bad certs or messages as if they were good To do the Malformed Certificates tests with SSL certs, I should launch two JVM, one as "JDK under test", the other as "attack JDK", I want to use JDK8 as attack JDK, and this JDK should be modified to allow use of invalid certificates, I have try to use following code to generate invalid certificate: import java.io.FileInputStream; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; public class X509CertificateLoad { /** * Load a X509 certificate from file. */ public static void main(String[] args) throws Exception { FileInputStream fis = new FileInputStream(args[0]); CertificateFactory cf = CertificateFactory.getInstance("X509"); X509Certificate cert = (X509Certificate) cf.generateCertificate(fis); System.out.println("SUCCESS"); } } got following error: X509Certificate cert = (X509Certificate) cf.generateCertificate(fis);java.lang.NegativeArraySizeException at sun.security.util.DerInputStream.getUnalignedBitString(DerInputStream.java:238) at sun.security.x509.X509Key.parse(X509Key.java:171) at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) Can you give some suggestion about how to bypass this kind of check to generator a certificate for invalid certificate? (I will use this invalid to attack normal JDK). Thanks Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Wed Mar 19 15:36:23 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 19 Mar 2014 08:36:23 -0700 Subject: RFR 8037258: AIOB while parsing CRL for revoked certificate Message-ID: <5329B977.7010502@oracle.com> Please review this small fix - http://cr.openjdk.java.net/~mullan/webrevs/8037258/webrev.02/ I have also updated the source to remove unused variables and updated javadoc information. Thanks, Rajan From mhall at mhcomputing.net Wed Mar 19 19:01:40 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Wed, 19 Mar 2014 12:01:40 -0700 Subject: Can you give some suggestion about how build a Hacked JDK for The Malformed Certificates tests In-Reply-To: <532985B2.5010806@oracle.com> References: <532985B2.5010806@oracle.com> Message-ID: <20140319190140.GA4647@mhcomputing.net> On Wed, Mar 19, 2014 at 07:55:30PM +0800, zaiyao liu wrote: > I am developing The Malformed Certificates tests, this test exist > to test JDK's SSL ability to withstand attack in the form of > deliberately 1.3 million malformed ASN.1-encoded data. > Detail please refer test plan: http://wiki.se.oracle.com/display/JPG/Malformed+Certificates+Test+Plan This is a VERY good thing to try. I worked previously on a protocol mutation system and found several serious bugs in GnuTLS using X.509 field corruptions which resulted in a security advisory. A competitor later found very similar issues in OpenSSL. > I want to use JDK8 as attack JDK, and this JDK should be modified to > allow use of invalid certificates, I have try to use following code > to generate invalid certificate: This simply cannot work via any sort of hack or workaround, because the JDK trusts the ASN.1 data when creating and allocating X.509 certificate substructures, such as the values behind all of these getter functions on the X509Certificate class: abstract int getBasicConstraints() List getExtendedKeyUsage() Collection> getIssuerAlternativeNames() abstract Principal getIssuerDN() abstract boolean[] getIssuerUniqueID() X500Principal getIssuerX500Principal() abstract boolean[] getKeyUsage() abstract Date getNotAfter() abstract Date getNotBefore() abstract BigInteger getSerialNumber() abstract String getSigAlgName() abstract String getSigAlgOID() abstract byte[] getSigAlgParams() abstract byte[] getSignature() Collection> getSubjectAlternativeNames() abstract boolean[] getSubjectUniqueID() X500Principal getSubjectX500Principal() abstract byte[] getTBSCertificate() abstract int getVersion() When the JDK attempts to load a cert, it expects valid ASN.1 encodings for all of these when allocating the structures. In order to perform your test, you'll need to make a modified version of JSSE or a modified version of the Bouncy Castle libraries, which will allow you to send an arbitrary byte[], *Stream class, or *Buffer class (from NIO), containing a corrupted X.509 certificate, which will be sent verbatim onto the Socket or Channel, with no modification. Good Luck! I think you'll find some fascinating results, and more than a few potential bugs. Matthew. From xuelei.fan at oracle.com Wed Mar 19 23:12:21 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Mar 2014 07:12:21 +0800 Subject: Review Request of JDK Enhancement Proposal: OCSP stapling Message-ID: <532A2455.9080902@oracle.com> Hi All, Please review the JDK Enhancement Proposal, support OCSP stapling in SunJSSE security provider. Detailed, please refer to the draft JEP: http://cr.openjdk.java.net/~xuelei/8034248/jep-csre.txt Feel free to make comment and send your feedback to the alias. Thanks, Xuelei From xuelei.fan at oracle.com Wed Mar 19 23:19:06 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Mar 2014 07:19:06 +0800 Subject: Review Request of JDK Enhancement Proposal: DTLS Message-ID: <532A25EA.7040802@oracle.com> Hi, Please review the JDK Enhancement Proposal, Support Datagram Transport Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the JSSE API and the SunJSSE security provider. Detailed, please refer to the draft JEP: http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt Feel free to make comment and send your feedback to the alias. Thanks, Xuelei From mhall at mhcomputing.net Thu Mar 20 00:31:58 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Wed, 19 Mar 2014 17:31:58 -0700 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <532A25EA.7040802@oracle.com> References: <532A25EA.7040802@oracle.com> Message-ID: <20140320003158.GA5754@mhcomputing.net> Xuelei, Is there an existing method for determining valid PMTU from inside of Java? If not then supplying correct segment size to whatever DTLSEngine (or however it's named) class would be non-trivial and could require native code. If there is not such support, then a separate spec would be needed to add that support, before it would be possible to get the new DTLS support to work very reliably. Matthew. On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: > Hi, > > Please review the JDK Enhancement Proposal, Support Datagram Transport > Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the > JSSE API and the SunJSSE security provider. Detailed, please refer to > the draft JEP: > > http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt > > Feel free to make comment and send your feedback to the alias. > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Mar 20 00:50:27 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Mar 2014 08:50:27 +0800 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140320003158.GA5754@mhcomputing.net> References: <532A25EA.7040802@oracle.com> <20140320003158.GA5754@mhcomputing.net> Message-ID: <532A3B53.6000407@oracle.com> PMTU is a key point of the design. I was wondering to expose this application layer as a configurable parameter. If it is too big (or not configured), DTLSEngine(let call it temporarily) will downgrade the size automatically, just as the previous messages get lost. It's good point that need a separate spec to determine the PMTU. I will see what we can do here. Thanks, Xuelei On 3/20/2014 8:31 AM, Matthew Hall wrote: > Xuelei, > > Is there an existing method for determining valid PMTU from inside of Java? If > not then supplying correct segment size to whatever DTLSEngine (or however > it's named) class would be non-trivial and could require native code. > > If there is not such support, then a separate spec would be needed to add that > support, before it would be possible to get the new DTLS support to work very > reliably. > > Matthew. > > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: >> Hi, >> >> Please review the JDK Enhancement Proposal, Support Datagram Transport >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the >> JSSE API and the SunJSSE security provider. Detailed, please refer to >> the draft JEP: >> >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt >> >> Feel free to make comment and send your feedback to the alias. >> >> Thanks, >> Xuelei From bradford.wetmore at oracle.com Thu Mar 20 18:31:34 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 20 Mar 2014 11:31:34 -0700 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <532A3B53.6000407@oracle.com> References: <532A25EA.7040802@oracle.com> <20140320003158.GA5754@mhcomputing.net> <532A3B53.6000407@oracle.com> Message-ID: <532B3406.1030607@oracle.com> On 3/19/2014 5:50 PM, Xuelei Fan wrote: > I was wondering to expose this > application layer as a configurable parameter. Just to make sure we're talking about the same thing, you're pointing out: 1. The need for determining the PMTU for the various protocol types. (UDP/DCCP/TCP/SCTP/etc) 2. Communicating that to the JSSE layer. Since the current plan is for this DTLS impl to be transport protocol-independent, I think needs to be configurable primarily at the JSSE API. You could take a guess at a default PMTU, but the answer likely won't be right for all. Brad From xuelei.fan at oracle.com Thu Mar 20 22:58:50 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Mar 2014 06:58:50 +0800 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <532B3406.1030607@oracle.com> References: <532A25EA.7040802@oracle.com> <20140320003158.GA5754@mhcomputing.net> <532A3B53.6000407@oracle.com> <532B3406.1030607@oracle.com> Message-ID: <532B72AA.7080102@oracle.com> You are right. Probably(As I have not designed the API, let me use probably), PMTU would be a configuration parameter. NetworkInterface.getMTU() can help here. Although MTU is not PMTU, but it is normally "correct". In case of corner cases where the configured MTU does not work, probably, the implementation of DTLSEngine can downgrade the size of PMTU automatically. Therefore, it is a two steps thing. Configurable parameter, and adjustable if the configured value does not work. It would be great if there is PMTU discovery API in Java, which can simplify the implementation of DTLS. Xuelei On 3/21/2014 2:31 AM, Bradford Wetmore wrote: > > On 3/19/2014 5:50 PM, Xuelei Fan wrote: >> I was wondering to expose this >> application layer as a configurable parameter. > > Just to make sure we're talking about the same thing, you're pointing out: > > 1. The need for determining the PMTU for the various protocol types. > (UDP/DCCP/TCP/SCTP/etc) > > 2. Communicating that to the JSSE layer. Since the current plan is for > this DTLS impl to be transport protocol-independent, I think needs to be > configurable primarily at the JSSE API. You could take a guess at a > default PMTU, but the answer likely won't be right for all. > > Brad > From mhall at mhcomputing.net Fri Mar 21 00:28:29 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 20 Mar 2014 17:28:29 -0700 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <532B72AA.7080102@oracle.com> References: <532A25EA.7040802@oracle.com> <20140320003158.GA5754@mhcomputing.net> <532A3B53.6000407@oracle.com> <532B3406.1030607@oracle.com> <532B72AA.7080102@oracle.com> Message-ID: <20140321002829.GB9508@mhcomputing.net> On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: > here. Although MTU is not PMTU, but it is normally "correct". I would state, not "normally correct", but "frequently correct". In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of these are used for Site-to-Site VPN, which will appear often in the context of RTP packets and SRTP packets, which happen to travel over VPNs. > It would be great if there is PMTU discovery API in Java, which can > simplify the implementation of DTLS. Without it, I think there will be a lot of odd bugs occurring. Matthew. From gnu.andrew at redhat.com Fri Mar 21 17:28:25 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Mar 2014 13:28:25 -0400 (EDT) Subject: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library In-Reply-To: <52FA22DA.1020004@redhat.com> References: <1362133828.2303.18.camel@localhost> <5177BC6A.7030308@redhat.com> <517858AF.2070503@oracle.com> <468091249.4123477.1391528895077.JavaMail.root@redhat.com> <52FA22DA.1020004@redhat.com> Message-ID: <1213718090.980097.1395422905874.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 02/04/2014 04:48 PM, Andrew Hughes wrote: > > > As has already been mentioned on this thread, libraries should have their > > version increased when the ABI changes. Thus, a libpcsclite.so.2 or later > > would indicate a different ABI to what the JDK PCSC code was written for. > > > > Now, it may be that the code also works fine with .2, but from my > > perspective, > > I'd rather the JDK fail with an error message and someone manually points > > it > > at a working .2 (and hopefully gives feedback that it's all good), than > > the JDK grabs any old version of the library and then crashes when the ABI > > doesn't match. That not only looks worse, but it's potentially harder to > > debug as well. > > I still think it's better to remove the dlopen/dlsym machinery and use > dynamic linking instead. > I've provided that as an option in IcedTea, but it then means that a different PCSC implementation can't be swapped in. > -- > Florian Weimer / Red Hat Product Security Team > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From valerie.peng at oracle.com Fri Mar 21 21:48:55 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 21 Mar 2014 14:48:55 -0700 Subject: Code Review Request: 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending In-Reply-To: References: <53237EA8.10506@oracle.com> Message-ID: <532CB3C7.8050804@oracle.com> Max, Thanks a lot for the review, please find comments in line. Webrev updated: http://cr.openjdk.java.net/~valeriep/8031003/webrev.01 On 03/17/14 01:47, Wang Weijun wrote: > NativeUtil.h: > > 88: How about puts(s) or printf("%s", s) (in case s includes "%")? Sure. > NativeUtil.c: > > 514-516: not necessary? Ok. > 539-543: Why not TRACEn here? Didn't want to add TRACE4 just for this one call. Anyway, changed the 2nd one to just 3 arguments and used TRACE3 for both calls. > 639-659: It looks like if cbytes == NULL then the function returns NULL with no exception throwing and this would break something in GSSLibStub.c. But actually cbytes will never be NULL there, right? How about remove the cbytes == NULL check at all? Hmm, getJavaBuffer is an utility method, so supposedly, I think it's reasonable to return NULL with no exception when cbytes is either NULL or GSS_C_NO_BUFFER. So, I prefer to keep the check of cbytes == NULL check since we have no control over the underlying native GSS lib. The result of getJavaBuffer(...) calls are mostly returned as results. I'd expect if the native buffer is null or empty, the error code should indicate the cause and corresponding exception would be thrown. > 644: I have no idea why cbytes->length != 0 is checked. Why cannot it be an empty string? It's not that it can't be empty. But rather just that I don't see the need to distinctish between NULL and byte[0] (yet). > GSSLibStub.c: > > 92: This need not be a jboolean, just use an int. > > 536: I guess getJavaString on 529 already released outNameBuf? Good catch, I missed this one when changing code back and forth. > 1103: This is not only "cleanup", it is "error". Agreed. > 1105: Not safe to releaseName/releaseCred here? I think it should be done but the earlier code isn't doing that. I've added code to release srcName, targetName, and delCred if error is encountered. Thanks, Valerie > > Thanks > Max > > > On Mar 15, 2014, at 6:11, Valerie (Yu-Ching) Peng wrote: > >> Max, >> >> Can you please help reviewing the fix for 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending? >> >> I ended up re-factoring the code to clean things up. So, the changes are somewhat extensive. I have also replaced the debug callbacks with native printf calls. >> >> The webrev is: >> http://cr.openjdk.java.net/~valeriep/8031003/webrev.00/ >> >> Thanks, >> Valerie From xuelei.fan at oracle.com Fri Mar 21 23:38:44 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 22 Mar 2014 07:38:44 +0800 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140321002829.GB9508@mhcomputing.net> References: <532A25EA.7040802@oracle.com> <20140320003158.GA5754@mhcomputing.net> <532A3B53.6000407@oracle.com> <532B3406.1030607@oracle.com> <532B72AA.7080102@oracle.com> <20140321002829.GB9508@mhcomputing.net> Message-ID: <532CCD84.1030400@oracle.com> Networking experts, any suggestion? Xuelei On 3/21/2014 8:28 AM, Matthew Hall wrote: > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: >> here. Although MTU is not PMTU, but it is normally "correct". > > I would state, not "normally correct", but "frequently correct". > > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of > these are used for Site-to-Site VPN, which will appear often in the context of > RTP packets and SRTP packets, which happen to travel over VPNs. > >> It would be great if there is PMTU discovery API in Java, which can >> simplify the implementation of DTLS. > > Without it, I think there will be a lot of odd bugs occurring. > > Matthew. > -------------- next part -------------- An embedded message was scrubbed... From: Xuelei Fan Subject: Re: Review Request of JDK Enhancement Proposal: DTLS Date: Thu, 20 Mar 2014 08:50:27 +0800 Size: 1965 URL: From christos at zoulas.com Fri Mar 21 23:46:22 2014 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 21 Mar 2014 19:46:22 -0400 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <532CCD84.1030400@oracle.com> from Xuelei Fan (Mar 22, 7:38am) Message-ID: <20140321234622.73BAA17FDA1@rebar.astron.com> On Mar 22, 7:38am, xuelei.fan at oracle.com (Xuelei Fan) wrote: -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | Networking experts, any suggestion? I have not seen pmtu exposed at the application layer before. Has anyone else? christos | | Xuelei | | On 3/21/2014 8:28 AM, Matthew Hall wrote: | > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: | >> here. Although MTU is not PMTU, but it is normally "correct". | > | > I would state, not "normally correct", but "frequently correct". | > | > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of | > these are used for Site-to-Site VPN, which will appear often in the context of | > RTP packets and SRTP packets, which happen to travel over VPNs. | > | >> It would be great if there is PMTU discovery API in Java, which can | >> simplify the implementation of DTLS. | > | > Without it, I think there will be a lot of odd bugs occurring. | > | > Matthew. | > | | | --------------090406030702020009070402 | Content-Type: message/rfc822; | name="Attached Message" | Content-Transfer-Encoding: 7bit | Content-Disposition: attachment; | filename="Attached Message" | | Message-ID: <532A3B53.6000407 at oracle.com> | Date: Thu, 20 Mar 2014 08:50:27 +0800 | From: Xuelei Fan | User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 | MIME-Version: 1.0 | To: Matthew Hall | CC: OpenJDK | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | References: <532A25EA.7040802 at oracle.com> <20140320003158.GA5754 at mhcomputing.net> | In-Reply-To: <20140320003158.GA5754 at mhcomputing.net> | Content-Type: text/plain; charset=ISO-8859-1 | Content-Transfer-Encoding: 7bit | | PMTU is a key point of the design. I was wondering to expose this | application layer as a configurable parameter. If it is too big (or not | configured), DTLSEngine(let call it temporarily) will downgrade the size | automatically, just as the previous messages get lost. | | It's good point that need a separate spec to determine the PMTU. I will | see what we can do here. | | Thanks, | Xuelei | | On 3/20/2014 8:31 AM, Matthew Hall wrote: | > Xuelei, | > | > Is there an existing method for determining valid PMTU from inside of Java? If | > not then supplying correct segment size to whatever DTLSEngine (or however | > it's named) class would be non-trivial and could require native code. | > | > If there is not such support, then a separate spec would be needed to add that | > support, before it would be possible to get the new DTLS support to work very | > reliably. | > | > Matthew. | > | > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: | >> Hi, | >> | >> Please review the JDK Enhancement Proposal, Support Datagram Transport | >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the | >> JSSE API and the SunJSSE security provider. Detailed, please refer to | >> the draft JEP: | >> | >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt | >> | >> Feel free to make comment and send your feedback to the alias. | >> | >> Thanks, | >> Xuelei | | | --------------090406030702020009070402-- -- End of excerpt from Xuelei Fan From mhall at mhcomputing.net Sat Mar 22 06:48:46 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Fri, 21 Mar 2014 23:48:46 -0700 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140321234622.73BAA17FDA1@rebar.astron.com> References: <532CCD84.1030400@oracle.com> <20140321234622.73BAA17FDA1@rebar.astron.com> Message-ID: <20140322064846.GA14432@mhcomputing.net> The following bug and source code [1] are present in OpenSSL: http://rt.openssl.org/Ticket/Display.html?id=1929 I think something similar could be done in the JDK, by making some tweaks to the SocketOptions classes to expose some more options. I'm pretty sure something relating to this will work in POSIX JDK for Linux, Solaris, OS X, but not sure what different magic would be needed for Windows. Then there could be some kind of way to generate the right discovery datagrams, figure out the result, and feed it to the DTLSEngine for packetization purposes. Also, there is some DTLS capability in Bouncy Castle, we could see what they allow in terms of packetization as well, though I doubt they'll have what OpenSSL has, since IP_MTU_DISCOVER is probably not available to them either. I am glad you guys are working on this... I already have some use cases in mind for it! :-D Matthew. Reference [1]: case BIO_CTRL_DGRAM_MTU_DISCOVER: #if defined(OPENSSL_SYS_LINUX) && defined(IP_MTU_DISCOVER) && defined(IP_PMTUDISC_DO) addr_len = (socklen_t)sizeof(addr); memset((void *)&addr, 0, sizeof(addr)); if (getsockname(b->num, &addr.sa, &addr_len) < 0) { ret = 0; break; } switch (addr.sa.sa_family) { case AF_INET: sockopt_val = IP_PMTUDISC_DO; if ((ret = setsockopt(b->num, IPPROTO_IP, IP_MTU_DISCOVER, &sockopt_val, sizeof(sockopt_val))) < 0) perror("setsockopt"); break; #if OPENSSL_USE_IPV6 && defined(IPV6_MTU_DISCOVER) && defined(IPV6_PMTUDISC_DO) case AF_INET6: sockopt_val = IPV6_PMTUDISC_DO; if ((ret = setsockopt(b->num, IPPROTO_IPV6, IPV6_MTU_DISCOVER, &sockopt_val, sizeof(sockopt_val))) < 0) perror("setsockopt"); break; #endif On Fri, Mar 21, 2014 at 07:46:22PM -0400, Christos Zoulas wrote: > On Mar 22, 7:38am, xuelei.fan at oracle.com (Xuelei Fan) wrote: > -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS > > | Networking experts, any suggestion? > > I have not seen pmtu exposed at the application layer before. Has anyone > else? > > christos > > | > | Xuelei > | > | On 3/21/2014 8:28 AM, Matthew Hall wrote: > | > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: > | >> here. Although MTU is not PMTU, but it is normally "correct". > | > > | > I would state, not "normally correct", but "frequently correct". > | > > | > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of > | > these are used for Site-to-Site VPN, which will appear often in the context of > | > RTP packets and SRTP packets, which happen to travel over VPNs. > | > > | >> It would be great if there is PMTU discovery API in Java, which can > | >> simplify the implementation of DTLS. > | > > | > Without it, I think there will be a lot of odd bugs occurring. > | > > | > Matthew. > | > > | > | > | --------------090406030702020009070402 > | Content-Type: message/rfc822; > | name="Attached Message" > | Content-Transfer-Encoding: 7bit > | Content-Disposition: attachment; > | filename="Attached Message" > | > | Message-ID: <532A3B53.6000407 at oracle.com> > | Date: Thu, 20 Mar 2014 08:50:27 +0800 > | From: Xuelei Fan > | User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 > | MIME-Version: 1.0 > | To: Matthew Hall > | CC: OpenJDK > | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS > | References: <532A25EA.7040802 at oracle.com> <20140320003158.GA5754 at mhcomputing.net> > | In-Reply-To: <20140320003158.GA5754 at mhcomputing.net> > | Content-Type: text/plain; charset=ISO-8859-1 > | Content-Transfer-Encoding: 7bit > | > | PMTU is a key point of the design. I was wondering to expose this > | application layer as a configurable parameter. If it is too big (or not > | configured), DTLSEngine(let call it temporarily) will downgrade the size > | automatically, just as the previous messages get lost. > | > | It's good point that need a separate spec to determine the PMTU. I will > | see what we can do here. > | > | Thanks, > | Xuelei > | > | On 3/20/2014 8:31 AM, Matthew Hall wrote: > | > Xuelei, > | > > | > Is there an existing method for determining valid PMTU from inside of Java? If > | > not then supplying correct segment size to whatever DTLSEngine (or however > | > it's named) class would be non-trivial and could require native code. > | > > | > If there is not such support, then a separate spec would be needed to add that > | > support, before it would be possible to get the new DTLS support to work very > | > reliably. > | > > | > Matthew. > | > > | > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: > | >> Hi, > | >> > | >> Please review the JDK Enhancement Proposal, Support Datagram Transport > | >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the > | >> JSSE API and the SunJSSE security provider. Detailed, please refer to > | >> the draft JEP: > | >> > | >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt > | >> > | >> Feel free to make comment and send your feedback to the alias. > | >> > | >> Thanks, > | >> Xuelei > | > | > | --------------090406030702020009070402-- > -- End of excerpt from Xuelei Fan > > From christos at zoulas.com Sat Mar 22 15:30:28 2014 From: christos at zoulas.com (Christos Zoulas) Date: Sat, 22 Mar 2014 11:30:28 -0400 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140322064846.GA14432@mhcomputing.net> from Matthew Hall (Mar 21, 11:48pm) Message-ID: <20140322153028.72DB817FDA1@rebar.astron.com> On Mar 21, 11:48pm, mhall at mhcomputing.net (Matthew Hall) wrote: -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | The following bug and source code [1] are present in OpenSSL: | | http://rt.openssl.org/Ticket/Display.html?id=1929 This link is not public. Can you post a summary? | I think something similar could be done in the JDK, by making some tweaks to | the SocketOptions classes to expose some more options. I'm pretty sure | something relating to this will work in POSIX JDK for Linux, Solaris, OS X, | but not sure what different magic would be needed for Windows. | | Then there could be some kind of way to generate the right discovery | datagrams, figure out the result, and feed it to the DTLSEngine for | packetization purposes. | | Also, there is some DTLS capability in Bouncy Castle, we could see what they | allow in terms of packetization as well, though I doubt they'll have what | OpenSSL has, since IP_MTU_DISCOVER is probably not available to them either. | | I am glad you guys are working on this... I already have some use cases in | mind for it! :-D So what happens on !linux? christos From mhall at mhcomputing.net Sat Mar 22 16:39:08 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Sat, 22 Mar 2014 09:39:08 -0700 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140322153028.72DB817FDA1@rebar.astron.com> References: <20140322153028.72DB817FDA1@rebar.astron.com> Message-ID: Sorry about the hiccup. Supposedly the bug will work if you get in with user guest PW guest. As for non Windows, I don't know a lot of Windows programmers, only malware analysts. So we'd need to ask somebody in Sun's porting group I think. Or if somebody has a contact at Microsoft. Matthew. -- Sent from my mobile device. On March 22, 2014 8:30:28 AM PDT, christos at zoulas.com wrote: >On Mar 21, 11:48pm, mhall at mhcomputing.net (Matthew Hall) wrote: >-- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS > >| The following bug and source code [1] are present in OpenSSL: >| >| http://rt.openssl.org/Ticket/Display.html?id=1929 > >This link is not public. Can you post a summary? > >| I think something similar could be done in the JDK, by making some >tweaks to >| the SocketOptions classes to expose some more options. I'm pretty >sure >| something relating to this will work in POSIX JDK for Linux, Solaris, >OS X, >| but not sure what different magic would be needed for Windows. >| >| Then there could be some kind of way to generate the right discovery >| datagrams, figure out the result, and feed it to the DTLSEngine for >| packetization purposes. >| >| Also, there is some DTLS capability in Bouncy Castle, we could see >what they >| allow in terms of packetization as well, though I doubt they'll have >what >| OpenSSL has, since IP_MTU_DISCOVER is probably not available to them >either. >| >| I am glad you guys are working on this... I already have some use >cases in >| mind for it! :-D > >So what happens on !linux? > >christos From christos at zoulas.com Sat Mar 22 17:14:28 2014 From: christos at zoulas.com (Christos Zoulas) Date: Sat, 22 Mar 2014 13:14:28 -0400 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: from Matthew Hall (Mar 22, 9:39am) Message-ID: <20140322171428.320E717FDA1@rebar.astron.com> On Mar 22, 9:39am, mhall at mhcomputing.net (Matthew Hall) wrote: -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | Sorry about the hiccup. Supposedly the bug will work if you get in with user guest PW guest. Thanks. christos From fweimer at redhat.com Mon Mar 24 08:07:01 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 24 Mar 2014 09:07:01 +0100 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140320003158.GA5754@mhcomputing.net> References: <532A25EA.7040802@oracle.com> <20140320003158.GA5754@mhcomputing.net> Message-ID: <532FE7A5.3050806@redhat.com> On 03/20/2014 01:31 AM, Matthew Hall wrote: > Is there an existing method for determining valid PMTU from inside of Java? If > not then supplying correct segment size to whatever DTLSEngine (or however > it's named) class would be non-trivial and could require native code. > > If there is not such support, then a separate spec would be needed to add that > support, before it would be possible to get the new DTLS support to work very > reliably. I don't think it's wise to rely on PMTU for UDP. It's not going to work reliably over the Internet. Extensive kernel support only exists on Linux (and people argue that it's against the RFC). The BSD sockets API cannot properly report ICMP errors even if the network generates. Is this really required for DTLS? -- Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Mon Mar 24 08:18:15 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 24 Mar 2014 09:18:15 +0100 Subject: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library In-Reply-To: <1213718090.980097.1395422905874.JavaMail.zimbra@redhat.com> References: <1362133828.2303.18.camel@localhost> <5177BC6A.7030308@redhat.com> <517858AF.2070503@oracle.com> <468091249.4123477.1391528895077.JavaMail.root@redhat.com> <52FA22DA.1020004@redhat.com> <1213718090.980097.1395422905874.JavaMail.zimbra@redhat.com> Message-ID: <532FEA47.7050109@redhat.com> On 03/21/2014 06:28 PM, Andrew Hughes wrote: >> I still think it's better to remove the dlopen/dlsym machinery and use >> dynamic linking instead. >> > > I've provided that as an option in IcedTea, but it then means that a different PCSC > implementation can't be swapped in. I think you can still use LD_LIBRARY_PATH or LD_PRELOAD. But isn't there an expectation that PCSC will provide a dispatching layer of its own? -- Florian Weimer / Red Hat Product Security Team From michael.x.mcmahon at oracle.com Mon Mar 24 11:52:09 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 24 Mar 2014 11:52:09 +0000 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140322064846.GA14432@mhcomputing.net> References: <532CCD84.1030400@oracle.com> <20140321234622.73BAA17FDA1@rebar.astron.com> <20140322064846.GA14432@mhcomputing.net> Message-ID: <53301C69.2010808@oracle.com> My understanding is that the original PMTU discovery spec RFC 1191 is not very effective due to its reliance on ICMP messages that are often filtered out by routers. There was an update in RFC 4821 which removes the dependency on ICMP and that seems to be effective I'm just wondering then how DTLS expects it to be done? Michael. On 22/03/14 06:48, Matthew Hall wrote: > The following bug and source code [1] are present in OpenSSL: > > http://rt.openssl.org/Ticket/Display.html?id=1929 > > I think something similar could be done in the JDK, by making some tweaks to > the SocketOptions classes to expose some more options. I'm pretty sure > something relating to this will work in POSIX JDK for Linux, Solaris, OS X, > but not sure what different magic would be needed for Windows. > > Then there could be some kind of way to generate the right discovery > datagrams, figure out the result, and feed it to the DTLSEngine for > packetization purposes. > > Also, there is some DTLS capability in Bouncy Castle, we could see what they > allow in terms of packetization as well, though I doubt they'll have what > OpenSSL has, since IP_MTU_DISCOVER is probably not available to them either. > > I am glad you guys are working on this... I already have some use cases in > mind for it! :-D > > Matthew. > > Reference [1]: > > case BIO_CTRL_DGRAM_MTU_DISCOVER: > #if defined(OPENSSL_SYS_LINUX) && defined(IP_MTU_DISCOVER) && defined(IP_PMTUDISC_DO) > addr_len = (socklen_t)sizeof(addr); > memset((void *)&addr, 0, sizeof(addr)); > if (getsockname(b->num, &addr.sa, &addr_len) < 0) > { > ret = 0; > break; > } > switch (addr.sa.sa_family) > { > case AF_INET: > sockopt_val = IP_PMTUDISC_DO; > if ((ret = setsockopt(b->num, IPPROTO_IP, IP_MTU_DISCOVER, > &sockopt_val, sizeof(sockopt_val))) < 0) > perror("setsockopt"); > break; > #if OPENSSL_USE_IPV6 && defined(IPV6_MTU_DISCOVER) && defined(IPV6_PMTUDISC_DO) > case AF_INET6: > sockopt_val = IPV6_PMTUDISC_DO; > if ((ret = setsockopt(b->num, IPPROTO_IPV6, IPV6_MTU_DISCOVER, > &sockopt_val, sizeof(sockopt_val))) < 0) > perror("setsockopt"); > break; > #endif > > > On Fri, Mar 21, 2014 at 07:46:22PM -0400, Christos Zoulas wrote: >> On Mar 22, 7:38am, xuelei.fan at oracle.com (Xuelei Fan) wrote: >> -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS >> >> | Networking experts, any suggestion? >> >> I have not seen pmtu exposed at the application layer before. Has anyone >> else? >> >> christos >> >> | >> | Xuelei >> | >> | On 3/21/2014 8:28 AM, Matthew Hall wrote: >> | > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: >> | >> here. Although MTU is not PMTU, but it is normally "correct". >> | > >> | > I would state, not "normally correct", but "frequently correct". >> | > >> | > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of >> | > these are used for Site-to-Site VPN, which will appear often in the context of >> | > RTP packets and SRTP packets, which happen to travel over VPNs. >> | > >> | >> It would be great if there is PMTU discovery API in Java, which can >> | >> simplify the implementation of DTLS. >> | > >> | > Without it, I think there will be a lot of odd bugs occurring. >> | > >> | > Matthew. >> | > >> | >> | >> | --------------090406030702020009070402 >> | Content-Type: message/rfc822; >> | name="Attached Message" >> | Content-Transfer-Encoding: 7bit >> | Content-Disposition: attachment; >> | filename="Attached Message" >> | >> | Message-ID: <532A3B53.6000407 at oracle.com> >> | Date: Thu, 20 Mar 2014 08:50:27 +0800 >> | From: Xuelei Fan >> | User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 >> | MIME-Version: 1.0 >> | To: Matthew Hall >> | CC: OpenJDK >> | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS >> | References: <532A25EA.7040802 at oracle.com> <20140320003158.GA5754 at mhcomputing.net> >> | In-Reply-To: <20140320003158.GA5754 at mhcomputing.net> >> | Content-Type: text/plain; charset=ISO-8859-1 >> | Content-Transfer-Encoding: 7bit >> | >> | PMTU is a key point of the design. I was wondering to expose this >> | application layer as a configurable parameter. If it is too big (or not >> | configured), DTLSEngine(let call it temporarily) will downgrade the size >> | automatically, just as the previous messages get lost. >> | >> | It's good point that need a separate spec to determine the PMTU. I will >> | see what we can do here. >> | >> | Thanks, >> | Xuelei >> | >> | On 3/20/2014 8:31 AM, Matthew Hall wrote: >> | > Xuelei, >> | > >> | > Is there an existing method for determining valid PMTU from inside of Java? If >> | > not then supplying correct segment size to whatever DTLSEngine (or however >> | > it's named) class would be non-trivial and could require native code. >> | > >> | > If there is not such support, then a separate spec would be needed to add that >> | > support, before it would be possible to get the new DTLS support to work very >> | > reliably. >> | > >> | > Matthew. >> | > >> | > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: >> | >> Hi, >> | >> >> | >> Please review the JDK Enhancement Proposal, Support Datagram Transport >> | >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the >> | >> JSSE API and the SunJSSE security provider. Detailed, please refer to >> | >> the draft JEP: >> | >> >> | >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt >> | >> >> | >> Feel free to make comment and send your feedback to the alias. >> | >> >> | >> Thanks, >> | >> Xuelei >> | >> | >> | --------------090406030702020009070402-- >> -- End of excerpt from Xuelei Fan >> >> From fweimer at redhat.com Mon Mar 24 16:30:50 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 24 Mar 2014 17:30:50 +0100 Subject: [PATCH] Add class java.security.StandardMessageDigests Message-ID: <53305DBA.1000001@redhat.com> This CR adds a new class java.security.StandardMessageDigests: Could I get a bug number if this change is fine in principle? Cryptographic hash functions are frequently used directly, often for non-cryptographic purposes, so I think it makes sense to provide a convenient way to access implementations for the most common hashes. The new class follows the java.nio.charset.StandardCharsets precedent (separate class, "Standard" in the name). I deliberately did not include support for MD5. It would be nice if we could drop the NoSuchAlgorithmException, but this would be problematic once there are providers that do not support SHA-1. Instantiating digest objects through cloning should be quite a bit faster than the provider route (but I measured this some time ago only, so these results could be outdated by now). -- Florian Weimer / Red Hat Product Security Team From sean.mullan at oracle.com Mon Mar 24 21:46:25 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 Mar 2014 17:46:25 -0400 Subject: RFR 8037258: AIOB while parsing CRL for revoked certificate In-Reply-To: <5329B977.7010502@oracle.com> References: <5329B977.7010502@oracle.com> Message-ID: <5330A7B1.9030805@oracle.com> Looks good to me. --Sean On 03/19/2014 11:36 AM, Rajan Halade wrote: > Please review this small fix - > > http://cr.openjdk.java.net/~mullan/webrevs/8037258/webrev.02/ > > I have also updated the source to remove unused variables and updated > javadoc information. > > Thanks, > Rajan From valerie.peng at oracle.com Mon Mar 24 23:13:17 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 24 Mar 2014 16:13:17 -0700 Subject: Review Request of JDK 9 Enhancement Proposal: AEAD/CCM Cipher Mode Message-ID: <5330BC0D.1070304@oracle.com> Here is the enhancement proposal for adding CCM cipher mode support to JDK. For details, please refer to the following JEP: http://cr.openjdk.java.net/~valeriep/8008342/jepCCM.txt Comments or feedback welcome. Thanks, Valerie From bernd-2014 at eckenfels.net Mon Mar 24 23:59:39 2014 From: bernd-2014 at eckenfels.net (Bernd Eckenfels) Date: Tue, 25 Mar 2014 00:59:39 +0100 Subject: Review Request of JDK 9 Enhancement Proposal: AEAD/CCM Cipher Mode In-Reply-To: <5330BC0D.1070304@oracle.com> References: <5330BC0D.1070304@oracle.com> Message-ID: <20140325005939.00005a19.bernd-2014@eckenfels.net> Am Mon, 24 Mar 2014 16:13:17 -0700 schrieb "Valerie (Yu-Ching) Peng" : > > Here is the enhancement proposal for adding CCM cipher mode support > to JDK. For details, please refer to the following JEP: > > http://cr.openjdk.java.net/~valeriep/8008342/jepCCM.txt > > Comments or feedback welcome. Sounds great, there is no mentioning of specific machine instructions to speed up CCM (like PCLMULQDQ for GCM) or no relationship to the AES intrinsic. It would really be a shame if (both) new modes cannot benefit from typical hardware speedups. (especially when it is out of scope for PKCS#11). From mhall at mhcomputing.net Tue Mar 25 00:24:37 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Mon, 24 Mar 2014 17:24:37 -0700 Subject: Review Request of JDK 9 Enhancement Proposal: AEAD/CCM Cipher Mode In-Reply-To: <20140325005939.00005a19.bernd-2014@eckenfels.net> References: <5330BC0D.1070304@oracle.com> <20140325005939.00005a19.bernd-2014@eckenfels.net> Message-ID: <20140325002437.GB27900@mhcomputing.net> On Tue, Mar 25, 2014 at 12:59:39AM +0100, Bernd Eckenfels wrote: > Sounds great, there is no mentioning of specific machine instructions > to speed up CCM (like PCLMULQDQ for GCM) or no relationship to the AES > intrinsic. It would really be a shame if (both) new modes cannot > benefit from typical hardware speedups. (especially when it is out of > scope for PKCS#11). If it's out of scope for PKCS #11 then I believe the only decent hope would be adding some of these calls to sun.misc.Unsafe or similar, then calling them from inside of the JCE code for the new cipher suites. Matthew. From anthony.scarpino at oracle.com Tue Mar 25 00:40:18 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 24 Mar 2014 17:40:18 -0700 Subject: Review Request of JDK 9 Enhancement Proposal: AEAD/CCM Cipher Mode In-Reply-To: <20140325005939.00005a19.bernd-2014@eckenfels.net> References: <5330BC0D.1070304@oracle.com> <20140325005939.00005a19.bernd-2014@eckenfels.net> Message-ID: <5330D072.4080608@oracle.com> On 03/24/2014 04:59 PM, Bernd Eckenfels wrote: > Am Mon, 24 Mar 2014 16:13:17 -0700 > schrieb "Valerie (Yu-Ching) Peng" : > >> >> Here is the enhancement proposal for adding CCM cipher mode support >> to JDK. For details, please refer to the following JEP: >> >> http://cr.openjdk.java.net/~valeriep/8008342/jepCCM.txt >> >> Comments or feedback welcome. > > Sounds great, there is no mentioning of specific machine instructions > to speed up CCM (like PCLMULQDQ for GCM) or no relationship to the AES > intrinsic. It would really be a shame if (both) new modes cannot > benefit from typical hardware speedups. (especially when it is out of > scope for PKCS#11). > Hardware acceleration is not being addressed as part of the CCM implementation. PCLMULQDQ is a whole different thing with other challenges. Tony From fweimer at redhat.com Thu Mar 27 13:34:47 2014 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 27 Mar 2014 14:34:47 +0100 Subject: Can you give some suggestion about how build a Hacked JDK for The Malformed Certificates tests In-Reply-To: <532985B2.5010806@oracle.com> References: <532985B2.5010806@oracle.com> Message-ID: <533428F7.6030109@redhat.com> On 03/19/2014 12:55 PM, zaiyao liu wrote: > Can you give some suggestion about how to bypass this kind of check to > generator a certificate for invalid certificate? (I will use this > invalid to attack normal JDK). IIRC, I sent you a reproducer when reporting CVE-2009-3876 that does this. I haven't got it anymore, but I believe I used a trust manager that returned a subclass of X509CertImpl with an overridden getEncoded() method that simply returned crafted DER. No further changes or bootclasspath hacks were required. -- Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Thu Mar 27 13:52:20 2014 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 27 Mar 2014 14:52:20 +0100 Subject: Can you give some suggestion about how build a Hacked JDK for The Malformed Certificates tests In-Reply-To: <533428F7.6030109@redhat.com> References: <532985B2.5010806@oracle.com> <533428F7.6030109@redhat.com> Message-ID: <53342D14.3070602@redhat.com> On 03/27/2014 02:34 PM, Florian Weimer wrote: > IIRC, I sent you a reproducer when reporting CVE-2009-3876 that does > this. I haven't got it anymore, but I believe I used a trust manager Sorry, this has to be an X509KeyManager with a suitable getCertificateChain() method. > that returned a subclass of X509CertImpl with an overridden getEncoded() > method that simply returned crafted DER. No further changes or > bootclasspath hacks were required. -- Florian Weimer / Red Hat Product Security Team From jdk-security-dev at whittington.net.nz Thu Mar 27 21:29:56 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Fri, 28 Mar 2014 10:29:56 +1300 Subject: Very slow performance of AES/GCM in JDK 8 SunJCE provider Message-ID: <51D9BF97-3C0D-4B93-AFD7-CD5C38E4B304@whittington.net.nz> Hi all I?ve noticed that the performance of the AES/GCM implementation in the JDK 8 SunJCE provider is very slow. On a simple micro-benchmark (standard caveats etc. etc.) encrypting 10 MB blocks of random data (not decrypt) I get the following rough throughputs: AES/ECB +UseAESIntrinsics - 600 MB/s (btw this is awesome fast for Java, up from about 300 MB/s in Java 7) AES/ECB -UseAESIntrinsics - 120 MB/s (again a good bump from about 90 MB/s in Java 7) AES/GCM - 4 MB/s 4 MB/s is pretty catastrophic (especially compared to the stellar baseline AES performance). A quick peek in a profiler reveals pretty much all the time is in GHash.blockMult()/getBit()/shift(). The performance of the AES/GCM mode is comparable to other pure Java implementations without table based multiplier optimisations (which typically provide speeds in the 40-60 MB/s on the same micro-benchmark). I wonder if the JDK implementation could adopt one of those approaches or (better) implement an intrinsic to speed this up (perhaps using the CLMUL interaction set when available). cheers tim ? java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) Darwin 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 From ivan at azulsystems.com Fri Mar 28 08:37:44 2014 From: ivan at azulsystems.com (Ivan Krylov) Date: Fri, 28 Mar 2014 08:37:44 +0000 Subject: Very slow performance of AES/GCM in JDK 8 SunJCE provider In-Reply-To: <51D9BF97-3C0D-4B93-AFD7-CD5C38E4B304@whittington.net.nz> References: <51D9BF97-3C0D-4B93-AFD7-CD5C38E4B304@whittington.net.nz> Message-ID: <32DBCC01-A23E-4B87-A16D-017F9D86846E@azulsystems.com> Tim, Do you have a Haswell powered machine at your disposal? JDK-7184394[1] should have addressed this issue Thanks, Ivan [1] - https://bugs.openjdk.java.net/browse/JDK-7184394 On 28 Mar 2014, at 01:29, Tim Whittington wrote: > Hi all > > I?ve noticed that the performance of the AES/GCM implementation in the JDK 8 SunJCE provider is very slow. > > On a simple micro-benchmark (standard caveats etc. etc.) encrypting 10 MB blocks of random data (not decrypt) I get the following rough throughputs: > > AES/ECB +UseAESIntrinsics - 600 MB/s (btw this is awesome fast for Java, up from about 300 MB/s in Java 7) > AES/ECB -UseAESIntrinsics - 120 MB/s (again a good bump from about 90 MB/s in Java 7) > AES/GCM - 4 MB/s > > 4 MB/s is pretty catastrophic (especially compared to the stellar baseline AES performance). > > A quick peek in a profiler reveals pretty much all the time is in GHash.blockMult()/getBit()/shift(). > The performance of the AES/GCM mode is comparable to other pure Java implementations without table based multiplier optimisations (which typically provide speeds in the 40-60 MB/s on the same micro-benchmark). > > I wonder if the JDK implementation could adopt one of those approaches or (better) implement an intrinsic to speed this up (perhaps using the CLMUL interaction set when available). > > cheers > tim > > ? > > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) > > Darwin 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 > > From jdk-security-dev at whittington.net.nz Fri Mar 28 09:08:09 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Fri, 28 Mar 2014 22:08:09 +1300 Subject: Very slow performance of AES/GCM in JDK 8 SunJCE provider In-Reply-To: <32DBCC01-A23E-4B87-A16D-017F9D86846E@azulsystems.com> References: <51D9BF97-3C0D-4B93-AFD7-CD5C38E4B304@whittington.net.nz> <32DBCC01-A23E-4B87-A16D-017F9D86846E@azulsystems.com> Message-ID: <23B28788-7AA8-4E21-A552-9C8F88096FD8@whittington.net.nz> This is on a Haswell Macbook Pro: $ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz AFAIKT JDK-7184394 only dealt with using AES-NI (and some SIMD for AES/CBC) - am I missing something? cheers tim On 28/03/2014, at 9:37 pm, Ivan Krylov wrote: > Tim, > > Do you have a Haswell powered machine at your disposal? > JDK-7184394[1] should have addressed this issue > > Thanks, > > Ivan > > [1] - https://bugs.openjdk.java.net/browse/JDK-7184394 > > On 28 Mar 2014, at 01:29, Tim Whittington wrote: > >> Hi all >> >> I?ve noticed that the performance of the AES/GCM implementation in the JDK 8 SunJCE provider is very slow. >> >> On a simple micro-benchmark (standard caveats etc. etc.) encrypting 10 MB blocks of random data (not decrypt) I get the following rough throughputs: >> >> AES/ECB +UseAESIntrinsics - 600 MB/s (btw this is awesome fast for Java, up from about 300 MB/s in Java 7) >> AES/ECB -UseAESIntrinsics - 120 MB/s (again a good bump from about 90 MB/s in Java 7) >> AES/GCM - 4 MB/s >> >> 4 MB/s is pretty catastrophic (especially compared to the stellar baseline AES performance). >> >> A quick peek in a profiler reveals pretty much all the time is in GHash.blockMult()/getBit()/shift(). >> The performance of the AES/GCM mode is comparable to other pure Java implementations without table based multiplier optimisations (which typically provide speeds in the 40-60 MB/s on the same micro-benchmark). >> >> I wonder if the JDK implementation could adopt one of those approaches or (better) implement an intrinsic to speed this up (perhaps using the CLMUL interaction set when available). >> >> cheers >> tim >> >> ? >> >> java version "1.8.0" >> Java(TM) SE Runtime Environment (build 1.8.0-b132) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) >> >> Darwin 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 >> >> > From weijun.wang at oracle.com Sun Mar 30 15:27:50 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 30 Mar 2014 23:27:50 +0800 Subject: RFR 8038754: ReplayCacheTestProc test fails with timeout Message-ID: <9F30FC15-D988-49E5-AE7C-2DD91BFF165F@oracle.com> Hi Please take a review at http://cr.openjdk.java.net/~weijun/8038754/webrev.00/ Before JDK-8031003, the debug message inside native JGSS is printed out on the Java side using System.out.println(msg); but after it, it is printed on the C side using puts(msg); and no newline will be automatically added. Therefore output are all packed into one line like [GSSLibStub_acquireCred] pName=4300612336, usage=2[GSSLibStub_acquireCred] pCred=4298497488PROCISFUN:true and ReplayCacheTestProc cannot find the test result "PROCISFUN:true". The fix adds the newline char. No new test. Thanks Max From weijun.wang at oracle.com Sun Mar 30 15:34:20 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 30 Mar 2014 23:34:20 +0800 Subject: RFR 8038754: ReplayCacheTestProc test fails with timeout In-Reply-To: <9F30FC15-D988-49E5-AE7C-2DD91BFF165F@oracle.com> References: <9F30FC15-D988-49E5-AE7C-2DD91BFF165F@oracle.com> Message-ID: <36285203-3C2D-4FD4-A0BF-7CA69F8037C0@oracle.com> On Mar 30, 2014, at 23:27, Wang Weijun wrote: > Hi > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8038754/webrev.00/ > > Before JDK-8031003, the debug message inside native JGSS is printed out on the Java side using > > System.out.println(msg); > > but after it, it is printed on the C side using > > puts(msg); Sorry, it's printf. --Max > > and no newline will be automatically added. Therefore output are all packed into one line like > > [GSSLibStub_acquireCred] pName=4300612336, usage=2[GSSLibStub_acquireCred] pCred=4298497488PROCISFUN:true > > and ReplayCacheTestProc cannot find the test result "PROCISFUN:true". > > The fix adds the newline char. > > No new test. > > Thanks > Max > From weijun.wang at oracle.com Mon Mar 31 00:56:16 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 31 Mar 2014 08:56:16 +0800 Subject: RFR 8038754: ReplayCacheTestProc test fails with timeout In-Reply-To: <9F30FC15-D988-49E5-AE7C-2DD91BFF165F@oracle.com> References: <9F30FC15-D988-49E5-AE7C-2DD91BFF165F@oracle.com> Message-ID: <5825C4A9-D869-46DF-85F7-06C720E049A7@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8038754/webrev.01/ 'printf(s); printf("\n")' is now 'printf(s"\n");'. One less call, and seems an extra benefit to force /s/ being a real literal. At least it compiles now. Thanks Max On Mar 30, 2014, at 23:27, Wang Weijun wrote: > Hi > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8038754/webrev.00/ > > Before JDK-8031003, the debug message inside native JGSS is printed out on the Java side using > > System.out.println(msg); > > but after it, it is printed on the C side using > > printf(msg); > > and no newline will be automatically added. Therefore output are all packed into one line like > > [GSSLibStub_acquireCred] pName=4300612336, usage=2[GSSLibStub_acquireCred] pCred=4298497488PROCISFUN:true > > and ReplayCacheTestProc cannot find the test result "PROCISFUN:true". > > The fix adds the newline char. > > No new test. > > Thanks > Max > From Alan.Bateman at oracle.com Mon Mar 31 07:29:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 31 Mar 2014 08:29:11 +0100 Subject: RFR 8038754: ReplayCacheTestProc test fails with timeout In-Reply-To: <5825C4A9-D869-46DF-85F7-06C720E049A7@oracle.com> References: <9F30FC15-D988-49E5-AE7C-2DD91BFF165F@oracle.com> <5825C4A9-D869-46DF-85F7-06C720E049A7@oracle.com> Message-ID: <53391947.30509@oracle.com> On 31/03/2014 01:56, Wang Weijun wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8038754/webrev.01/ > > 'printf(s); printf("\n")' is now 'printf(s"\n");'. One less call, and seems an extra benefit to force /s/ being a real literal. At least it compiles now. > > Thanks > Max > Good sleuthing, the change looks good to me. It's a reminder that it's important that it's good to run tests on all platforms when making changes to the native code. -Alan From vincent.x.ryan at oracle.com Mon Mar 31 10:42:27 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 31 Mar 2014 11:42:27 +0100 Subject: Review Request for JDK-8030114: [parfait] warnings from b119 for jdk.src.share.native.sun.security.smartcardio: JNI exception pending In-Reply-To: <5317C727.6090302@oracle.com> References: <52FD63BE.9080004@oracle.com> <52FE28F7.5010408@redhat.com> <5307F235.4030401@oracle.com> <5317C727.6090302@oracle.com> Message-ID: Your latest webrev looks good. Thanks. On 6 Mar 2014, at 00:53, Valerie (Yu-Ching) Peng wrote: > > I still need a reviewer for integrating the changes for 8030114... Any taker? > Thanks, > Valerie > > On 02/21/14 16:41, Valerie (Yu-Ching) Peng wrote: >> >> Good points, I have updated the webrev accordingly. >> The current callers of Java_sun_security_smartcardio_PCSC_SCardGetStatusChange seems to only pass 1 reader at a time, so I just moved the free call to a separate loop as part of cleanup. >> >> Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8030114/webrev.01/ >> Thanks, >> Valerie >> >> On 02/14/14 06:32, Florian Weimer wrote: >>> On 02/14/2014 01:30 AM, Valerie (Yu-Ching) Peng wrote: >>> >>>> Can someone please review the fixes which checks for pending exceptions >>>> in native code "pcsc.c"? >>>> The fix is straightforward for all except the changes under >>>> Java_sun_security_smartcardio_PCSC_SCardGetStatusChange(...) method >>>> which is somewhat complicated due to the need to free up memories. >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8030114/webrev.00/ >>> >>> It seems to me there is a slight behavioral change in Java_sun_security_smartcardio_PCSC_SCardStatus. I think the ArrayIndexOutofBoundsException is no longer thrown if the status array is too short. >>> >>> The logic in Java_sun_security_smartcardio_PCSC_SCardGetStatusChange appears to be correct, but I wonder if it would be clearer to use calloc for allocation and avoid the interlocked i/j/k loop counters, at the cost of calling free on a few NULL pointers. >>> >> >> > From bc at whittington.net.nz Thu Mar 27 21:28:37 2014 From: bc at whittington.net.nz (Tim Whittington) Date: Thu, 27 Mar 2014 21:28:37 -0000 Subject: Very slow performance of AES/GCM in JDK 8 SunJCE provider Message-ID: <9F85D762-3C7D-4C92-8E80-4E80A744A7F9@whittington.net.nz> Hi all I?ve noticed that the performance of the AES/GCM implementation in the JDK 8 SunJCE provider is very slow. On a simple micro-benchmark (standard caveats etc. etc.) encrypting 10 MB blocks of random data (not decrypt) I get the following rough throughputs: AES/ECB +UseAESIntrinsics - 600 MB/s (btw this is awesome fast for Java, up from about 300 MB/s in Java 7) AES/ECB -UseAESIntrinsics - 120 MB/s (again a good bump from about 90 MB/s in Java 7) AES/GCM - 4 MB/s 4 MB/s is pretty catastrophic (especially compared to the stellar baseline AES performance). A quick peek in a profiler reveals pretty much all the time is in GHash.blockMult()/getBit()/shift(). The performance of the AES/GCM mode is comparable to other pure Java implementations without table based multiplier optimisations (which typically provide speeds in the 40-60 MB/s on the same micro-benchmark). I wonder if the JDK implementation could adopt one of those approaches or (better) implement an intrinsic to speed this up (perhaps using the CLMUL interaction set when available). cheers tim ? java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) Darwin 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64