From bruno at distributedmatter.net Sun Feb 2 14:03:55 2014 From: bruno at distributedmatter.net (Bruno Harbulot) Date: Sun, 2 Feb 2014 22:03:55 +0000 Subject: Windows-ROOT keystore merging aliases (and hiding certificates) Message-ID: Hello, It seems there may be a bug in the Windows-ROOT store implementation [1], which prevents a number of certificates from being used. For example, a Windows 7 machine with the default certificates list should have the "UTN-USERFirst-Hardware" CA certificate. However, when listing the contents of the "Windows-ROOT" keystore, it cannot be found. I haven't looked into the source code for this implementation, but I think this is due to the fact that the certificate's "Friendly Name" (in Windows terminology) is used as the alias name in the keystore. Unfortunately, this friendly name is not unique, so some certificates would be overwritten in the map implemented in the keystore (or a similar data structure, I presume). Indeed, the certificate with "CN = UTN-USERFirst-Object" and the one with "CN = UTN-USERFirst-Hardware" both use the "USERTrust" friendly name (so do other UTN certificates). If you change the friendly name manually to something different, it is then visible via the keystore. To try this, run mmc.exe, add the "Certificates" snap-in for the current user, open "UTN-USERFirst-Hardware" in the "Trusted Root Certification Authorities" list, and edit its "Friendly Name" in the details panel. By listing all the aliases in the Windows-ROOT keystore, looking for duplicate names and comparing with the number in the Windows list, it appears there are about 60 certificates hidden this way and unusable (22 aliases that have multiple certificates). Perhaps a way to fix this bug would be to add a number to the alias name if the friendly name has already been seen, when loading the Windows store. Best wishes, Bruno. [1]: http://www.oracle.com/technetwork/articles/javase/security-137537.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140202/c490aa76/attachment.html From bruno at distributedmatter.net Sun Feb 2 14:59:18 2014 From: bruno at distributedmatter.net (Bruno Harbulot) Date: Sun, 2 Feb 2014 22:59:18 +0000 Subject: Windows-ROOT keystore merging aliases (and hiding certificates) In-Reply-To: References: Message-ID: Sorry, I hadn't noticed there were already a few bug entries on this topic [2]. Perhaps one way to guarantee uniqueness of the alias would be to use the certificate's thumbprint. This would also be consistent with the way certificates are identified in some Windows native tools (such as "netsh http add sslcert" [3]). It's less human friendly, but it would certainly prevent this type of problems. (This wouldn't necessarily solve the problem of certificates added to the store with an alias given by the user.) Best wishes, Bruno. [2]: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6483657 [3]: http://msdn.microsoft.com/en-us/library/ms733791%28v=vs.110%29.aspx On Sun, Feb 2, 2014 at 10:03 PM, Bruno Harbulot wrote: > Hello, > > It seems there may be a bug in the Windows-ROOT store implementation [1], > which prevents a number of certificates from being used. > > For example, a Windows 7 machine with the default certificates list should > have the "UTN-USERFirst-Hardware" CA certificate. However, when listing the > contents of the "Windows-ROOT" keystore, it cannot be found. > > I haven't looked into the source code for this implementation, but I think > this is due to the fact that the certificate's "Friendly Name" (in Windows > terminology) is used as the alias name in the keystore. Unfortunately, this > friendly name is not unique, so some certificates would be overwritten in > the map implemented in the keystore (or a similar data structure, I > presume). > > Indeed, the certificate with "CN = UTN-USERFirst-Object" and the one with > "CN = UTN-USERFirst-Hardware" both use the "USERTrust" friendly name (so do > other UTN certificates). > > If you change the friendly name manually to something different, it is > then visible via the keystore. To try this, run mmc.exe, add the > "Certificates" snap-in for the current user, open "UTN-USERFirst-Hardware" > in the "Trusted Root Certification Authorities" list, and edit its > "Friendly Name" in the details panel. > > By listing all the aliases in the Windows-ROOT keystore, looking for > duplicate names and comparing with the number in the Windows list, it > appears there are about 60 certificates hidden this way and unusable (22 > aliases that have multiple certificates). > > Perhaps a way to fix this bug would be to add a number to the alias name > if the friendly name has already been seen, when loading the Windows store. > > Best wishes, > > Bruno. > > > [1]: > http://www.oracle.com/technetwork/articles/javase/security-137537.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140202/18b11f8c/attachment.html From anthony.scarpino at oracle.com Mon Feb 3 10:24:46 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 03 Feb 2014 10:24:46 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker Message-ID: <52EFDEEE.7090406@oracle.com> 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 Alan.Bateman at oracle.com Tue Feb 4 07:02:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Feb 2014 15:02:26 +0000 Subject: 8031586: Check jdk/src/*/native/com/sun/security/auth/module for pending JNI exceptions Message-ID: <52F10102.10500@oracle.com> The native methods for the JDK-specific API to JAAS don't handle handle errors and JNI exceptions everywhere. I'd like to fix some of these with the following patch: http://cr.openjdk.java.net/~alanb/8031586/webrev/ A couple of things to note: - The existing code throws IllegalArgumentException for cases where GetFieldID fails. I've cleaned this up a bit but it might be simpler to just get rid of this and let the NoSuchFieldError or other error be thrown, any opinions? I should add that at least in SolarisSystem.getSolarisInfo then the exception messages weren't actually useful because they are all the same. I can only assume that the original author wanted a useful exception thrown when the java and native code is out of sync. - In NTSystem.getCurrent it requires a lot of work to set systemError to true when there is an error. I decided the simplest thing here is to just removing the not-very-useful message printed to stdout. - As the JAAS library is not linked to libjava then it means we can't use the JNU_* functions defined in jni_util.c. We deliberately removed this dependency some time ago as part of our modularity efforts. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140204/2253425e/attachment.html From gnu.andrew at redhat.com Tue Feb 4 07:48:15 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 4 Feb 2014 10:48:15 -0500 (EST) Subject: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library In-Reply-To: <517858AF.2070503@oracle.com> References: <1362133828.2303.18.camel@localhost> <5177BC6A.7030308@redhat.com> <517858AF.2070503@oracle.com> Message-ID: <468091249.4123477.1391528895077.JavaMail.root@redhat.com> ----- Original Message ----- > > Won't this change break systems which don't have libpcsclite.so.1? > Changes like this need to be thought through. What happens when > libpcsclite.so.2 comes out? > As for API changes, shouldn't there be some compatibility requirement on > APIs as libpcsclite.so evolves? > Valerie > > On 04/24/13 04:05, Florian Weimer wrote: > > On 03/01/2013 11:30 AM, Severin Gehwolf wrote: > >> Hi, > >> > >> The bug for this review request is at: > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142 > >> > >> In PlatformPCSC.java unversioned native libraries are loaded by default > >> if no system property is specified. This could lead to a JVM crash if > >> the API of the native library changes, but the Java code still relies on > >> old API. The fix is to load versioned shared libraries instead. > > > > Hmm. Why doesn't the "j2pcsc" library link against the right version > > of libpcsclite.so? > > > > We've just shipped the patch in IcedTea 2.4.5 [0] but I see the attempt to upstream it seems to have died out. 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. Are there further issues with this patch or am I ok to push it upstream? Severin works for Red Hat, so the corporate OCA applies. [0] http://bitly.com/1d7AJHj Thanks, -- 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 vincent.x.ryan at oracle.com Tue Feb 4 08:18:33 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 04 Feb 2014 16:18:33 +0000 Subject: [9] RFR 8028727: warnings from b116 for jdk.src.share.native.sun.security.ec: JNI pending exceptions Message-ID: <52F112D9.5040309@oracle.com> Please review this patch for better handling of JNI pending exceptions in the ECC native code: Webrev: http://cr.openjdk.java.net/~vinnie/8028727/webrev.00/ The patch examines the return code from JNI calls to check whether an exception is already pending. If so then it cleans up and returns. Thanks. From chris.hegarty at oracle.com Tue Feb 4 08:24:04 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 04 Feb 2014 16:24:04 +0000 Subject: 8031586: Check jdk/src/*/native/com/sun/security/auth/module for pending JNI exceptions In-Reply-To: <52F10102.10500@oracle.com> References: <52F10102.10500@oracle.com> Message-ID: <52F11424.3030605@oracle.com> As far as the source changes are concerned, then they look good to me. -Chris. On 02/04/2014 03:02 PM, Alan Bateman wrote: > > The native methods for the JDK-specific API to JAAS don't handle handle > errors and JNI exceptions everywhere. I'd like to fix some of these with > the following patch: > > http://cr.openjdk.java.net/~alanb/8031586/webrev/ > > A couple of things to note: > > - The existing code throws IllegalArgumentException for cases where > GetFieldID fails. I've cleaned this up a bit but it might be simpler to > just get rid of this and let the NoSuchFieldError or other error be > thrown, any opinions? I should add that at least in > SolarisSystem.getSolarisInfo then the exception messages weren't > actually useful because they are all the same. I can only assume that > the original author wanted a useful exception thrown when the java and > native code is out of sync. > > - In NTSystem.getCurrent it requires a lot of work to set systemError to > true when there is an error. I decided the simplest thing here is to > just removing the not-very-useful message printed to stdout. > > - As the JAAS library is not linked to libjava then it means we can't > use the JNU_* functions defined in jni_util.c. We deliberately removed > this dependency some time ago as part of our modularity efforts. > > -Alan From Alan.Bateman at oracle.com Tue Feb 4 08:39:51 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Feb 2014 16:39:51 +0000 Subject: Fwd: [9] RFR 8028727: warnings from b116 for jdk.src.share.native.sun.security.ec: JNI pending exceptions In-Reply-To: <52F115F5.3070506@oracle.com> References: <52F112D9.5040309@oracle.com> <52F115F5.3070506@oracle.com> Message-ID: <52F117D7.2040200@oracle.com> On 04/02/2014 16:31, Vincent Ryan wrote: > : > > Please review this patch for better handling of JNI pending exceptions > in the ECC native code: > > Webrev: http://cr.openjdk.java.net/~vinnie/8028727/webrev.00/ > > The patch examines the return code from JNI calls to check whether an > exception is already pending. If so then it cleans up and returns. This looks to good, I just wonder about the calls GetByteArrayRegion as they can potentially fail with NULL/ArrayIndexOutOfBoundsException. It would be a bug if we pass indexes that are out of range but it might be worth checking those too. -Alan From vincent.x.ryan at oracle.com Tue Feb 4 09:13:12 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 04 Feb 2014 17:13:12 +0000 Subject: Fwd: [9] RFR 8028727: warnings from b116 for jdk.src.share.native.sun.security.ec: JNI pending exceptions In-Reply-To: <52F117D7.2040200@oracle.com> References: <52F112D9.5040309@oracle.com> <52F115F5.3070506@oracle.com> <52F117D7.2040200@oracle.com> Message-ID: <52F11FA8.2060701@oracle.com> Thanks Alan. In this case, each call to GetByteArrayRegion is preceded by a call to GetArrayLength so passing an array index that is out of bounds cannot occur. On 04/02/2014 16:39, Alan Bateman wrote: > On 04/02/2014 16:31, Vincent Ryan wrote: >> : >> >> Please review this patch for better handling of JNI pending exceptions >> in the ECC native code: >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8028727/webrev.00/ >> >> The patch examines the return code from JNI calls to check whether an >> exception is already pending. If so then it cleans up and returns. > This looks to good, I just wonder about the calls GetByteArrayRegion as > they can potentially fail with NULL/ArrayIndexOutOfBoundsException. It > would be a bug if we pass indexes that are out of range but it might be > worth checking those too. > > -Alan From sean.mullan at oracle.com Tue Feb 4 11:49:28 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 04 Feb 2014 14:49:28 -0500 Subject: Security Policy with denying rules In-Reply-To: References: Message-ID: <52F14448.5070902@oracle.com> Hi Ondrej, Thanks for sharing the information about your project. If you have a copy of the book "Inside Java 2 Platform Security" [1], there is a section (5.1.5) discussing the rationale for not including support for "negative" permissions in the Java Security model. The section talks about the reasons for not supporting them, particularly that there can never be any conflict between positive permissions. This makes it simpler to implement and also safer since there is no need to check for conflicts, and there is less of an unknown factor in what permissions are actually being granted. The book also discusses another potential solution whereby you could preprocess the negative permissions into a policy file containing only positive permissions. Requests for negative permissions come up every now and then, so I think it is useful to discuss it some more. Anyway, I don't necessarily want to discourage you but I was just wondering if you have thought about any of these issues. Thanks, Sean [1] http://www.amazon.com/Inside-Java%C2%BF-Platform-Security-Implementation/dp/0201787911 On 01/17/2014 03:39 AM, Ond?ej Luk?? wrote: > Hi, > I've implemented Java Security Manager and Policy for using denying > rules and I think that maybe someone will be interested in it. Standard > Java Policy [1] uses only granting permissions and there are cases when > denying rules are more comfortable than granting rules. I would like to > know your opinion and get some feedback if you'll be interested. Project > is called Prograde (Policy Rules Of GRanting And DEnying) and you can > use it as maven artifact: > > > net.sourceforge.pro-grade > pro-grade > 1.0 > > > Project is also available through github [2] and some tests are in > progradeTests project [3]. > > In the README files of these two github projects is some information > about using policy with denying rules. Usage is similar as with standard > policy, but you can write also deny entry (keyword "deny") instead of > grant. There is a new entry named "priority" which is set to grant or > deny value - it says whether grant or deny rule is used if they are in > conflict. Some examples of policy files are used in [3]. > > I think that the main advantage of this type of policy rules and > Prograde project is simplification of testing. Sometimes you want to > know what behavior will your application have in case that some specific > permission isn't granted. In this case you need to grant everything > except that permission, so a denying rule is the best option. > > There are also some imperfections, but I think that they are not so > important: > - Prograde is not able to work with general expansion [4]. (property > expansion works fine) > - Path used in codebase entry must contain only a-z, A-Z, 0-9 and some > symbols defined in encodeSpecialCharacters protected method of > net.sourceforge.prograde.policy.ProgradePolicyFile class. > > I am planning to fix it in future releases. > > I hope Prograde will be helpful for somebody and I'll be happy for every > feedback. > > Best regards, > Ondrej Lukas > > [1] > http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html > [2] https://github.com/olukas/pro-grade > [3] https://github.com/olukas/progradeTests > [4] > http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#GeneralExp From sean.mullan at oracle.com Wed Feb 5 06:37:14 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 05 Feb 2014 09:37:14 -0500 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <52EA1196.4080702@oracle.com> References: <52EA1196.4080702@oracle.com> Message-ID: <52F24C9A.5000207@oracle.com> 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 vincent.x.ryan at oracle.com Wed Feb 5 07:00:36 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 5 Feb 2014 15:00:36 +0000 Subject: [9] RFR 8011983: False positive: unportable format string argument mismatch in jdk/src/windows/native/com/sun/security/auth/module/nt.c Message-ID: <1B982FB7-26D5-4122-AED4-3B2F52DD6119@oracle.com> Hello, I?d like to make the following trivial fix to a JAAS function in native code on Windows. It simply corrects a printf statement to expect a pointer: diff --git a/src/windows/native/com/sun/security/auth/module/nt.c b/src/windows/native/com/sun/security/auth/module/nt.c --- a/src/windows/native/com/sun/security/auth/module/nt.c +++ b/src/windows/native/com/sun/security/auth/module/nt.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -589,7 +589,8 @@ BOOL getImpersonationToken(PHANDLE imper CloseHandle(dupToken); if (debug) { - printf(" [getImpersonationToken] token = %d\n", *impersonationToken); + printf(" [getImpersonationToken] token = %p\n", + (void *)*impersonationToken); } return TRUE; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140205/8ad3aa93/attachment.html From vincent.x.ryan at oracle.com Wed Feb 5 09:06:28 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 5 Feb 2014 17:06:28 +0000 Subject: [9] RFR 8025669: [parfait] warning from b62 for jdk.src.solaris.native.com.sun.security.auth.module: memory leak Message-ID: <50057FF4-BC71-4FE0-8119-30AE50C12DC6@oracle.com> Please review this fix for a potential memory leak in JAAS native code on Solaris: Webrev: http://cr.openjdk.java.net/~vinnie/8025669/webrev.00/ The fix ensures that the calloc?d memory always gets freed. Thanks. From Alan.Bateman at oracle.com Wed Feb 5 09:13:58 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Feb 2014 17:13:58 +0000 Subject: [9] RFR 8025669: [parfait] warning from b62 for jdk.src.solaris.native.com.sun.security.auth.module: memory leak In-Reply-To: <50057FF4-BC71-4FE0-8119-30AE50C12DC6@oracle.com> References: <50057FF4-BC71-4FE0-8119-30AE50C12DC6@oracle.com> Message-ID: <52F27156.1040409@oracle.com> On 05/02/2014 17:06, Vincent Ryan wrote: > Please review this fix for a potential memory leak in JAAS native code on Solaris: > > Webrev: http://cr.openjdk.java.net/~vinnie/8025669/webrev.00/ > > The fix ensures that the calloc?d memory always gets freed. > Thanks. This looks okay to me. -Alan. From chris.hegarty at oracle.com Wed Feb 5 09:14:47 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 5 Feb 2014 17:14:47 +0000 Subject: [9] RFR 8025669: [parfait] warning from b62 for jdk.src.solaris.native.com.sun.security.auth.module: memory leak In-Reply-To: <50057FF4-BC71-4FE0-8119-30AE50C12DC6@oracle.com> References: <50057FF4-BC71-4FE0-8119-30AE50C12DC6@oracle.com> Message-ID: <3FE10168-EEBB-47E4-A927-9AE9EB097C6F@oracle.com> Looks good to me Vincent. -Chris. On 5 Feb 2014, at 17:06, Vincent Ryan wrote: > Please review this fix for a potential memory leak in JAAS native code on Solaris: > > Webrev: http://cr.openjdk.java.net/~vinnie/8025669/webrev.00/ > > The fix ensures that the calloc?d memory always gets freed. > Thanks. From michael.x.mcmahon at oracle.com Thu Feb 6 01:57:20 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 06 Feb 2014 09:57:20 +0000 Subject: RFR: 8031588 warnings from b03 for jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending Message-ID: <52F35C80.4030309@oracle.com> Hi, This is a fix adding some checks for pending exceptions in the JGSS native code. All of these cases could only practically happen in case of OutOfMemoryError. There are a couple of places where the JNI spec isn't completely clear whether the exception will be thrown. In those cases, we check for an exception and throw OOME if none is pending. http://cr.openjdk.java.net/~michaelm/8031588/webrev.1/ Thanks, Michael From vincent.x.ryan at oracle.com Thu Feb 6 03:17:15 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 6 Feb 2014 11:17:15 +0000 Subject: [9] RFR 8033757: Redo JDK-8011983 (due to bad merge with JDK-8031586) Message-ID: <833E0946-E61B-4CE7-BE04-F4814AF5304C@oracle.com> My fix for JDK-8011983 trampled on the fix for JDK-8031568 in: jdk/src/windows/native/com/sun/security/auth/module/nt.c This change merges both of those changes. Webrev: http://cr.openjdk.java.net/~vinnie/8033757/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140206/583b2a63/attachment.html From Alan.Bateman at oracle.com Thu Feb 6 03:23:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Feb 2014 11:23:52 +0000 Subject: [9] RFR 8033757: Redo JDK-8011983 (due to bad merge with JDK-8031586) In-Reply-To: <833E0946-E61B-4CE7-BE04-F4814AF5304C@oracle.com> References: <833E0946-E61B-4CE7-BE04-F4814AF5304C@oracle.com> Message-ID: <52F370C8.9010803@oracle.com> On 06/02/2014 11:17, Vincent Ryan wrote: > My fix for JDK-8011983 trampled on the fix for JDK-8031568 in: > jdk/src/windows/native/com/sun/security/auth/module/nt.c > > This change merges both of those changes. > > Webrev: http://cr.openjdk.java.net/~vinnie/8033757/webrev.00/ > > Thanks for fixing this up, looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140206/1877b467/attachment.html From henry.jen at oracle.com Thu Feb 6 10:34:09 2014 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Thu, 06 Feb 2014 18:34:09 +0000 Subject: hg: jdk8/tl/jdk: 8033590: java.util.Comparator::thenComparing has unnecessary type restriction Message-ID: <20140206183432.A898562A7F@hg.openjdk.java.net> Changeset: 7534523b4174 Author: henryjen Date: 2014-02-06 10:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7534523b4174 8033590: java.util.Comparator::thenComparing has unnecessary type restriction Reviewed-by: psandoz ! src/share/classes/java/util/Comparator.java ! test/java/util/Comparator/TypeTest.java From sean.mullan at oracle.com Thu Feb 6 12:34:34 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 06 Feb 2014 15:34:34 -0500 Subject: RFR: 8031588 warnings from b03 for jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending In-Reply-To: <52F35C80.4030309@oracle.com> References: <52F35C80.4030309@oracle.com> Message-ID: <52F3F1DA.9080909@oracle.com> Looks fine to me, Michael. Please add a noreg label to the bug. --Sean On 02/06/2014 04:57 AM, Michael McMahon wrote: > Hi, > > This is a fix adding some checks for pending exceptions in the JGSS > native code. > All of these cases could only practically happen in case of > OutOfMemoryError. > There are a couple of places where the JNI spec isn't completely clear > whether > the exception will be thrown. In those cases, we check for an exception > and throw > OOME if none is pending. > > http://cr.openjdk.java.net/~michaelm/8031588/webrev.1/ > > Thanks, > Michael From Alan.Bateman at oracle.com Mon Feb 10 03:47:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Feb 2014 11:47:17 +0000 Subject: 8034043/8034026 - clean up of a few native code issues to align things with modules Message-ID: <52F8BC45.8040202@oracle.com> This patch is a clean-up to fix a number issues that arise trying to align native libraries with possible future modules. The first is the preferences API where the native code is currently linked into libjava for Windows/Linux/Solaris and libosx on OS X. This patch moves the native sources down to a prefs sub-directory (to follow long standing conventions) and links the resulting code into a new libprefs (all platforms). The rational for this is that the preferences API is a reasonable candidate for a module and it is odd to have its native methods in libraries that are likely to be in other modules. See also JDK-8034074 [1] for an opportunity for anyone so inclined to eliminate some of this code. The logging API is another case where it has native code linked into libjava. It's for the somewhat obscure case where the VM is running as a setuid process and the FileHandler is configured to include the user's home directory. For now, I've moved this to sun.misc.VM on the assumption that there may be other places where we need to know if we are running with setuid. We have to do a general clean-up of sun.misc and that may be the time to move it to a better home. In the security area then the OS X implementation of the native methods for sun.security.krb5.SCDynamicStoreConfig were put in the wrong location by the OS X port (src/macosx/native/java/util???) and also linked to the wrong library (libosx.dylib). This patch moves the source and links it into existing libosxkrb5.dylib along with the other OS X specific Kerberos code. This is code that is not exercised by the tests as it requires Open Directory to be configured. Thanks to Max Wang for trying out a preliminary version of this patch to ensure that it continues to work. One comment on SecurityLibraries.gmk is it's using hardcoded paths to the OS X frameworks. Erik Joelsson told me that this is on the build group's list of things to fix up in the future. The webrev with the proposed changes is here: http://cr.openjdk.java.net/~alanb/8034043%2b8034026/webrev/ -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8034074 From rob.mckenna at oracle.com Mon Feb 10 06:50:15 2014 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 10 Feb 2014 14:50:15 +0000 Subject: hg: jdk8/tl/jdk: 7152892: some jtreg tests fail with permission denied Message-ID: <20140210145247.DD74462B24@hg.openjdk.java.net> Changeset: da4b0962ad11 Author: robm Date: 2014-02-10 14:35 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11 7152892: some jtreg tests fail with permission denied Reviewed-by: coffeys ! test/java/lang/ClassLoader/Assert.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/util/zip/ZipFile/ReadZip.java ! test/sun/net/www/protocol/jar/jarbug/run.sh From valerie.peng at oracle.com Mon Feb 10 15:04:29 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 10 Feb 2014 15:04:29 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <52EFDEEE.7090406@oracle.com> References: <52EFDEEE.7090406@oracle.com> Message-ID: <52F95AFD.6090303@oracle.com> 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. Also, now that every P11Cipher "object" has its own session pool, will this have any impact on the overall 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. 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 Mon Feb 10 16:30:20 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 10 Feb 2014 16:30:20 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <52F95AFD.6090303@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> Message-ID: <52F96F1C.7040405@oracle.com> 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. > > 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. 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 weijun.wang at oracle.com Tue Feb 11 04:27:44 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 11 Feb 2014 20:27:44 +0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c Message-ID: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> Hi All I didn't attend the parfait day last week, but a new one is coming. Please review my fix at http://cr.openjdk.java.net/~weijun/8034033/webrev.00/ Thanks Max From fweimer at redhat.com Tue Feb 11 05:17:14 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 11 Feb 2014 14:17:14 +0100 Subject: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library In-Reply-To: <468091249.4123477.1391528895077.JavaMail.root@redhat.com> References: <1362133828.2303.18.camel@localhost> <5177BC6A.7030308@redhat.com> <517858AF.2070503@oracle.com> <468091249.4123477.1391528895077.JavaMail.root@redhat.com> Message-ID: <52FA22DA.1020004@redhat.com> 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. -- Florian Weimer / Red Hat Product Security Team From mark.reinhold at oracle.com Tue Feb 11 09:42:40 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 11 Feb 2014 09:42:40 -0800 Subject: Changeset rolled back: jdk8/tl/jdk: 7152892: some jtreg tests fail with permission denied Message-ID: <20140211094240.954088@eggemoggin.niobe.net> This changeset was erroneously pushed to jdk8/tl/jdk: Changeset: da4b0962ad11 Author: robm Date: 2014-02-10 14:35 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11 7152892: some jtreg tests fail with permission denied Reviewed-by: coffeys ! test/java/lang/ClassLoader/Assert.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/util/zip/ZipFile/ReadZip.java ! test/sun/net/www/protocol/jar/jarbug/run.sh It has been rolled back on the server and blacklisted in jcheck. If you have a clone of this repository then either strip this changeset or destroy the repository and re-clone it. - Mark From lana.steuck at oracle.com Tue Feb 11 13:40:10 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:10 +0000 Subject: hg: jdk8/tl/corba: 7 new changesets Message-ID: <20140211214024.5EA1E62B9A@hg.openjdk.java.net> Changeset: 18c4d03cf516 Author: katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18c4d03cf516 Added tag jdk8-b125 for changeset 7b45151c7a05 ! .hgtags Changeset: 8ceb68fd9e10 Author: katleman Date: 2014-01-22 14:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8ceb68fd9e10 Merge ! .hgtags Changeset: cfa04e69b115 Author: katleman Date: 2014-01-24 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cfa04e69b115 Added tag jdk8-b126 for changeset 8ceb68fd9e10 ! .hgtags Changeset: b8c71dae0557 Author: lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b8c71dae0557 Merge Changeset: 113e7569b49b Author: katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/113e7569b49b Added tag jdk8-b127 for changeset b8c71dae0557 ! .hgtags Changeset: 5c72d74c6805 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5c72d74c6805 Added tag jdk8-b128 for changeset 113e7569b49b ! .hgtags Changeset: eea0d7dfcbe2 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/eea0d7dfcbe2 Added tag jdk8-b129 for changeset 5c72d74c6805 ! .hgtags From lana.steuck at oracle.com Tue Feb 11 13:40:17 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:17 +0000 Subject: hg: jdk8/tl/langtools: 7 new changesets Message-ID: <20140211214140.425E862B9E@hg.openjdk.java.net> Changeset: 9a4dbfe11ed1 Author: katleman Date: 2014-01-22 12:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9a4dbfe11ed1 Added tag jdk8-b125 for changeset 436176151e85 ! .hgtags Changeset: ba24b6304362 Author: katleman Date: 2014-01-22 14:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ba24b6304362 Merge ! .hgtags Changeset: 305b97f4651b Author: katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/305b97f4651b Added tag jdk8-b126 for changeset ba24b6304362 ! .hgtags Changeset: bb69217ed812 Author: lana Date: 2014-01-29 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb69217ed812 Merge Changeset: 09cdd3b493c0 Author: katleman Date: 2014-01-30 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09cdd3b493c0 Added tag jdk8-b127 for changeset bb69217ed812 ! .hgtags Changeset: 8fe7202d3c38 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8fe7202d3c38 Added tag jdk8-b128 for changeset 09cdd3b493c0 ! .hgtags Changeset: 9d81ae1c417a Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d81ae1c417a Added tag jdk8-b129 for changeset 8fe7202d3c38 ! .hgtags From lana.steuck at oracle.com Tue Feb 11 13:40:13 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:13 +0000 Subject: hg: jdk8/tl/jaxws: 7 new changesets Message-ID: <20140211214119.DF23C62B9C@hg.openjdk.java.net> Changeset: c0040f0b75e2 Author: katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c0040f0b75e2 Added tag jdk8-b125 for changeset ef71ecbcd7bc ! .hgtags Changeset: 7193a007a159 Author: katleman Date: 2014-01-22 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7193a007a159 Merge ! .hgtags Changeset: 3f682f2ea376 Author: katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3f682f2ea376 Added tag jdk8-b126 for changeset 7193a007a159 ! .hgtags Changeset: 8e46fe36e175 Author: lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8e46fe36e175 Merge Changeset: de172acc095b Author: katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/de172acc095b Added tag jdk8-b127 for changeset 8e46fe36e175 ! .hgtags Changeset: aabc90596123 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/aabc90596123 Added tag jdk8-b128 for changeset de172acc095b ! .hgtags Changeset: 4195c0956930 Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/4195c0956930 Added tag jdk8-b129 for changeset aabc90596123 ! .hgtags From lana.steuck at oracle.com Tue Feb 11 13:40:17 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:17 +0000 Subject: hg: jdk8/tl/jaxp: 7 new changesets Message-ID: <20140211214123.063DA62B9D@hg.openjdk.java.net> Changeset: 6a5af8a36aaf Author: katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6a5af8a36aaf Added tag jdk8-b125 for changeset 83bb924238f8 ! .hgtags Changeset: 390cc275c04c Author: katleman Date: 2014-01-22 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/390cc275c04c Merge ! .hgtags Changeset: 573c261a2025 Author: katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/573c261a2025 Added tag jdk8-b126 for changeset 390cc275c04c ! .hgtags Changeset: b68cdb63a70b Author: lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b68cdb63a70b Merge Changeset: b1839922f10c Author: katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b1839922f10c Added tag jdk8-b127 for changeset b68cdb63a70b ! .hgtags Changeset: b7752cea7c81 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b7752cea7c81 Added tag jdk8-b128 for changeset b1839922f10c ! .hgtags Changeset: 0cb0cd015218 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0cb0cd015218 Added tag jdk8-b129 for changeset b7752cea7c81 ! .hgtags From lana.steuck at oracle.com Tue Feb 11 13:40:24 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:24 +0000 Subject: hg: jdk8/tl/nashorn: 8 new changesets Message-ID: <20140211214101.632E862B9B@hg.openjdk.java.net> Changeset: d336209a0e45 Author: katleman Date: 2014-01-22 12:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d336209a0e45 Added tag jdk8-b125 for changeset 7346abe2ea03 ! .hgtags Changeset: 095263db862d Author: katleman Date: 2014-01-22 14:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/095263db862d Merge ! .hgtags Changeset: e2522604c7c9 Author: katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e2522604c7c9 Added tag jdk8-b126 for changeset 095263db862d ! .hgtags Changeset: fdfbb745caf0 Author: lana Date: 2014-01-29 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fdfbb745caf0 Merge Changeset: 7dfde83426d1 Author: katleman Date: 2014-01-30 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7dfde83426d1 Added tag jdk8-b127 for changeset fdfbb745caf0 ! .hgtags Changeset: 73cbad0c5d28 Author: lana Date: 2014-01-31 13:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/73cbad0c5d28 Merge Changeset: 9cc3fd32fbab Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9cc3fd32fbab Added tag jdk8-b128 for changeset 73cbad0c5d28 ! .hgtags Changeset: f87eba70e9ee Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f87eba70e9ee Added tag jdk8-b129 for changeset 9cc3fd32fbab ! .hgtags From lana.steuck at oracle.com Tue Feb 11 13:40:17 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:17 +0000 Subject: hg: jdk8/tl/hotspot: 23 new changesets Message-ID: <20140211214227.12C4F62B9F@hg.openjdk.java.net> Changeset: 16e0c6c84a91 Author: amurillo Date: 2014-01-13 16:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16e0c6c84a91 8031553: new hotspot build - hs25-b67 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 12ad8db39f76 Author: roland Date: 2014-01-14 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12ad8db39f76 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a Summary: C1 generates code to encode compressed oop into tmp register before runtime call for patching where GC may happen Reviewed-by: iveresov, twisti, kvn Contributed-by: mgerdin ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 8b81451dc7f7 Author: twisti Date: 2014-01-16 16:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b81451dc7f7 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 3585183c191a Author: amurillo Date: 2014-01-17 20:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3585183c191a Merge Changeset: 5df2666e4573 Author: amurillo Date: 2014-01-17 20:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5df2666e4573 Added tag hs25-b67 for changeset 3585183c191a ! .hgtags Changeset: 55ff9170e27d Author: katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55ff9170e27d Added tag jdk8-b125 for changeset df333ee12bba ! .hgtags Changeset: c8218f1072a0 Author: katleman Date: 2014-01-22 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8218f1072a0 Merge ! .hgtags Changeset: 9a11d5e679cf Author: katleman Date: 2014-01-24 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a11d5e679cf Added tag jdk8-b126 for changeset c8218f1072a0 ! .hgtags Changeset: c2106608358b Author: amurillo Date: 2014-01-17 20:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c2106608358b 8032015: new hotspot build - hs25-b68 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 709018897c81 Author: vlivanov Date: 2014-01-23 01:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/709018897c81 8031695: CHA ignores default methods during analysis leading to incorrect code generation Reviewed-by: jrose, acorn, hseigel, lfoltan ! src/share/vm/code/dependencies.cpp + test/compiler/inlining/DefaultAndConcreteMethodsCHA.java Changeset: f970454708b8 Author: iveresov Date: 2014-01-17 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f970454708b8 8032207: C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size Summary: Fix the sizing of loadUS2L_immI16 and loadI2L_immI Reviewed-by: kvn, azeemj ! src/cpu/sparc/vm/sparc.ad + test/compiler/codegen/LoadWithMask.java Changeset: 984401824c5e Author: iveresov Date: 2014-01-21 20:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/984401824c5e 8031743: C2: loadI2L_immI broken for negative memory values Summary: Restrict loadI2L_imm optimizations to positive values of mask Reviewed-by: kvn, dlong ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + test/compiler/codegen/LoadWithMask2.java Changeset: d45454002494 Author: amurillo Date: 2014-01-23 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d45454002494 Merge Changeset: 2c564e329c87 Author: amurillo Date: 2014-01-23 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c564e329c87 Added tag hs25-b68 for changeset d45454002494 ! .hgtags Changeset: 58879cd9f8df Author: amurillo Date: 2014-01-28 09:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58879cd9f8df Merge ! .hgtags Changeset: 7e412f95e310 Author: amurillo Date: 2014-01-23 13:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e412f95e310 8032608: new hotspot build - hs25-b69 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 2185d483f5f8 Author: kvn Date: 2014-01-27 10:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2185d483f5f8 8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib) Summary: Switch off EliminateAutoBox flag by default in jdk8 release. Reviewed-by: iveresov ! src/share/vm/opto/c2_globals.hpp Changeset: 32f017489ba5 Author: amurillo Date: 2014-01-28 15:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32f017489ba5 Merge Changeset: 1d8728efc05f Author: amurillo Date: 2014-01-28 15:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d8728efc05f Added tag hs25-b69 for changeset 32f017489ba5 ! .hgtags Changeset: 35038da7bb9d Author: lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35038da7bb9d Merge Changeset: 874c0b4a946c Author: katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/874c0b4a946c Added tag jdk8-b127 for changeset 35038da7bb9d ! .hgtags Changeset: cb39165c4a65 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb39165c4a65 Added tag jdk8-b128 for changeset 874c0b4a946c ! .hgtags Changeset: 1dbaf664a611 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1dbaf664a611 Added tag jdk8-b129 for changeset cb39165c4a65 ! .hgtags From lana.steuck at oracle.com Tue Feb 11 13:40:47 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:47 +0000 Subject: hg: jdk8/tl/jdk: 14 new changesets Message-ID: <20140211214445.3A9FE62BA0@hg.openjdk.java.net> Changeset: 75cf17ceb6d1 Author: katleman Date: 2014-01-22 12:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75cf17ceb6d1 Added tag jdk8-b125 for changeset ae303640bc1c ! .hgtags Changeset: 95410515ba5f Author: katleman Date: 2014-01-22 14:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95410515ba5f Merge ! .hgtags Changeset: 91bce40d0347 Author: alexsch Date: 2014-01-23 20:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91bce40d0347 8032063: javax.swing.plaf.metal.MetalFileChooserUI$FilterComboBoxModel extends non-standard API Reviewed-by: pchelko, serb ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java - src/share/classes/sun/swing/AbstractFilterComboBoxModel.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 6935e7a3a7c9 Author: amurillo Date: 2014-01-23 14:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6935e7a3a7c9 Merge Changeset: a9088d517f2f Author: amurillo Date: 2014-01-23 14:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9088d517f2f Merge Changeset: a635c394328c Author: katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a635c394328c Added tag jdk8-b126 for changeset a9088d517f2f ! .hgtags Changeset: fbf251b8ef8a Author: lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbf251b8ef8a Merge Changeset: f777d83e0433 Author: katleman Date: 2014-01-30 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f777d83e0433 Added tag jdk8-b127 for changeset fbf251b8ef8a ! .hgtags Changeset: f644211c59fd Author: lana Date: 2014-01-31 13:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f644211c59fd Merge Changeset: 3c9473004f38 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c9473004f38 Added tag jdk8-b128 for changeset f644211c59fd ! .hgtags Changeset: ab6e7bb8ff9f Author: pchelko Date: 2014-01-22 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab6e7bb8ff9f 7155984: Security problems in regression test java/awt/PrintJob/Security/SecurityDialogTest.java Reviewed-by: anthony, serb ! src/macosx/classes/apple/laf/JRSUIUtils.java Changeset: eef10feca8ca Author: lana Date: 2014-02-06 13:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eef10feca8ca Merge Changeset: 80568a19aab7 Author: lana Date: 2014-02-06 13:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80568a19aab7 Merge Changeset: 43386cc9a017 Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43386cc9a017 Added tag jdk8-b129 for changeset 80568a19aab7 ! .hgtags From lana.steuck at oracle.com Tue Feb 11 13:40:08 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Feb 2014 21:40:08 +0000 Subject: hg: jdk8/tl: 8 new changesets Message-ID: <20140211214010.B63CD62B98@hg.openjdk.java.net> Changeset: 950921234b10 Author: katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/950921234b10 Added tag jdk8-b125 for changeset 790bbd46b201 ! .hgtags Changeset: 1b5d578f93ef Author: katleman Date: 2014-01-22 14:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1b5d578f93ef Merge ! .hgtags Changeset: 9ccce5bf1b0e Author: katleman Date: 2014-01-24 04:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9ccce5bf1b0e Merge Changeset: 4f8fa4724c14 Author: katleman Date: 2014-01-24 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4f8fa4724c14 Added tag jdk8-b126 for changeset 9ccce5bf1b0e ! .hgtags Changeset: 2e2ffb9e4b69 Author: lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2e2ffb9e4b69 Merge Changeset: 101e42de4686 Author: katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/101e42de4686 Added tag jdk8-b127 for changeset 2e2ffb9e4b69 ! .hgtags Changeset: 1e5fe8654913 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1e5fe8654913 Added tag jdk8-b128 for changeset 101e42de4686 ! .hgtags Changeset: 839546caab12 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/839546caab12 Added tag jdk8-b129 for changeset 1e5fe8654913 ! .hgtags From valerie.peng at oracle.com Tue Feb 11 14:18:03 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 11 Feb 2014 14:18:03 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <52F96F1C.7040405@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> Message-ID: <52FAA19B.8050108@oracle.com> 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. > >> >> 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. 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 weijun.wang at oracle.com Wed Feb 12 02:01:37 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 12 Feb 2014 18:01:37 +0800 Subject: RFR 8034762: Move krb5.conf related tests into a single place Message-ID: <200DF46A-B047-4DEF-8C35-F43734FF4F5C@oracle.com> Hi All The bug is at https://bugs.openjdk.java.net/browse/JDK-8034762. Basically there is nothing to review. I just move 10 files to a different directory and not a single bit of their contents was changed. They are test/sun/security/krb5/ConfPlusProp.java test/sun/security/krb5/ConfigWithQuotations.java test/sun/security/krb5/DnsFallback.java test/sun/security/krb5/ParseCAPaths.java test/sun/security/krb5/ParseConfig.java test/sun/security/krb5/confplusprop.conf test/sun/security/krb5/confplusprop2.conf test/sun/security/krb5/edu.mit.Kerberos test/sun/security/krb5/krb5-capaths.conf test/sun/security/krb5/krb5.conf Thanks Max From xuelei.fan at oracle.com Wed Feb 12 02:32:52 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 12 Feb 2014 18:32:52 +0800 Subject: RFR 8034762: Move krb5.conf related tests into a single place In-Reply-To: <200DF46A-B047-4DEF-8C35-F43734FF4F5C@oracle.com> References: <200DF46A-B047-4DEF-8C35-F43734FF4F5C@oracle.com> Message-ID: <52FB4DD4.40809@oracle.com> OK to me to make the changes. Xuelei On 2/12/2014 6:01 PM, Wang Weijun wrote: > Hi All > > The bug is at https://bugs.openjdk.java.net/browse/JDK-8034762. > > Basically there is nothing to review. I just move 10 files to a different directory and not a single bit of their contents was changed. They are > > test/sun/security/krb5/ConfPlusProp.java > test/sun/security/krb5/ConfigWithQuotations.java > test/sun/security/krb5/DnsFallback.java > test/sun/security/krb5/ParseCAPaths.java > test/sun/security/krb5/ParseConfig.java > test/sun/security/krb5/confplusprop.conf > test/sun/security/krb5/confplusprop2.conf > test/sun/security/krb5/edu.mit.Kerberos > test/sun/security/krb5/krb5-capaths.conf > test/sun/security/krb5/krb5.conf > > Thanks > Max > From sean.mullan at oracle.com Wed Feb 12 05:14:24 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Feb 2014 08:14:24 -0500 Subject: Result: New Security Group Member: Jason Uh Message-ID: <52FB73B0.1010506@oracle.com> The vote for Jason Uh [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-January/010087.html From jason.uh at oracle.com Wed Feb 12 15:17:47 2014 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 12 Feb 2014 15:17:47 -0800 Subject: [9] Request for Review: 8031025: SQE test CertPath/CertPathBuilderTest/* failed with java.lang.IndexOutOfBoundsException Message-ID: <52FC011B.1010101@oracle.com> Hi all, Please review this fix for JDK 9, which checks for an empty cert path list in RevocationChecker. webrev: http://cr.openjdk.java.net/~juh/8031025/webrev.01 noreq-sqe, as the fix can be verified with existing SQE tests. Thanks, Jason From sean.mullan at oracle.com Wed Feb 12 15:35:50 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Feb 2014 18:35:50 -0500 Subject: [9] Request for Review: 8031025: SQE test CertPath/CertPathBuilderTest/* failed with java.lang.IndexOutOfBoundsException In-Reply-To: <52FC011B.1010101@oracle.com> References: <52FC011B.1010101@oracle.com> Message-ID: <52FC0556.2020200@oracle.com> Looks good. --Sean On 02/12/2014 06:17 PM, Jason Uh wrote: > Hi all, > > Please review this fix for JDK 9, which checks for an empty cert path > list in RevocationChecker. > > webrev: http://cr.openjdk.java.net/~juh/8031025/webrev.01 > > noreq-sqe, as the fix can be verified with existing SQE tests. > > Thanks, > Jason From valerie.peng at oracle.com Wed Feb 12 16:48:05 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 12 Feb 2014 16:48:05 -0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> Message-ID: <52FC1645.3090400@oracle.com> Max, Changes look fine. However, I noticed some calls which may throw exceptions but no check is added, e.g. 593 (*env)->SetObjectArrayElement(env, address_list, index, address); BTW, I noticed there are several existing calls to ExceptionOccurred(...) which can be replaced with ExceptionCheck(...) calls which won't create local references to the exception object. Thanks, Valerie On 02/11/14 04:27, Wang Weijun wrote: > Hi All > > I didn't attend the parfait day last week, but a new one is coming. Please review my fix at > > http://cr.openjdk.java.net/~weijun/8034033/webrev.00/ > > Thanks > Max > From weijun.wang at oracle.com Wed Feb 12 16:56:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 13 Feb 2014 08:56:34 +0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: <52FC1645.3090400@oracle.com> References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> <52FC1645.3090400@oracle.com> Message-ID: <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> On Feb 13, 2014, at 8:48, Valerie (Yu-Ching) Peng wrote: > Max, > > Changes look fine. > However, I noticed some calls which may throw exceptions but no check is added, e.g. > > 593 (*env)->SetObjectArrayElement(env, address_list, index, address); That's in a while loop. Maybe parfait does not realize SetByteArrayRegion could be called after SetObjectArrayElement? > > BTW, I noticed there are several existing calls to ExceptionOccurred(...) which can be replaced with ExceptionCheck(...) calls which won't create local references to the exception object. I see. So ExceptionCheck is just a return-void version of ExceptionOccurred. I'll create another webrev. Thanks Max > > Thanks, > Valerie > > On 02/11/14 04:27, Wang Weijun wrote: >> Hi All >> >> I didn't attend the parfait day last week, but a new one is coming. Please review my fix at >> >> http://cr.openjdk.java.net/~weijun/8034033/webrev.00/ >> >> Thanks >> Max >> > From sean.mullan at oracle.com Thu Feb 13 05:04:23 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Feb 2014 08:04:23 -0500 Subject: Review Request for JDK-8025708 : Certificate Path Building problem with AKI serial number Message-ID: <52FCC2D7.5070500@oracle.com> See: http://cr.openjdk.java.net/~mullan/webrevs/8025708/webrev/ This fixes a problem with the PKIX CertPathBuilder where it wasn't able to build a path when the Authority Key Identifier extension of an intermediate CA cert did not contain a serial number field, and the end entity cert did. The problem was in the AdaptableX509CertSelector class. It was reusing this selector without re-initializing certain fields. I changed the implementation of this class so that it doesn't have this issue anymore. Thanks, Sean From Alan.Bateman at oracle.com Thu Feb 13 05:18:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Feb 2014 13:18:03 +0000 Subject: 8034856/8034857: More gcc warnings Message-ID: <52FCC60B.6040205@oracle.com> The number of native code warnings in the build is annoying so this is another drive-by fix that eliminates a few of them in the serviceability and security areas. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8034856+8034857/webrev/ In the pkcs11 code the issue is the function prototypes for the throwXXX functions aren't included. This is fixed by including pkcs11wrapper.h but that exposes another issue with the header file includes that needed to be fixed. In JarFacade the issue is that it uses isspace but doesn't include the ctype.h For LinuxOperatingSystem.c then there are 12 warnings related to fscanf usages where the format specifier is %lld and the code wants to read into a uint64_t. I've changed the format specifier to"%"SCNd64 so that it matches uint64_t and should be okay on both 32 and 64-bit. Thanks, Alan. From staffan.larsen at oracle.com Thu Feb 13 05:24:39 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 13 Feb 2014 14:24:39 +0100 Subject: 8034856/8034857: More gcc warnings In-Reply-To: <52FCC60B.6040205@oracle.com> References: <52FCC60B.6040205@oracle.com> Message-ID: Changes look good. /Staffan On 13 feb 2014, at 14:18, Alan Bateman wrote: > > The number of native code warnings in the build is annoying so this is another drive-by fix that eliminates a few of them in the serviceability and security areas. The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8034856+8034857/webrev/ > > In the pkcs11 code the issue is the function prototypes for the throwXXX functions aren't included. This is fixed by including pkcs11wrapper.h but that exposes another issue with the header file includes that needed to be fixed. > > In JarFacade the issue is that it uses isspace but doesn't include the ctype.h > > For LinuxOperatingSystem.c then there are 12 warnings related to fscanf usages where the format specifier is %lld and the code wants to read into a uint64_t. I've changed the format specifier to"%"SCNd64 so that it matches uint64_t and should be okay on both 32 and 64-bit. > > Thanks, > Alan. From sean.mullan at oracle.com Thu Feb 13 06:05:49 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Feb 2014 09:05:49 -0500 Subject: 8034856/8034857: More gcc warnings In-Reply-To: <52FCC60B.6040205@oracle.com> References: <52FCC60B.6040205@oracle.com> Message-ID: <52FCD13D.9040605@oracle.com> Looks fine to me. --Sean On 02/13/2014 08:18 AM, Alan Bateman wrote: > > The number of native code warnings in the build is annoying so this is > another drive-by fix that eliminates a few of them in the serviceability > and security areas. The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8034856+8034857/webrev/ > > In the pkcs11 code the issue is the function prototypes for the throwXXX > functions aren't included. This is fixed by including pkcs11wrapper.h > but that exposes another issue with the header file includes that needed > to be fixed. > > In JarFacade the issue is that it uses isspace but doesn't include the > ctype.h > > For LinuxOperatingSystem.c then there are 12 warnings related to fscanf > usages where the format specifier is %lld and the code wants to read > into a uint64_t. I've changed the format specifier to"%"SCNd64 so that > it matches uint64_t and should be okay on both 32 and 64-bit. > > Thanks, > Alan. From Alan.Bateman at oracle.com Thu Feb 13 10:23:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Feb 2014 18:23:30 +0000 Subject: 8034856/8034857: More gcc warnings In-Reply-To: <6E073B44-2FF7-419F-A094-7CD5C3AE0788@oracle.com> References: <52FCC60B.6040205@oracle.com> <6E073B44-2FF7-419F-A094-7CD5C3AE0788@oracle.com> Message-ID: <52FD0DA2.7030201@oracle.com> On 13/02/2014 17:56, Mikael Vidstedt wrote: > Alan, > > I made the change to JarFacade.c myself last week, only to then see the comment a few lines above where you added the new include. It seems to indicate that including ctype.h on Solaris/SPARC is a bad idea. I have no idea if the comment is still relevant, but that may be worth understanding first. > > Do you have cycles to look into it? As the code is using isspace already then it's not clear (unless there are different versions). Before pushing the changes then I ran the tests on all platforms (including Solaris) and the j.l.i tests include a number of tests exercise these manifest attributes with a non-US characters. As an aside, the native code warnings coming from the jdk repository are really annoying so this is the reason for the drive-by fixes when I get a few minutes. I think others are doing the same. -Alan. From mikael.vidstedt at oracle.com Thu Feb 13 09:56:48 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Feb 2014 09:56:48 -0800 Subject: 8034856/8034857: More gcc warnings In-Reply-To: <52FCC60B.6040205@oracle.com> References: <52FCC60B.6040205@oracle.com> Message-ID: <6E073B44-2FF7-419F-A094-7CD5C3AE0788@oracle.com> Alan, I made the change to JarFacade.c myself last week, only to then see the comment a few lines above where you added the new include. It seems to indicate that including ctype.h on Solaris/SPARC is a bad idea. I have no idea if the comment is still relevant, but that may be worth understanding first. Cheers, Mikael > On Feb 13, 2014, at 5:18, Alan Bateman wrote: > > > The number of native code warnings in the build is annoying so this is another drive-by fix that eliminates a few of them in the serviceability and security areas. The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8034856+8034857/webrev/ > > In the pkcs11 code the issue is the function prototypes for the throwXXX functions aren't included. This is fixed by including pkcs11wrapper.h but that exposes another issue with the header file includes that needed to be fixed. > > In JarFacade the issue is that it uses isspace but doesn't include the ctype.h > > For LinuxOperatingSystem.c then there are 12 warnings related to fscanf usages where the format specifier is %lld and the code wants to read into a uint64_t. I've changed the format specifier to"%"SCNd64 so that it matches uint64_t and should be okay on both 32 and 64-bit. > > Thanks, > Alan. From anthony.scarpino at oracle.com Thu Feb 13 11:16:56 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 13 Feb 2014 11:16:56 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <52FAA19B.8050108@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> Message-ID: <52FD1A28.8050808@oracle.com> 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 mikael.vidstedt at oracle.com Thu Feb 13 13:14:45 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Feb 2014 13:14:45 -0800 Subject: 8034856/8034857: More gcc warnings In-Reply-To: <52FD0DA2.7030201@oracle.com> References: <52FCC60B.6040205@oracle.com> <6E073B44-2FF7-419F-A094-7CD5C3AE0788@oracle.com> <52FD0DA2.7030201@oracle.com> Message-ID: <52FD35C5.1000306@oracle.com> On 2014-02-13 10:23, Alan Bateman wrote: > On 13/02/2014 17:56, Mikael Vidstedt wrote: >> Alan, >> >> I made the change to JarFacade.c myself last week, only to then see >> the comment a few lines above where you added the new include. It >> seems to indicate that including ctype.h on Solaris/SPARC is a bad >> idea. I have no idea if the comment is still relevant, but that may >> be worth understanding first. >> >> > Do you have cycles to look into it? As the code is using isspace > already then it's not clear (unless there are different versions). > Before pushing the changes then I ran the tests on all platforms > (including Solaris) and the j.l.i tests include a number of tests > exercise these manifest attributes with a non-US characters. The change in question appears to come from https://bugs.openjdk.java.net/browse/JDK-6679866, but I'm not sure the bug gives enough additional information. My speculation (and it's really just a speculation) is that it's not related to isspace per-se, but to something else which gets defined/redefined/undefined by including ctype.h. I guess it would be good to know if we have tests which cover the thing the comment is alluding to (non-ascii in Premain-Class). > As an aside, the native code warnings coming from the jdk repository > are really annoying so this is the reason for the drive-by fixes when > I get a few minutes. I think others are doing the same. Absolutely support this work! As a matter of fact I have a couple of change in a sandbox I should send out for review. Cheers, Mikael From valerie.peng at oracle.com Thu Feb 13 15:29:17 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 13 Feb 2014 15:29:17 -0800 Subject: Review Request for JDK-8033571: [parfait] warning from b128 for security/smartcardio/pcsc_md.c: JNI exception pending Message-ID: <52FD554D.7050207@oracle.com> 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 From valerie.peng at oracle.com Thu Feb 13 16:30:54 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 13 Feb 2014 16:30:54 -0800 Subject: Review Request for JDK-8030114: [parfait] warnings from b119 for jdk.src.share.native.sun.security.smartcardio: JNI exception pending Message-ID: <52FD63BE.9080004@oracle.com> 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/ Thanks, Valerie From weijun.wang at oracle.com Thu Feb 13 17:49:10 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 14 Feb 2014 09:49:10 +0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> <52FC1645.3090400@oracle.com> <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> Message-ID: <7B37A8A1-AE93-4F93-9A9A-0CF6F8DCB904@oracle.com> Updated webrev at http://cr.openjdk.java.net/~weijun/8034033/webrev.01/ Thanks Max On Feb 13, 2014, at 8:56, Wang Weijun wrote: > > On Feb 13, 2014, at 8:48, Valerie (Yu-Ching) Peng wrote: > >> Max, >> >> Changes look fine. >> However, I noticed some calls which may throw exceptions but no check is added, e.g. >> >> 593 (*env)->SetObjectArrayElement(env, address_list, index, address); > > That's in a while loop. Maybe parfait does not realize SetByteArrayRegion could be called after SetObjectArrayElement? > >> >> BTW, I noticed there are several existing calls to ExceptionOccurred(...) which can be replaced with ExceptionCheck(...) calls which won't create local references to the exception object. > > I see. So ExceptionCheck is just a return-void version of ExceptionOccurred. > > I'll create another webrev. > > Thanks > Max > > >> >> Thanks, >> Valerie >> >> On 02/11/14 04:27, Wang Weijun wrote: >>> Hi All >>> >>> I didn't attend the parfait day last week, but a new one is coming. Please review my fix at >>> >>> http://cr.openjdk.java.net/~weijun/8034033/webrev.00/ >>> >>> Thanks >>> Max >>> >> > From jason.uh at oracle.com Thu Feb 13 19:04:41 2014 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 13 Feb 2014 19:04:41 -0800 Subject: Review Request for JDK-8025708 : Certificate Path Building problem with AKI serial number In-Reply-To: <52FCC2D7.5070500@oracle.com> References: <52FCC2D7.5070500@oracle.com> Message-ID: <52FD87C9.8010004@oracle.com> Hi Sean, Looks good to me, but I'm not an official Reviewer. I have a couple of questions, though. 1. This isn't a part of your change, but shouldn't the comment on line 200 of AdaptableX509CertSelector.java read "As for version 3,..." and not "As for version 2,..."? 2. Just curious, any reason why this wasn't just fixed with void parseAuthorityKeyIdentifierExtension( AuthorityKeyIdentifierExtension akidext) throws IOException { + super.setSubjectKeyIdentifier(null); + super.setSerialNumber(null); if (akidext != null) { ... } in AdaptableX509CertSelector.java? Thanks! Jason On 2/13/14 5:04 AM, Sean Mullan wrote: > See: http://cr.openjdk.java.net/~mullan/webrevs/8025708/webrev/ > > This fixes a problem with the PKIX CertPathBuilder where it wasn't able > to build a path when the Authority Key Identifier extension of an > intermediate CA cert did not contain a serial number field, and the end > entity cert did. > > The problem was in the AdaptableX509CertSelector class. It was reusing > this selector without re-initializing certain fields. I changed the > implementation of this class so that it doesn't have this issue anymore. > > Thanks, > Sean From Alan.Bateman at oracle.com Fri Feb 14 04:06:05 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Feb 2014 12:06:05 +0000 Subject: 8034943: Eliminate Keberos dependency on com.sun.security.auth to avoid circular dependency Message-ID: <52FE06AD.2090407@oracle.com> As part of preparing the JDK for modules we need to look at the dependencies between Kerberos and JAAS as they are logically separate components. As it stands we have a circular dependency due to the JDK-specific API to JAAS have API dependencies on Kerberos types, and the JGSS implementation using one of the CallbackHandlers defined in JDK-specific API to JAAS. I'd like to eliminate this dependency with the following patch: http://cr.openjdk.java.net/~alanb/8034943/webrev/ It basically copies TextCallbackHandler to sun.security.util.ConsoleCallbackHandler and changes TextCallbackHandler so that it just delegates to ConsoleCallbackHandler. This is good enough to fix the dependency issue and with the change then all the existing JAAS and Kerberos tests in the jdk repository pass as before. -Alan. From weijun.wang at oracle.com Fri Feb 14 05:55:47 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 14 Feb 2014 21:55:47 +0800 Subject: 8034943: Eliminate Keberos dependency on com.sun.security.auth to avoid circular dependency In-Reply-To: <52FE06AD.2090407@oracle.com> References: <52FE06AD.2090407@oracle.com> Message-ID: <4683FFE0-FE25-460B-A001-1BFECF0C890E@oracle.com> Code change looks good. Do you really want to use "Copyright (c) 2000, 2014" for the new file? Thanks Max On Feb 14, 2014, at 20:06, Alan Bateman wrote: > > As part of preparing the JDK for modules we need to look at the dependencies between Kerberos and JAAS as they are logically separate components. > > As it stands we have a circular dependency due to the JDK-specific API to JAAS have API dependencies on Kerberos types, and the JGSS implementation using one of the CallbackHandlers defined in JDK-specific API to JAAS. > > I'd like to eliminate this dependency with the following patch: > > http://cr.openjdk.java.net/~alanb/8034943/webrev/ > > It basically copies TextCallbackHandler to sun.security.util.ConsoleCallbackHandler and changes TextCallbackHandler so that it just delegates to ConsoleCallbackHandler. This is good enough to fix the dependency issue and with the change then all the existing JAAS and Kerberos tests in the jdk repository pass as before. > > -Alan. > > From Alan.Bateman at oracle.com Fri Feb 14 05:56:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Feb 2014 13:56:33 +0000 Subject: 8034943: Eliminate Keberos dependency on com.sun.security.auth to avoid circular dependency In-Reply-To: <4683FFE0-FE25-460B-A001-1BFECF0C890E@oracle.com> References: <52FE06AD.2090407@oracle.com> <4683FFE0-FE25-460B-A001-1BFECF0C890E@oracle.com> Message-ID: <52FE2091.20307@oracle.com> On 14/02/2014 13:55, Wang Weijun wrote: > Code change looks good. > > Do you really want to use "Copyright (c) 2000, 2014" for the new file? > Thanks Max. On the copyright date then I wasn't sure. As the code is coming from TextCallbackHandler (originally 2000 I assume) then I left this as the starting year. I could of course just put 2014 as it is a new file. Hard to know sometimes. Do you have a suggestion? -Alan From weijun.wang at oracle.com Fri Feb 14 06:01:33 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 14 Feb 2014 22:01:33 +0800 Subject: 8034943: Eliminate Keberos dependency on com.sun.security.auth to avoid circular dependency In-Reply-To: <52FE2091.20307@oracle.com> References: <52FE06AD.2090407@oracle.com> <4683FFE0-FE25-460B-A001-1BFECF0C890E@oracle.com> <52FE2091.20307@oracle.com> Message-ID: Unless you put a comment saying this file is a direct copy of another file, the starting year does not make sense. Of course people really curious about it can track to this changeset and see its origin. --Max On Feb 14, 2014, at 21:56, Alan Bateman wrote: > On 14/02/2014 13:55, Wang Weijun wrote: >> Code change looks good. >> >> Do you really want to use "Copyright (c) 2000, 2014" for the new file? >> > Thanks Max. > > On the copyright date then I wasn't sure. As the code is coming from TextCallbackHandler (originally 2000 I assume) then I left this as the starting year. I could of course just put 2014 as it is a new file. Hard to know sometimes. Do you have a suggestion? > > -Alan From Alan.Bateman at oracle.com Fri Feb 14 06:07:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Feb 2014 14:07:41 +0000 Subject: 8034943: Eliminate Keberos dependency on com.sun.security.auth to avoid circular dependency In-Reply-To: References: <52FE06AD.2090407@oracle.com> <4683FFE0-FE25-460B-A001-1BFECF0C890E@oracle.com> <52FE2091.20307@oracle.com> Message-ID: <52FE232D.3060405@oracle.com> On 14/02/2014 14:01, Wang Weijun wrote: > Unless you put a comment saying this file is a direct copy of another file, the starting year does not make sense. Of course people really curious about it can track to this changeset and see its origin. > > --Max > Okay, I can just leave it as 2014 so that it looks like a new file. If anyone is curious then they can look at the hg logs. -Alan From fweimer at redhat.com Fri Feb 14 06:32:23 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 14 Feb 2014 15:32:23 +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: <52FD63BE.9080004@oracle.com> References: <52FD63BE.9080004@oracle.com> Message-ID: <52FE28F7.5010408@redhat.com> 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. -- Florian Weimer / Red Hat Product Security Team From sean.mullan at oracle.com Fri Feb 14 07:17:24 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Feb 2014 10:17:24 -0500 Subject: Review Request for JDK-8025708 : Certificate Path Building problem with AKI serial number In-Reply-To: <52FD87C9.8010004@oracle.com> References: <52FCC2D7.5070500@oracle.com> <52FD87C9.8010004@oracle.com> Message-ID: <52FE3384.7020607@oracle.com> On 02/13/2014 10:04 PM, Jason Uh wrote: > Hi Sean, > > Looks good to me, but I'm not an official Reviewer. > > I have a couple of questions, though. Sure. > 1. This isn't a part of your change, but shouldn't the comment on line > 200 of AdaptableX509CertSelector.java read "As for version 3,..." and > not "As for version 2,..."? Yes, good catch. I changed it. > 2. Just curious, any reason why this wasn't just fixed with > > void parseAuthorityKeyIdentifierExtension( > AuthorityKeyIdentifierExtension akidext) throws IOException { > + super.setSubjectKeyIdentifier(null); > + super.setSerialNumber(null); > > if (akidext != null) { ... } > > in AdaptableX509CertSelector.java? I did initially consider that fix, but the problem is the subjectKeyIdentifier and serialNumber matching rules are slightly different for X509CertSelector. In X509CertSelector the subjectKeyIdentifier match fails if the certificate has no subject key identifier, whereas in AdaptableX509CertSelector it passes. With serialNumber, the match is only performed in AdaptableX509CertSelector if the certificate version is < 3. The previous code for AdaptableX509CertSelector had to workaround that by setting these criteria to null in certain cases to trick the superclass matching rules to pass. See lines 167-171 and 182-184. After reviewing this code, I came to the conclusion that it was much cleaner to always override the matching rules for these criteria in AdaptableX509CertSelector and never call the superclass methods to set those criteria (which is why they are overridden to throw IllegalArgumentExc). Hope this makes sense. --Sean > > Thanks! > > Jason > > On 2/13/14 5:04 AM, Sean Mullan wrote: >> See: http://cr.openjdk.java.net/~mullan/webrevs/8025708/webrev/ >> >> This fixes a problem with the PKIX CertPathBuilder where it wasn't able >> to build a path when the Authority Key Identifier extension of an >> intermediate CA cert did not contain a serial number field, and the end >> entity cert did. >> >> The problem was in the AdaptableX509CertSelector class. It was reusing >> this selector without re-initializing certain fields. I changed the >> implementation of this class so that it doesn't have this issue anymore. >> >> Thanks, >> Sean > From jason.uh at oracle.com Fri Feb 14 12:29:42 2014 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 14 Feb 2014 12:29:42 -0800 Subject: Review Request for JDK-8025708 : Certificate Path Building problem with AKI serial number In-Reply-To: <52FE3384.7020607@oracle.com> References: <52FCC2D7.5070500@oracle.com> <52FD87C9.8010004@oracle.com> <52FE3384.7020607@oracle.com> Message-ID: <52FE7CB6.4030909@oracle.com> On 2/14/14 7:17 AM, Sean Mullan wrote: > On 02/13/2014 10:04 PM, Jason Uh wrote: >> Hi Sean, >> >> Looks good to me, but I'm not an official Reviewer. >> >> I have a couple of questions, though. > > Sure. > >> 1. This isn't a part of your change, but shouldn't the comment on line >> 200 of AdaptableX509CertSelector.java read "As for version 3,..." and >> not "As for version 2,..."? > > Yes, good catch. I changed it. > >> 2. Just curious, any reason why this wasn't just fixed with >> >> void parseAuthorityKeyIdentifierExtension( >> AuthorityKeyIdentifierExtension akidext) throws >> IOException { >> + super.setSubjectKeyIdentifier(null); >> + super.setSerialNumber(null); >> >> if (akidext != null) { ... } >> >> in AdaptableX509CertSelector.java? > > I did initially consider that fix, but the problem is the > subjectKeyIdentifier and serialNumber matching rules are slightly > different for X509CertSelector. In X509CertSelector the > subjectKeyIdentifier match fails if the certificate has no subject key > identifier, whereas in AdaptableX509CertSelector it passes. With > serialNumber, the match is only performed in AdaptableX509CertSelector > if the certificate version is < 3. > > The previous code for AdaptableX509CertSelector had to workaround that > by setting these criteria to null in certain cases to trick the > superclass matching rules to pass. See lines 167-171 and 182-184. After > reviewing this code, I came to the conclusion that it was much cleaner > to always override the matching rules for these criteria in > AdaptableX509CertSelector and never call the superclass methods to set > those criteria (which is why they are overridden to throw > IllegalArgumentExc). > > Hope this makes sense. Ah, I see. Agreed! Thanks for the explanation. Jason > --Sean > > > >> >> Thanks! >> >> Jason >> >> On 2/13/14 5:04 AM, Sean Mullan wrote: >>> See: http://cr.openjdk.java.net/~mullan/webrevs/8025708/webrev/ >>> >>> This fixes a problem with the PKIX CertPathBuilder where it wasn't able >>> to build a path when the Authority Key Identifier extension of an >>> intermediate CA cert did not contain a serial number field, and the end >>> entity cert did. >>> >>> The problem was in the AdaptableX509CertSelector class. It was reusing >>> this selector without re-initializing certain fields. I changed the >>> implementation of this class so that it doesn't have this issue anymore. >>> >>> Thanks, >>> Sean >> > From anthony.scarpino at oracle.com Fri Feb 14 12:51:35 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 14 Feb 2014 12:51:35 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <52FD1A28.8050808@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> <52FD1A28.8050808@oracle.com> Message-ID: <52FE81D7.7030903@oracle.com> I've updated the webrev, removing the unneeded methods, and also adding back some rather important pool cleanup code I hadn't noticed the patch removed. http://cr.openjdk.java.net/~ascarpino/7107611/webrev.01/ Tony On 02/13/2014 11:16 AM, 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 Feb 14 16:45:34 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 14 Feb 2014 16:45:34 -0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: <7B37A8A1-AE93-4F93-9A9A-0CF6F8DCB904@oracle.com> References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> <52FC1645.3090400@oracle.com> <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> <7B37A8A1-AE93-4F93-9A9A-0CF6F8DCB904@oracle.com> Message-ID: <52FEB8AE.2070900@oracle.com> Hi, Max, Just noticed that there is a JNIEnv->NewObject call on line 378. It looks like we have to check pending exception there also? This call is inside a while loop... Rest looks fine. Thanks, Valerie On 02/13/14 17:49, Wang Weijun wrote: > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8034033/webrev.01/ > > Thanks > Max > > On Feb 13, 2014, at 8:56, Wang Weijun wrote: > >> On Feb 13, 2014, at 8:48, Valerie (Yu-Ching) Peng wrote: >> >>> Max, >>> >>> Changes look fine. >>> However, I noticed some calls which may throw exceptions but no check is added, e.g. >>> >>> 593 (*env)->SetObjectArrayElement(env, address_list, index, address); >> That's in a while loop. Maybe parfait does not realize SetByteArrayRegion could be called after SetObjectArrayElement? >> >>> BTW, I noticed there are several existing calls to ExceptionOccurred(...) which can be replaced with ExceptionCheck(...) calls which won't create local references to the exception object. >> I see. So ExceptionCheck is just a return-void version of ExceptionOccurred. >> >> I'll create another webrev. >> >> Thanks >> Max >> >> >>> Thanks, >>> Valerie >>> >>> On 02/11/14 04:27, Wang Weijun wrote: >>>> Hi All >>>> >>>> I didn't attend the parfait day last week, but a new one is coming. Please review my fix at >>>> >>>> http://cr.openjdk.java.net/~weijun/8034033/webrev.00/ >>>> >>>> Thanks >>>> Max >>>> From weijun.wang at oracle.com Fri Feb 14 17:14:26 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 15 Feb 2014 09:14:26 +0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: <52FEB8AE.2070900@oracle.com> References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> <52FC1645.3090400@oracle.com> <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> <7B37A8A1-AE93-4F93-9A9A-0CF6F8DCB904@oracle.com> <52FEB8AE.2070900@oracle.com> Message-ID: Hi Valerie Since this is a while loop, it seems for each BuildXXX function, just returning NULL when an exception is thrown is not enough, because it's not returning to Java but still inside the native code so another JNI call might run. Do you think it's OK to add a ExceptionClear call after the cleanup label? This would suppress the exception but the returning value will most likely to be null in this case so IMO it's quite harmless. In fact this loop is quite strange: it goes thru all creds, reads those for krbtgt and returns the *last* found one. During this loop, NewObject for krbCreds could be called several times. Will this cause a memory leak? Also, the check made is "strncmp (serverName, "krbtgt", sizeof("krbtgt")-1) == 0" so this means a cross-realm TGT like krbtgt/THIS at THAT also matches. Now that the last one is returned this is more likely an issue because normally the initial TGT should appear before the cross-realm TGT. I'll need to look more into this and do some test. Thanks Max On Feb 15, 2014, at 8:45, Valerie (Yu-Ching) Peng wrote: > > Hi, Max, > > Just noticed that there is a JNIEnv->NewObject call on line 378. It looks like we have to check pending exception there also? This call is inside a while loop... > > Rest looks fine. > Thanks, > Valerie > >> http://cr.openjdk.java.net/~weijun/8034033/webrev.01/ From xuelei.fan at oracle.com Fri Feb 14 17:52:46 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 15 Feb 2014 09:52:46 +0800 Subject: Review Request for JDK-8025708 : Certificate Path Building problem with AKI serial number In-Reply-To: <52FCC2D7.5070500@oracle.com> References: <52FCC2D7.5070500@oracle.com> Message-ID: <52FEC86E.8060005@oracle.com> AdaptableX509CertSelector.java ============================== 1. for boolean value checking, I normally use if (boolean-value) or if (!boolean-value) 2. AdaptableX509CertSelector.match(Certificate) KID can be used to facilitate the path building. I would suggest check the SKID and SN at first, and then call super.match(). 3. AdaptableX509CertSelector.clone() Also want to clone "serial" variabl? 4. absence of SKID Per section 4.2.1.2, RFC 5280: To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE. In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Not a big concerns, I was just wondering we may still want to check KID although the serial number checking may be optional. This update allow the absence of subject key ID extension. Otherwise, looks fine to me. Xuelei On 2/13/2014 9:04 PM, Sean Mullan wrote: > See: http://cr.openjdk.java.net/~mullan/webrevs/8025708/webrev/ > > This fixes a problem with the PKIX CertPathBuilder where it wasn't able > to build a path when the Authority Key Identifier extension of an > intermediate CA cert did not contain a serial number field, and the end > entity cert did. > > The problem was in the AdaptableX509CertSelector class. It was reusing > this selector without re-initializing certain fields. I changed the > implementation of this class so that it doesn't have this issue anymore. > > Thanks, > Sean From xuelei.fan at oracle.com Fri Feb 14 18:01:01 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 15 Feb 2014 10:01:01 +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: <52FECA5D.9020607@oracle.com> Looks fine to me. Just want to make sure, no exception should be thrown if libName is null, right? 92 if (libName == NULL) { 93 return; 94 } Xuelei On 2/14/2014 7:29 AM, 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 From weijun.wang at oracle.com Sat Feb 15 00:18:07 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 15 Feb 2014 16:18:07 +0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> <52FC1645.3090400@oracle.com> <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> <7B37A8A1-AE93-4F93-9A9A-0CF6F8DCB904@oracle.com> <52FEB8AE.2070900@oracle.com> Message-ID: <025C2E31-AD37-4F2D-AF23-8A38CA9705FC@oracle.com> Webrev updated again at http://cr.openjdk.java.net/~weijun/8034033/webrev.02/ I add more checks to make sure it's a good initial TGT, and exit the loop when there is either an exception or the TGT is found. So there will be no exception pending and also no memory leak. Thanks Max On Feb 15, 2014, at 9:14, Wang Weijun wrote: > Hi Valerie > > Since this is a while loop, it seems for each BuildXXX function, just returning NULL when an exception is thrown is not enough, because it's not returning to Java but still inside the native code so another JNI call might run. Do you think it's OK to add a ExceptionClear call after the cleanup label? This would suppress the exception but the returning value will most likely to be null in this case so IMO it's quite harmless. > > In fact this loop is quite strange: it goes thru all creds, reads those for krbtgt and returns the *last* found one. During this loop, NewObject for krbCreds could be called several times. Will this cause a memory leak? > > Also, the check made is "strncmp (serverName, "krbtgt", sizeof("krbtgt")-1) == 0" so this means a cross-realm TGT like krbtgt/THIS at THAT also matches. Now that the last one is returned this is more likely an issue because normally the initial TGT should appear before the cross-realm TGT. I'll need to look more into this and do some test. > > Thanks > Max > > > On Feb 15, 2014, at 8:45, Valerie (Yu-Ching) Peng wrote: > >> >> Hi, Max, >> >> Just noticed that there is a JNIEnv->NewObject call on line 378. It looks like we have to check pending exception there also? This call is inside a while loop... >> >> Rest looks fine. >> Thanks, >> Valerie >> >>> http://cr.openjdk.java.net/~weijun/8034033/webrev.01/ > From bernd-2014 at eckenfels.net Sat Feb 15 14:31:37 2014 From: bernd-2014 at eckenfels.net (Bernd Eckenfels) Date: Sat, 15 Feb 2014 23:31:37 +0100 Subject: FYI: ssl ciphers (howsmyssl.com) Message-ID: <20140215233137.0000105d.bernd-2014@eckenfels.net> Hello, I run Oracle 1.8.0 b129 with default SSL Socket Factory (win7 x64) against howsmyssl.com and here is the API response: Howsmyssl Test: 1.8.0-b129/25.0-b69 Java HotSpot(TM) 64-Bit Server VM HTTP/1.1 200 OK Content-Length: 1578 Connection: close Content-Type: application/json Date: Sat, 15 Feb 2014 22:08:07 GMT Strict-Transport-Security: max-age=631138519; includeSubdomains {"given_cipher_suites":[ "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA256", "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256", "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256", "TLS_DHE_RSA_WITH_AES_128_CBC_SHA256", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA", "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA", "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA", "TLS_ECDHE_RSA_WITH_RC4_128_SHA", "TLS_RSA_WITH_RC4_128_SHA", "TLS_ECDH_ECDSA_WITH_RC4_128_SHA", "TLS_ECDH_RSA_WITH_RC4_128_SHA", "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256", "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA", "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA", "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA", "TLS_RSA_WITH_RC4_128_MD5", "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"], "ephemeral_keys_supported":true, "session_ticket_supported":false, "tls_compression_supported":false, "unknown_cipher_suite_supported":false, "beast_vuln":false, "able_to_detect_n_minus_one_splitting":false, "insecure_cipher_suites":{}, "tls_version":"TLS 1.2", "rating":"Improvable"} Not sure what contributes to improvable, I guess the absence of session ticket support is the major point here. We talked about the sequence of ciphers before. Anyway, as I read here: https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls "PFS is not enabled by default", but the cipher list looks otherwise? (which I think is good), But, I am not sure why TLS_RSA_WITH_AES_128_CBC_SHA256 is higher prioritized than TLS_DHE_RSA_WITH_AES_128_CBC_SHA256? Greetings Bernd PS: https://github.com/ecki/JavaCryptoTest/blob/master/src/main/java/net/eckenfels/test/howsmyssl/Client.java From sean.mullan at oracle.com Mon Feb 17 05:57:20 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Feb 2014 08:57:20 -0500 Subject: Review Request for JDK-8025708 : Certificate Path Building problem with AKI serial number In-Reply-To: <52FEC86E.8060005@oracle.com> References: <52FCC2D7.5070500@oracle.com> <52FEC86E.8060005@oracle.com> Message-ID: <53021540.8040002@oracle.com> On 02/14/2014 08:52 PM, Xuelei Fan wrote: > AdaptableX509CertSelector.java > ============================== > 1. for boolean value checking, I normally use > if (boolean-value) or if (!boolean-value) I usually do too, but "== false" seemed more readable to me in this code, perhaps because it is immediately returning false afterwards. Anyway, it's not a big deal either way to me, so I'll change it to "!". > 2. AdaptableX509CertSelector.match(Certificate) > KID can be used to facilitate the path building. I would suggest > check the SKID and SN at first, and then call super.match(). Good point, this will filter out non-matching certs faster. Changed. > 3. AdaptableX509CertSelector.clone() > Also want to clone "serial" variabl? Not necessary, it's immutable. > 4. absence of SKID > Per section 4.2.1.2, RFC 5280: > > To facilitate certification path construction, this extension MUST > appear in all conforming CA certificates, that is, all certificates > including the basic constraints extension (Section 4.2.1.9) where the > value of cA is TRUE. In conforming CA certificates, the value of the > subject key identifier MUST be the value placed in the key identifier > field of the authority key identifier extension (Section 4.2.1.1) of > certificates issued by the subject of this certificate. > > Not a big concerns, I was just wondering we may still want to check > KID although the serial number checking may be optional. This update > allow the absence of subject key ID extension. Yes I was wondering about that, but I am just preserving the previous behavior: see lines 167-170 -- which I assume was done for a good reason. --Sean > > Otherwise, looks fine to me. > > Xuelei > > > On 2/13/2014 9:04 PM, Sean Mullan wrote: >> See: http://cr.openjdk.java.net/~mullan/webrevs/8025708/webrev/ >> >> This fixes a problem with the PKIX CertPathBuilder where it wasn't able >> to build a path when the Authority Key Identifier extension of an >> intermediate CA cert did not contain a serial number field, and the end >> entity cert did. >> >> The problem was in the AdaptableX509CertSelector class. It was reusing >> this selector without re-initializing certain fields. I changed the >> implementation of this class so that it doesn't have this issue anymore. >> >> Thanks, >> Sean > From Xuelei.Fan at Oracle.Com Mon Feb 17 06:34:55 2014 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 17 Feb 2014 22:34:55 +0800 Subject: Review Request for JDK-8025708 : Certificate Path Building problem with AKI serial number In-Reply-To: <53021540.8040002@oracle.com> References: <52FCC2D7.5070500@oracle.com> <52FEC86E.8060005@oracle.com> <53021540.8040002@oracle.com> Message-ID: <1418C5F0-B81A-43DF-BC4C-D30CCBAC1430@Oracle.Com> Ok to me. Xuelei > On Feb 17, 2014, at 9:57 PM, Sean Mullan wrote: > >> On 02/14/2014 08:52 PM, Xuelei Fan wrote: >> AdaptableX509CertSelector.java >> ============================== >> 1. for boolean value checking, I normally use >> if (boolean-value) or if (!boolean-value) > > I usually do too, but "== false" seemed more readable to me in this code, perhaps because it is immediately returning false afterwards. Anyway, it's not a big deal either way to me, so I'll change it to "!". > >> 2. AdaptableX509CertSelector.match(Certificate) >> KID can be used to facilitate the path building. I would suggest >> check the SKID and SN at first, and then call super.match(). > > Good point, this will filter out non-matching certs faster. Changed. > >> 3. AdaptableX509CertSelector.clone() >> Also want to clone "serial" variabl? > > Not necessary, it's immutable. > >> 4. absence of SKID >> Per section 4.2.1.2, RFC 5280: >> >> To facilitate certification path construction, this extension MUST >> appear in all conforming CA certificates, that is, all certificates >> including the basic constraints extension (Section 4.2.1.9) where the >> value of cA is TRUE. In conforming CA certificates, the value of the >> subject key identifier MUST be the value placed in the key identifier >> field of the authority key identifier extension (Section 4.2.1.1) of >> certificates issued by the subject of this certificate. >> >> Not a big concerns, I was just wondering we may still want to check >> KID although the serial number checking may be optional. This update >> allow the absence of subject key ID extension. > > Yes I was wondering about that, but I am just preserving the previous behavior: see lines 167-170 -- which I assume was done for a good reason. > > --Sean > >> >> Otherwise, looks fine to me. >> >> Xuelei >> >> >>> On 2/13/2014 9:04 PM, Sean Mullan wrote: >>> See: http://cr.openjdk.java.net/~mullan/webrevs/8025708/webrev/ >>> >>> This fixes a problem with the PKIX CertPathBuilder where it wasn't able >>> to build a path when the Authority Key Identifier extension of an >>> intermediate CA cert did not contain a serial number field, and the end >>> entity cert did. >>> >>> The problem was in the AdaptableX509CertSelector class. It was reusing >>> this selector without re-initializing certain fields. I changed the >>> implementation of this class so that it doesn't have this issue anymore. >>> >>> Thanks, >>> Sean >> > From weijun.wang at oracle.com Tue Feb 18 17:02:02 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 19 Feb 2014 09:02:02 +0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: <025C2E31-AD37-4F2D-AF23-8A38CA9705FC@oracle.com> References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> <52FC1645.3090400@oracle.com> <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> <7B37A8A1-AE93-4F93-9A9A-0CF6F8DCB904@oracle.com> <52FEB8AE.2070900@oracle.com> <025C2E31-AD37-4F2D-AF23-8A38CA9705FC@oracle.com> Message-ID: Ping again. On Feb 15, 2014, at 16:18, Wang Weijun wrote: > Webrev updated again at > > http://cr.openjdk.java.net/~weijun/8034033/webrev.02/ > > I add more checks to make sure it's a good initial TGT, and exit the loop when there is either an exception or the TGT is found. So there will be no exception pending and also no memory leak. > > Thanks > Max From valerie.peng at oracle.com Tue Feb 18 18:19:42 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 18 Feb 2014 18:19:42 -0800 Subject: RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c In-Reply-To: References: <2BDDBB87-7F3D-4849-8BED-6C514C41B28B@oracle.com> <52FC1645.3090400@oracle.com> <43A00812-F627-41A9-9F11-8B79714CC269@oracle.com> <7B37A8A1-AE93-4F93-9A9A-0CF6F8DCB904@oracle.com> <52FEB8AE.2070900@oracle.com> <025C2E31-AD37-4F2D-AF23-8A38CA9705FC@oracle.com> Message-ID: <530414BE.3070307@oracle.com> Changes look fine. Thanks, Valerie On 02/18/14 17:02, Wang Weijun wrote: > Ping again. > > On Feb 15, 2014, at 16:18, Wang Weijun wrote: > >> Webrev updated again at >> >> http://cr.openjdk.java.net/~weijun/8034033/webrev.02/ >> >> I add more checks to make sure it's a good initial TGT, and exit the loop when there is either an exception or the TGT is found. So there will be no exception pending and also no memory leak. >> >> Thanks >> Max From valerie.peng at oracle.com Tue Feb 18 18:34:29 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 18 Feb 2014 18:34:29 -0800 Subject: Review Request for JDK-8033571: [parfait] warning from b128 for security/smartcardio/pcsc_md.c: JNI exception pending In-Reply-To: <52FECA5D.9020607@oracle.com> References: <52FD554D.7050207@oracle.com> <52FECA5D.9020607@oracle.com> Message-ID: <53041835.40802@oracle.com> Hmm, good question. When I checked JNI spec, it turns out that it didn't list any JNI exception under JNIEnv->GetStringUTFChars(...). Since this JNI method Java_sun_security_smartcardio_PlatformPCSC_initialize(..) does not return any object, perhaps we should throw some exception here to indicate a failure despite that it's very unlikely to happen in reality. I think either NullPointerException or IOException will do here. Do you have a preference? Valerie On 02/14/14 18:01, Xuelei Fan wrote: > Looks fine to me. > > Just want to make sure, no exception should be thrown if libName is > null, right? > > 92 if (libName == NULL) { > 93 return; > 94 } > > Xuelei > > On 2/14/2014 7:29 AM, 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 From xuelei.fan at oracle.com Tue Feb 18 18:56:37 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 19 Feb 2014 10:56:37 +0800 Subject: Review Request for JDK-8033571: [parfait] warning from b128 for security/smartcardio/pcsc_md.c: JNI exception pending In-Reply-To: <53041835.40802@oracle.com> References: <52FD554D.7050207@oracle.com> <52FECA5D.9020607@oracle.com> <53041835.40802@oracle.com> Message-ID: <53041D65.7090107@oracle.com> On 2/19/2014 10:34 AM, Valerie (Yu-Ching) Peng wrote: > > Hmm, good question. > When I checked JNI spec, it turns out that it didn't list any JNI > exception under JNIEnv->GetStringUTFChars(...). > Since this JNI method > Java_sun_security_smartcardio_PlatformPCSC_initialize(..) does not > return any object, perhaps we should throw some exception here to > indicate a failure despite that it's very unlikely to happen in reality. > > I think either NullPointerException or IOException will do here. Do you > have a preference? I prefer NPE if jLibName cannot be null. Xuelei > Valerie > > On 02/14/14 18:01, Xuelei Fan wrote: >> Looks fine to me. >> >> Just want to make sure, no exception should be thrown if libName is >> null, right? >> >> 92 if (libName == NULL) { >> 93 return; >> 94 } >> >> Xuelei >> >> On 2/14/2014 7:29 AM, 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 > From valerie.peng at oracle.com Wed Feb 19 18:32:56 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 19 Feb 2014 18:32:56 -0800 Subject: Review Request for JDK-8033571: [parfait] warning from b128 for security/smartcardio/pcsc_md.c: JNI exception pending In-Reply-To: <53041D65.7090107@oracle.com> References: <52FD554D.7050207@oracle.com> <52FECA5D.9020607@oracle.com> <53041835.40802@oracle.com> <53041D65.7090107@oracle.com> Message-ID: <53056958.4050004@oracle.com> Ok, webrev updated: http://cr.openjdk.java.net/~valeriep/8033571/webrev.01 Thanks, Valerie On 02/18/14 18:56, Xuelei Fan wrote: > On 2/19/2014 10:34 AM, Valerie (Yu-Ching) Peng wrote: >> Hmm, good question. >> When I checked JNI spec, it turns out that it didn't list any JNI >> exception under JNIEnv->GetStringUTFChars(...). >> Since this JNI method >> Java_sun_security_smartcardio_PlatformPCSC_initialize(..) does not >> return any object, perhaps we should throw some exception here to >> indicate a failure despite that it's very unlikely to happen in reality. >> >> I think either NullPointerException or IOException will do here. Do you >> have a preference? > I prefer NPE if jLibName cannot be null. > > Xuelei > >> Valerie >> >> On 02/14/14 18:01, Xuelei Fan wrote: >>> Looks fine to me. >>> >>> Just want to make sure, no exception should be thrown if libName is >>> null, right? >>> >>> 92 if (libName == NULL) { >>> 93 return; >>> 94 } >>> >>> Xuelei >>> >>> On 2/14/2014 7:29 AM, 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 From luchsh at linux.vnet.ibm.com Wed Feb 19 19:15:30 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 20 Feb 2014 11:15:30 +0800 Subject: Add IDN support to existing net APIs In-Reply-To: <53048751.8070000@oracle.com> References: <53048751.8070000@oracle.com> Message-ID: Hi Michael, Thanks a lot for your comments. On Wed, Feb 19, 2014 at 6:28 PM, Michael McMahon < michael.x.mcmahon at oracle.com> wrote: > I think it's a good idea. Before changing anything though, > we would need to: > > 1. identify all APIs that could potentially be affected and figure out > what is > needed for each. For instance: > 1. InetAddress > 2. SocketPermission > 3. URLPermission > 4. HttpURLConnection > 5. URL/URI > 6. ... > > Right, I assume all APIs which accept string-represented host names would be affected. It that may not be a big change from point of view. > > 1. > 1. understand how it relates to URIs and IRIs. I haven't looked > into this much > but it seems that there might be potential for confusion given that > these entities > have their own encoding schemes already. I'm sure the issues are all > well thrashed out > already, but I'd like to see exactly how it will work in Java before > we start the work > > For the potential confusion, were you meaning a confusion between URI encoding (RFC-2396 [1]) and IDN ? > > > Maybe, the work is within the scope of a small JEP, if nothing else to > define the scope > of the work. > > Michael. > Copying core-libs-dev and security-dev to get more comments. Many thanks - Jonathan [1] http://www.ietf.org/rfc/rfc2396.txt > > > On 19/02/14 04:00, Jonathan Lu wrote: > > Hi net-dev, > > If a Java application tries to support International Domain Names (IDN) > [1], which was firstly brought in Java6, > it has to write additional code or wrap java.net.IDN API [2] to make the > conversion each time it tries to resolve > a non-ASCII domain name, and use the converted punycode to make > connections to remote host, like: > > java.net.IDN.toASCII("??.info "); > > It is easier for newly writen applications, since a wrappers can be made > in early design stage, but if > it comes to existing Java applications and third-party libraries, IDN > support would involve much more effort > like modifying the existing code base, inspecting libraries > interfaces/implementations, or even > re-implement some of the functions. > > I'm wondering if it is possible to add IDN support into existing Java > APIs, like > java.net.InetAddress.getByName(), if JDK itself supports IDN, any existing > applications or libraries would > benefit from supporting IDN automatically without any source code > modifications. > > Of course there's security risks regarding IDN homograph attacks [1][2], > so it may not be a > good idea to change the default behavior right now. But it would still > work if a simple switch can be > added into current JDK. > For example, by defining following the property in command like options > like > > -Djava.net.AutoIDN=true > > Any existing Java applications who wishes to support IDN feature will be > able to support IDN > without any changes to its source code or re-compilation. > > What's your opinion on this ? any comment is welcome. > > Thank you > > - Jonathan Lu > > ----------- > > [1] http://en.wikipedia.org/wiki/Internationalized_domain_name > [2] http://download.java.net/jdk8/docs/api/java/net/IDN.html > [3] http://www.unicode.org/reports/tr36/ > [4] http://en.wikipedia.org/wiki/IDN_homograph_attack > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140220/2c4382b5/attachment.html From stefan.liebig at compeople.de Wed Feb 19 21:59:29 2014 From: stefan.liebig at compeople.de (Stefan Liebig) Date: Thu, 20 Feb 2014 05:59:29 +0000 Subject: Bug 8028627 Message-ID: <44027d28e6b9426fbb670f05b2cc1222@DOX13BE01.hex2013.com> Hi, I would like to add a comment to an existing bug: - http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8028627 - https://bugs.openjdk.java.net/browse/JDK-8028627 The problem described in that bug seems that it has been discovered by statically code analysis. However, it seems that we have this problem in production code. A thread dump shows that two threads are "looping": Java HotSpot(TM) Client VM (24.45-b08 mixed mode) "pool-2-thread-2" prio=6 tid=0x40537c00 nid=0xb80 runnable [0x4298e000] java.lang.Thread.State: RUNNABLE at java.util.WeakHashMap.get(WeakHashMap.java:471) at javax.crypto.JceSecurity.getCodeBase(JceSecurity.java:222) at javax.crypto.JceSecurityManager.getCryptoPermission(JceSecurityManager.java:107) at javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2503) at javax.crypto.Cipher.initCryptoPermission(Cipher.java:685) at javax.crypto.Cipher.chooseProvider(Cipher.java:848) - locked <0x16005f98> (a java.lang.Object) at javax.crypto.Cipher.init(Cipher.java:1213) at javax.crypto.Cipher.init(Cipher.java:1153) at org.hsqldb.persist.Crypto.(Unknown Source) at org.hsqldb.persist.Logger.setVariables(Unknown Source) at org.hsqldb.persist.Logger.openPersistence(Unknown Source) at org.hsqldb.Database.reopen(Unknown Source) at org.hsqldb.Database.open(Unknown Source) - locked <0x15e51a60> (a org.hsqldb.Database) at org.hsqldb.DatabaseManager.getDatabase(Unknown Source) - locked <0x15e51a60> (a org.hsqldb.Database) at org.hsqldb.DatabaseManager.newSession(Unknown Source) at org.hsqldb.jdbc.JDBCConnection.(Unknown Source) ... "pool-2-thread-1" prio=6 tid=0x40537400 nid=0x18f4 runnable [0x412fe000] java.lang.Thread.State: RUNNABLE at java.util.WeakHashMap.get(WeakHashMap.java:471) at javax.crypto.JceSecurity.getCodeBase(JceSecurity.java:222) at javax.crypto.JceSecurityManager.getCryptoPermission(JceSecurityManager.java:107) at javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2503) at javax.crypto.Cipher.initCryptoPermission(Cipher.java:685) at javax.crypto.Cipher.chooseProvider(Cipher.java:848) - locked <0x16006128> (a java.lang.Object) at javax.crypto.Cipher.init(Cipher.java:1213) at javax.crypto.Cipher.init(Cipher.java:1153) at org.hsqldb.persist.Crypto.(Unknown Source) at org.hsqldb.persist.Logger.setVariables(Unknown Source) at org.hsqldb.persist.Logger.openPersistence(Unknown Source) at org.hsqldb.Database.reopen(Unknown Source) at org.hsqldb.Database.open(Unknown Source) - locked <0x15e5a718> (a org.hsqldb.Database) at org.hsqldb.DatabaseManager.getDatabase(Unknown Source) - locked <0x15e5a718> (a org.hsqldb.Database) at org.hsqldb.DatabaseManager.newSession(Unknown Source) at org.hsqldb.jdbc.JDBCConnection.(Unknown Source) at org.hsqldb.jdbc.JDBCDriver.getConnection(Unknown Source) at org.hsqldb.jdbc.JDBCDriver.connect(Unknown Source) ... We have two database instances running parallel. Tsch??, Stefan ------------------------------------------------------------- compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.de Vorstand: J?rgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 ------------------------------------------------------------- From bradford.wetmore at oracle.com Thu Feb 20 16:29:20 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 20 Feb 2014 16:29:20 -0800 Subject: Bug 8028627 In-Reply-To: <44027d28e6b9426fbb670f05b2cc1222@DOX13BE01.hex2013.com> References: <44027d28e6b9426fbb670f05b2cc1222@DOX13BE01.hex2013.com> Message-ID: <53069DE0.6@oracle.com> I've added the stack trace to the report. Thanks! Brad On 2/19/2014 9:59 PM, Stefan Liebig wrote: > Hi, > > I would like to add a comment to an existing bug: > - http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8028627 > - https://bugs.openjdk.java.net/browse/JDK-8028627 > > The problem described in that bug seems that it has been discovered by statically code analysis. > However, it seems that we have this problem in production code. A thread dump shows that two threads are "looping": > > Java HotSpot(TM) Client VM (24.45-b08 mixed mode) > > "pool-2-thread-2" prio=6 tid=0x40537c00 nid=0xb80 runnable [0x4298e000] > java.lang.Thread.State: RUNNABLE > at java.util.WeakHashMap.get(WeakHashMap.java:471) > at javax.crypto.JceSecurity.getCodeBase(JceSecurity.java:222) > at javax.crypto.JceSecurityManager.getCryptoPermission(JceSecurityManager.java:107) > at javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2503) > at javax.crypto.Cipher.initCryptoPermission(Cipher.java:685) > at javax.crypto.Cipher.chooseProvider(Cipher.java:848) > - locked <0x16005f98> (a java.lang.Object) > at javax.crypto.Cipher.init(Cipher.java:1213) > at javax.crypto.Cipher.init(Cipher.java:1153) > at org.hsqldb.persist.Crypto.(Unknown Source) > at org.hsqldb.persist.Logger.setVariables(Unknown Source) > at org.hsqldb.persist.Logger.openPersistence(Unknown Source) > at org.hsqldb.Database.reopen(Unknown Source) > at org.hsqldb.Database.open(Unknown Source) > - locked <0x15e51a60> (a org.hsqldb.Database) > at org.hsqldb.DatabaseManager.getDatabase(Unknown Source) > - locked <0x15e51a60> (a org.hsqldb.Database) > at org.hsqldb.DatabaseManager.newSession(Unknown Source) > at org.hsqldb.jdbc.JDBCConnection.(Unknown Source) ... > > "pool-2-thread-1" prio=6 tid=0x40537400 nid=0x18f4 runnable [0x412fe000] > java.lang.Thread.State: RUNNABLE > at java.util.WeakHashMap.get(WeakHashMap.java:471) > at javax.crypto.JceSecurity.getCodeBase(JceSecurity.java:222) > at javax.crypto.JceSecurityManager.getCryptoPermission(JceSecurityManager.java:107) > at javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2503) > at javax.crypto.Cipher.initCryptoPermission(Cipher.java:685) > at javax.crypto.Cipher.chooseProvider(Cipher.java:848) > - locked <0x16006128> (a java.lang.Object) > at javax.crypto.Cipher.init(Cipher.java:1213) > at javax.crypto.Cipher.init(Cipher.java:1153) > at org.hsqldb.persist.Crypto.(Unknown Source) > at org.hsqldb.persist.Logger.setVariables(Unknown Source) > at org.hsqldb.persist.Logger.openPersistence(Unknown Source) > at org.hsqldb.Database.reopen(Unknown Source) > at org.hsqldb.Database.open(Unknown Source) > - locked <0x15e5a718> (a org.hsqldb.Database) > at org.hsqldb.DatabaseManager.getDatabase(Unknown Source) > - locked <0x15e5a718> (a org.hsqldb.Database) > at org.hsqldb.DatabaseManager.newSession(Unknown Source) > at org.hsqldb.jdbc.JDBCConnection.(Unknown Source) > at org.hsqldb.jdbc.JDBCDriver.getConnection(Unknown Source) > at org.hsqldb.jdbc.JDBCDriver.connect(Unknown Source) ... > > We have two database instances running parallel. > > Tsch??, > Stefan > ------------------------------------------------------------- > compeople AG > Untermainanlage 8 > 60329 Frankfurt/Main > fon: +49 (0) 69 / 27 22 18 0 > fax: +49 (0) 69 / 27 22 18 22 > web: www.compeople.de > > Vorstand: J?rgen Wiesmaier > Aufsichtsratsvorsitzender: Christian Glanz > > Sitz der Gesellschaft: Frankfurt/Main > Handelsregister Frankfurt HRB 56759 > USt-IdNr. DE207665352 > ------------------------------------------------------------- > From weijun.wang at oracle.com Thu Feb 20 22:17:41 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 21 Feb 2014 14:17:41 +0800 Subject: Dup content in java.security-platform files Message-ID: <2C8A4F0B-7649-45C4-9854-8B0693EB7E3B@oracle.com> Is there a proposal to extract them into a single include file? Thanks Max From valerie.peng at oracle.com Fri Feb 21 14:38:00 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 21 Feb 2014 14:38:00 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <52FD1A28.8050808@oracle.com> References: <52EFDEEE.7090406@oracle.com> <52F95AFD.6090303@oracle.com> <52F96F1C.7040405@oracle.com> <52FAA19B.8050108@oracle.com> <52FD1A28.8050808@oracle.com> Message-ID: <5307D548.2080606@oracle.com> 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 Feb 21 14:44:56 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 21 Feb 2014 14:44:56 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <5307D548.2080606@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> Message-ID: <5307D6E8.5010300@oracle.com> On 02/21/2014 02:38 PM, Valerie (Yu-Ching) Peng wrote: > > Where can I find the updated webrev? Oops.. thought I included it: http://cr.openjdk.java.net/~ascarpino/7107611/webrev.01/ > > 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 Feb 21 16:41:25 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 21 Feb 2014 16:41:25 -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: <52FE28F7.5010408@redhat.com> References: <52FD63BE.9080004@oracle.com> <52FE28F7.5010408@redhat.com> Message-ID: <5307F235.4030401@oracle.com> 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 sean.mullan at oracle.com Sun Feb 23 09:44:03 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Sun, 23 Feb 2014 12:44:03 -0500 Subject: Dup content in java.security-platform files In-Reply-To: <2C8A4F0B-7649-45C4-9854-8B0693EB7E3B@oracle.com> References: <2C8A4F0B-7649-45C4-9854-8B0693EB7E3B@oracle.com> Message-ID: <530A3363.8040506@oracle.com> On 02/21/2014 01:17 AM, Wang Weijun wrote: > Is there a proposal to extract them into a single include file? No solution proposed yet, but there is an RFE for this: https://bugs.openjdk.java.net/browse/JDK-6997010 --Sean From java3 at segal.org Sun Feb 23 10:20:36 2014 From: java3 at segal.org (Mickey Segal) Date: Sun, 23 Feb 2014 13:20:36 -0500 Subject: Bug 8028627 In-Reply-To: <53069DE0.6@oracle.com> References: <44027d28e6b9426fbb670f05b2cc1222@DOX13BE01.hex2013.com> <53069DE0.6@oracle.com> Message-ID: <002001cf30c3$f35d07b0$da171710$@segal.org> There used to be a way to add such comments directly to bug reports. For a general non-security bug, how can one add comments and updates? I have bugs submitted 4 years ago (e.g. http://bugs.java.com/view_bug.do?bug_id=8014369) that are still listed as "In progress" and I don't see any way to add a comment. Bradford Wetmore wrote: I've added the stack trace to the report. From weijun.wang at oracle.com Sun Feb 23 15:57:29 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 24 Feb 2014 07:57:29 +0800 Subject: Dup content in java.security-platform files In-Reply-To: <530A3363.8040506@oracle.com> References: <2C8A4F0B-7649-45C4-9854-8B0693EB7E3B@oracle.com> <530A3363.8040506@oracle.com> Message-ID: <51DF6125-429E-4979-BDFB-9A4DAEDD7DAD@oracle.com> A somehow related question: is there a proposal to specify a security property on the command line? Thanks Max On Feb 24, 2014, at 1:44, Sean Mullan wrote: > On 02/21/2014 01:17 AM, Wang Weijun wrote: >> Is there a proposal to extract them into a single include file? > > No solution proposed yet, but there is an RFE for this: https://bugs.openjdk.java.net/browse/JDK-6997010 > > --Sean From sean.mullan at oracle.com Mon Feb 24 05:57:34 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 Feb 2014 08:57:34 -0500 Subject: Dup content in java.security-platform files In-Reply-To: <51DF6125-429E-4979-BDFB-9A4DAEDD7DAD@oracle.com> References: <2C8A4F0B-7649-45C4-9854-8B0693EB7E3B@oracle.com> <530A3363.8040506@oracle.com> <51DF6125-429E-4979-BDFB-9A4DAEDD7DAD@oracle.com> Message-ID: <530B4FCE.6070201@oracle.com> On 02/23/2014 06:57 PM, Wang Weijun wrote: > A somehow related question: is there a proposal to specify a security property on the command line? I agree that would be useful. A workaround: echo "property=foo" > /tmp/props; java -Djava.security.properties=/tmp/foo ... --Sean From sean.mullan at oracle.com Mon Feb 24 06:05:42 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 Feb 2014 09:05:42 -0500 Subject: Dup content in java.security-platform files In-Reply-To: <530B4FCE.6070201@oracle.com> References: <2C8A4F0B-7649-45C4-9854-8B0693EB7E3B@oracle.com> <530A3363.8040506@oracle.com> <51DF6125-429E-4979-BDFB-9A4DAEDD7DAD@oracle.com> <530B4FCE.6070201@oracle.com> Message-ID: <530B51B6.6050503@oracle.com> On 02/24/2014 08:57 AM, Sean Mullan wrote: > On 02/23/2014 06:57 PM, Wang Weijun wrote: >> A somehow related question: is there a proposal to specify a security >> property on the command line? > > I agree that would be useful. A workaround: > > echo "property=foo" > /tmp/props; java > -Djava.security.properties=/tmp/foo ... Oops, I mean: echo "property=foo" > /tmp/props; java -Djava.security.properties=/tmp/props ... --Sean From bradford.wetmore at oracle.com Mon Feb 24 12:40:28 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 24 Feb 2014 12:40:28 -0800 Subject: Bug 8028627 In-Reply-To: <002001cf30c3$f35d07b0$da171710$@segal.org> References: <44027d28e6b9426fbb670f05b2cc1222@DOX13BE01.hex2013.com> <53069DE0.6@oracle.com> <002001cf30c3$f35d07b0$da171710$@segal.org> Message-ID: <530BAE3C.40703@oracle.com> Are you referring to 8014369: Intermittently only some components refresh This was submitted May 2013. > For a > general non-security bug, how can one add comments and updates? If you are a OpenJDK contributor with a userid, you should be able to add directly to it using the JIRA instance, but if not, then I'd suggest writing to the appropriate group. This is a AWT bug, so probably awt-dev? http://mail.openjdk.java.net/mailman/listinfo Brad On 2/23/2014 10:20 AM, Mickey Segal wrote: > There used to be a way to add such comments directly to bug reports. For a > general non-security bug, how can one add comments and updates? I have bugs > submitted 4 years ago (e.g. http://bugs.java.com/view_bug.do?bug_id=8014369) > that are still listed as "In progress" and I don't see any way to add a > comment. > > Bradford Wetmore wrote: > > I've added the stack trace to the report. > > From weijun.wang at oracle.com Tue Feb 25 04:44:27 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Feb 2014 20:44:27 +0800 Subject: RFR 7176574 for 7u-dev: sun/security/krb5/auto/TcpTimeout.java failure Message-ID: <0B77E234-3877-444F-A032-1ABFDA0B1ABE@oracle.com> 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 artem.smotrakov at oracle.com Tue Feb 25 23:41:32 2014 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 26 Feb 2014 11:41:32 +0400 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <52F24C9A.5000207@oracle.com> References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> Message-ID: <530D9AAC.5080608@oracle.com> 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 Feb 26 00:09:37 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 26 Feb 2014 16:09:37 +0800 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <530D9AAC.5080608@oracle.com> References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> Message-ID: <6977BC53-1175-4FB1-9D34-EC6725E38E5C@oracle.com> Hi Artem Indefinite length is not allowed in DER so we never generate it. However, we do support reading it. I guess there must be a reason. Maybe 1. We don't have separate BerXXX classes, so basically we read both DER and BER with the same codes. 2. Most protocols require DER encoding, but maybe some do not, we need to deal with them. 3. Maybe there are vendors out there that generates non-standard DER. Anyway, I think it's better to be tolerant, especially we have supported it ever since. 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 From weijun.wang at oracle.com Wed Feb 26 00:15:13 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 26 Feb 2014 16:15:13 +0800 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <6977BC53-1175-4FB1-9D34-EC6725E38E5C@oracle.com> References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> <6977BC53-1175-4FB1-9D34-EC6725E38E5C@oracle.com> Message-ID: <4AFACF10-8019-4780-96FC-64AF16B0EDAE@oracle.com> Oh, I might have mis-read your webrev. I take back my words below. Will read it again. Thanks Max On Feb 26, 2014, at 16:09, Wang Weijun wrote: > > Anyway, I think it's better to be tolerant, especially we have supported it ever since. > > 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 > From xuelei.fan at oracle.com Wed Feb 26 01:39:53 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 26 Feb 2014 17:39:53 +0800 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <4AFACF10-8019-4780-96FC-64AF16B0EDAE@oracle.com> References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> <6977BC53-1175-4FB1-9D34-EC6725E38E5C@oracle.com> <4AFACF10-8019-4780-96FC-64AF16B0EDAE@oracle.com> Message-ID: <530DB669.3000903@oracle.com> FYI. It common to encode as DER, and decode as BER. BER is still a popular format. For example, PKCS#7 is BER based, and JDK accept PKCS#7 records. See the usage section of this wiki [*] for more protocols that use BER encoding. It's better to avoid the update that the DER APIs cannot be used to decode BER any more. [*] http://en.wikipedia.org/wiki/X.690 On 2/26/2014 4:15 PM, Wang Weijun wrote: > Oh, I might have mis-read your webrev. I take back my words below. Will read it again. > > Thanks > Max > > On Feb 26, 2014, at 16:09, Wang Weijun wrote: > >> >> Anyway, I think it's better to be tolerant, especially we have supported it ever since. >> >> 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 >> > From weijun.wang at oracle.com Wed Feb 26 01:54:52 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 26 Feb 2014 17:54:52 +0800 Subject: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <530D9AAC.5080608@oracle.com> References: <52EA1196.4080702@oracle.com> <52F24C9A.5000207@oracle.com> <530D9AAC.5080608@oracle.com> Message-ID: 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 volker.simonis at gmail.com Wed Feb 26 10:51:29 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Feb 2014 19:51:29 +0100 Subject: RFR(S): 8035881: PPC64: Fix AIX build in ppc-aix-port/stage after syncing 7133499 and 8028293 from jdk8u Message-ID: Hi, please review the following small AIX-only change for ppc-aix-port/stage (and eventually jdk8u) which became necessary after we have synced the following two changes from jdk8u: 8028293: Check local configuration for actual ephemeral port range 7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X This change also updates src/share/lib/security/java.security-aix to incorporate the latest changes from the other platforms security files (i.e. java.security-aix is now equal to java.security-linux). http://cr.openjdk.java.net/~simonis/webrevs/8035881/ https://bugs.openjdk.java.net/browse/JDK-8035881 This change is similar to the already reviewed and pushed "8033154: PPC64: Fix AIX build after integration into jdk9/dev" for jdk9/dev except that jdk8u doesn?t have "8032451: (dc) DatagramChannel.join should support include-mode filtering on OS X" until now so the corresponding fixes aren't needed. See the thread http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-January/001653.html for the previous review. make/lib/NioLibraries.gmk src/aix/native/sun/nio/ch/AixNativeThread.c 7133499 did some changes to NativeThread.c. Instead of adding another platform specific section to that file I've moved the AIX implementation to it's own file which will only be used during the AIX port. Notice that the changes in the makefile are in a AIX-specific section and won't affect any other platform. src/solaris/classes/sun/net/PortConfig.java This is another file which wasn't present in our stage/jdk repository but in the new jdk8u/jdk. Just added the required, AIX-specific section to the file. src/share/lib/security/java.security-aix Recent changes have updated the various src/share/lib/security/java.security* files. Without these changes, the JDK failes to pass the java/lang/SecurityManager/CheckPackageAccess.java jtreg regression test. I've just updated java.security-aix to be the same like the corresponding Linux version (as this was done - and agreed upon that it is OK - in the initial AIX change). Thanks, Volker From Alan.Bateman at oracle.com Wed Feb 26 11:00:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Feb 2014 19:00:14 +0000 Subject: RFR(S): 8035881: PPC64: Fix AIX build in ppc-aix-port/stage after syncing 7133499 and 8028293 from jdk8u In-Reply-To: References: Message-ID: <530E39BE.9040904@oracle.com> On 26/02/2014 18:51, Volker Simonis wrote: > Hi, > > please review the following small AIX-only change for > ppc-aix-port/stage (and eventually jdk8u) which became necessary after > we have synced the following two changes from jdk8u: > > 8028293: Check local configuration for actual ephemeral port range > 7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X > > This change also updates src/share/lib/security/java.security-aix to > incorporate the latest changes from the other platforms security files > (i.e. java.security-aix is now equal to java.security-linux). > > http://cr.openjdk.java.net/~simonis/webrevs/8035881/ > https://bugs.openjdk.java.net/browse/JDK-8035881 > This looks okay to me although I have no way to check the default ephemeral port rate on AIX. -Alan. From vladimir.kozlov at oracle.com Wed Feb 26 11:24:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Feb 2014 11:24:14 -0800 Subject: RFR(S): 8035881: PPC64: Fix AIX build in ppc-aix-port/stage after syncing 7133499 and 8028293 from jdk8u In-Reply-To: <530E39BE.9040904@oracle.com> References: <530E39BE.9040904@oracle.com> Message-ID: <530E3F5E.7000501@oracle.com> I will do JPRT control build and push this fix into ppc-aix-port/stage Thanks, Vladimir On 2/26/14 11:00 AM, Alan Bateman wrote: > On 26/02/2014 18:51, Volker Simonis wrote: >> Hi, >> >> please review the following small AIX-only change for >> ppc-aix-port/stage (and eventually jdk8u) which became necessary after >> we have synced the following two changes from jdk8u: >> >> 8028293: Check local configuration for actual ephemeral port range >> 7133499: (fc) FileChannel.read not preempted by asynchronous close on >> OS X >> >> This change also updates src/share/lib/security/java.security-aix to >> incorporate the latest changes from the other platforms security files >> (i.e. java.security-aix is now equal to java.security-linux). >> >> http://cr.openjdk.java.net/~simonis/webrevs/8035881/ >> https://bugs.openjdk.java.net/browse/JDK-8035881 >> > This looks okay to me although I have no way to check the default > ephemeral port rate on AIX. > > -Alan. > From sean.coffey at oracle.com Wed Feb 26 15:07:08 2014 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 26 Feb 2014 23:07:08 +0000 Subject: hg: jdk8/tl/corba: 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only Message-ID: <20140226230711.5750362F74@hg.openjdk.java.net> Changeset: 0683ee308085 Author: coffeys Date: 2014-02-26 23:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0683ee308085 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only Reviewed-by: mchung, chegar ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java From robert.field at oracle.com Fri Feb 28 10:45:50 2014 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 28 Feb 2014 18:45:50 +0000 Subject: hg: jdk8/tl/jdk: 8035777: Consistent Lambda construction Message-ID: <20140228184805.22B6D6239C@hg.openjdk.java.net> Changeset: 183a8c520b4a Author: rfield Date: 2014-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/183a8c520b4a 8035777: Consistent Lambda construction Reviewed-by: ahgross, briangoetz, dlsmith ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaReceiver.java + test/java/lang/invoke/lambda/LambdaReceiverBridge.java + test/java/lang/invoke/lambda/LambdaReceiver_anotherpkg/LambdaReceiver_A.java + test/java/lang/invoke/lambda/LambdaReturn.java + test/java/lang/invoke/lambda/MetafactoryArityTest.java + test/java/lang/invoke/lambda/MetafactoryParameterCastTest.java + test/java/lang/invoke/lambda/MetafactorySamReturnTest.java From jason.uh at oracle.com Fri Feb 28 11:54:13 2014 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 28 Feb 2014 11:54:13 -0800 Subject: [9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert Message-ID: <5310E965.1080803@oracle.com> 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 Thanks, Jason From jason.uh at oracle.com Fri Feb 28 11:56:30 2014 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 28 Feb 2014 11:56:30 -0800 Subject: Request for Review: 8035973: NPE in ForwardBuilder Message-ID: <5310E9EE.3090400@oracle.com> Could I please get a review of this change? 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 anthony.scarpino at oracle.com Fri Feb 28 15:03:55 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 28 Feb 2014 15:03:55 -0800 Subject: Code Review Request: 7107611 sun.security.pkcs11.SessionManager is scalability blocker In-Reply-To: <5307D548.2080606@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> Message-ID: <531115DB.5080708@oracle.com> 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 xuelei.fan at oracle.com Fri Feb 28 15:31:59 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 01 Mar 2014 07:31:59 +0800 Subject: Request for Review: 8035973: NPE in ForwardBuilder In-Reply-To: <5310E9EE.3090400@oracle.com> References: <5310E9EE.3090400@oracle.com> Message-ID: <53111C6F.3080502@oracle.com> Looks fine to me. noreg-trivial tag? Xuelei On 3/1/2014 3:56 AM, Jason Uh wrote: > Could I please get a review of this change? > > 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 jason.uh at oracle.com Fri Feb 28 15:38:12 2014 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 28 Feb 2014 15:38:12 -0800 Subject: Request for Review: 8035973: NPE in ForwardBuilder In-Reply-To: <53111C6F.3080502@oracle.com> References: <5310E9EE.3090400@oracle.com> <53111C6F.3080502@oracle.com> Message-ID: <53111DE4.5090505@oracle.com> Do I need more than one noreg tag? I already have noreg-sqe. On 2/28/14 3:31 PM, Xuelei Fan wrote: > Looks fine to me. noreg-trivial tag? > > Xuelei > > On 3/1/2014 3:56 AM, Jason Uh wrote: >> Could I please get a review of this change? >> >> 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 Fri Feb 28 15:50:41 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 01 Mar 2014 07:50:41 +0800 Subject: Request for Review: 8035973: NPE in ForwardBuilder In-Reply-To: <53111DE4.5090505@oracle.com> References: <5310E9EE.3090400@oracle.com> <53111C6F.3080502@oracle.com> <53111DE4.5090505@oracle.com> Message-ID: <531120D1.9040607@oracle.com> On 3/1/2014 7:38 AM, Jason Uh wrote: > Do I need more than one noreg tag? I already have noreg-sqe. > noreg-sqe is OK. Thanks, Xuelei > On 2/28/14 3:31 PM, Xuelei Fan wrote: >> Looks fine to me. noreg-trivial tag? >> >> Xuelei >> >> On 3/1/2014 3:56 AM, Jason Uh wrote: >>> Could I please get a review of this change? >>> >>> 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 weijun.wang at oracle.com Fri Feb 28 19: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 Fri Feb 28 22: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 >> >