From sean.mullan at oracle.com Mon Jun 2 18:15:24 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 02 Jun 2014 14:15:24 -0400 Subject: JDK 9 RFR for 8036841 : Reuse no-perms AccessControlContext object when performing isAuthorized check Message-ID: <538CBF3C.7020202@oracle.com> This is a fix to avoid creating multiple no-perms ACC objects for access control checks. Since this is required in an uncommon scenario, I used the Initialization on demand holder pattern to only create it under those circumstances. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8036841/webrev.01/ --Sean From bradford.wetmore at oracle.com Mon Jun 2 19:15:07 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 02 Jun 2014 12:15:07 -0700 Subject: JDK 9 RFR for 8036841 : Reuse no-perms AccessControlContext object when performing isAuthorized check In-Reply-To: <538CBF3C.7020202@oracle.com> References: <538CBF3C.7020202@oracle.com> Message-ID: <538CCD3B.90100@oracle.com> Looks ok to me. Brad On 6/2/2014 11:15 AM, Sean Mullan wrote: > This is a fix to avoid creating multiple no-perms ACC objects for access > control checks. Since this is required in an uncommon scenario, I used > the Initialization on demand holder pattern to only create it under > those circumstances. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8036841/webrev.01/ > > --Sean From anthony.scarpino at oracle.com Mon Jun 2 19:34:52 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 02 Jun 2014 12:34:52 -0700 Subject: RFR: 8037742 & 8041142: solaris sunpkcs11 config changes Message-ID: <538CD1DC.4030605@oracle.com> Him I need review of two very simple config file changes to enable algorithms for Solaris PKCS#11 that were disabled due to fixed Solaris bugs or old SPARC hardware performance issues. http://cr.openjdk.java.net/~ascarpino/8037742/webrev/ http://cr.openjdk.java.net/~ascarpino/8041142/webrev/ thanks Tony From valerie.peng at oracle.com Mon Jun 2 21:52:39 2014 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 02 Jun 2014 14:52:39 -0700 Subject: RFR: 8037742 & 8041142: solaris sunpkcs11 config changes In-Reply-To: <538CD1DC.4030605@oracle.com> References: <538CD1DC.4030605@oracle.com> Message-ID: <538CF227.3070801@oracle.com> Looks fine. Valerie On 06/02/14 12:34, Anthony Scarpino wrote: > Him > > I need review of two very simple config file changes to enable > algorithms for Solaris PKCS#11 that were disabled due to fixed Solaris > bugs or old SPARC hardware performance issues. > > http://cr.openjdk.java.net/~ascarpino/8037742/webrev/ > http://cr.openjdk.java.net/~ascarpino/8041142/webrev/ > > thanks > > Tony From anthony.scarpino at oracle.com Tue Jun 3 00:04:27 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 02 Jun 2014 17:04:27 -0700 Subject: RFR: 8037742 & 8041142: solaris sunpkcs11 config changes In-Reply-To: <538CF227.3070801@oracle.com> References: <538CD1DC.4030605@oracle.com> <538CF227.3070801@oracle.com> Message-ID: <538D110B.3010704@oracle.com> Thanks Tony On 06/02/2014 02:52 PM, Valerie (Yu-Ching) Peng wrote: > > Looks fine. > Valerie > > On 06/02/14 12:34, Anthony Scarpino wrote: >> Him >> >> I need review of two very simple config file changes to enable >> algorithms for Solaris PKCS#11 that were disabled due to fixed Solaris >> bugs or old SPARC hardware performance issues. >> >> http://cr.openjdk.java.net/~ascarpino/8037742/webrev/ >> http://cr.openjdk.java.net/~ascarpino/8041142/webrev/ >> >> thanks >> >> Tony > From weijun.wang at oracle.com Wed Jun 4 06:21:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Jun 2014 14:21:34 +0800 Subject: RFR 8044755: Add a test for algorithm constraints check in jarsigner Message-ID: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> Please review a new test at http://cr.openjdk.java.net/~weijun/8044755/webrev.00/ It makes sure the CertPath validation check in jarsigner matches the algorithm constraints check on key sizes. Thanks Max From xuelei.fan at oracle.com Wed Jun 4 08:20:30 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 04 Jun 2014 16:20:30 +0800 Subject: RFR 8044755: Add a test for algorithm constraints check in jarsigner In-Reply-To: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> References: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> Message-ID: <538ED6CE.8060501@oracle.com> Looks fine to me. FYI, I'd like to remove the temporary files (a.jar, ks, etc) after a testing. Xuelei On 6/4/2014 2:21 PM, Wang Weijun wrote: > Please review a new test at > > http://cr.openjdk.java.net/~weijun/8044755/webrev.00/ > > It makes sure the CertPath validation check in jarsigner matches the algorithm constraints check on key sizes. > > Thanks > Max > From weijun.wang at oracle.com Wed Jun 4 08:26:39 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Jun 2014 16:26:39 +0800 Subject: RFR 8044755: Add a test for algorithm constraints check in jarsigner In-Reply-To: <538ED6CE.8060501@oracle.com> References: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> <538ED6CE.8060501@oracle.com> Message-ID: Oh, I was just updating the webrev to http://cr.openjdk.java.net/~weijun/8044755/webrev.01/ As we've just discussed offline, the reason the 2nd jarsigner call fails is a double weakness, not only the signer's key is 512 bit, but also signer's cert is signed by a 512 key (of CA). Therefore I update the test to use a weak signature alg -- MD2withRSA. This time I believe the weakness of CA's cert won't infect the its signature when signing signer. Thanks Max On Jun 4, 2014, at 16:20, Xuelei Fan wrote: > Looks fine to me. > > FYI, I'd like to remove the temporary files (a.jar, ks, etc) after a > testing. > > Xuelei > > On 6/4/2014 2:21 PM, Wang Weijun wrote: >> Please review a new test at >> >> http://cr.openjdk.java.net/~weijun/8044755/webrev.00/ >> >> It makes sure the CertPath validation check in jarsigner matches the algorithm constraints check on key sizes. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Wed Jun 4 08:41:12 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Jun 2014 16:41:12 +0800 Subject: RFR 8044755: Add a test for algorithm constraints check in jarsigner In-Reply-To: <538ED6CE.8060501@oracle.com> References: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> <538ED6CE.8060501@oracle.com> Message-ID: <1A36C254-2189-4F49-9DC2-C4A617B73E78@oracle.com> On Jun 4, 2014, at 16:20, Xuelei Fan wrote: > FYI, I'd like to remove the temporary files (a.jar, ks, etc) after a > testing. Oh, my habit is to always keeping them so that if anything goes wrong there is a chance to look at what's happening. Also, jtreg takes care of removing or retaining them so I am happy with it. Yes, I can remove them only when the test succeeds but it will be complex. Sometimes I even want to look at the files when it's a success. There is only one case cleaning up is necessary, that's when the test includes multiple @run actions. The automatic clean up is only performed once at the end. Thanks Max From xuelei.fan at oracle.com Wed Jun 4 09:11:18 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 04 Jun 2014 17:11:18 +0800 Subject: RFR 8044755: Add a test for algorithm constraints check in jarsigner In-Reply-To: References: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> <538ED6CE.8060501@oracle.com> Message-ID: <538EE2B6.60206@oracle.com> Ok. > Oh, my habit is to always keeping them so that if anything goes > wrong ... Ok. Xuelei On 6/4/2014 4:26 PM, Wang Weijun wrote: > Oh, I was just updating the webrev to > > http://cr.openjdk.java.net/~weijun/8044755/webrev.01/ > > As we've just discussed offline, the reason the 2nd jarsigner call fails is a double weakness, not only the signer's key is 512 bit, but also signer's cert is signed by a 512 key (of CA). > > Therefore I update the test to use a weak signature alg -- MD2withRSA. This time I believe the weakness of CA's cert won't infect the its signature when signing signer. > > Thanks > Max > > On Jun 4, 2014, at 16:20, Xuelei Fan wrote: > >> Looks fine to me. >> >> FYI, I'd like to remove the temporary files (a.jar, ks, etc) after a >> testing. >> >> Xuelei >> >> On 6/4/2014 2:21 PM, Wang Weijun wrote: >>> Please review a new test at >>> >>> http://cr.openjdk.java.net/~weijun/8044755/webrev.00/ >>> >>> It makes sure the CertPath validation check in jarsigner matches the algorithm constraints check on key sizes. >>> >>> Thanks >>> Max >>> >> > From xuelei.fan at oracle.com Wed Jun 4 09:38:37 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 04 Jun 2014 17:38:37 +0800 Subject: Code review request, 8044771, PKIXValidator indent cleanup Message-ID: <538EE91D.9060802@oracle.com> Hi, Please review this code conversion cleanup update: http://cr.openjdk.java.net/~xuelei/8044771/webrev.00/ Webrev toolkit ignore space update so the webrev above looks strange. The major update is cleanup the indentation. For example, 4 leading space are removed at line 250 of PKIXValidator.java. Thanks, Xuelei From weijun.wang at oracle.com Wed Jun 4 09:46:05 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Jun 2014 17:46:05 +0800 Subject: Code review request, 8044771, PKIXValidator indent cleanup In-Reply-To: <538EE91D.9060802@oracle.com> References: <538EE91D.9060802@oracle.com> Message-ID: Looks fine. Please remember to add a noreg-cleanup to JBS. Thanks Max On Jun 4, 2014, at 17:38, Xuelei Fan wrote: > Hi, > > Please review this code conversion cleanup update: > > http://cr.openjdk.java.net/~xuelei/8044771/webrev.00/ > > Webrev toolkit ignore space update so the webrev above looks strange. > The major update is cleanup the indentation. For example, 4 leading > space are removed at line 250 of PKIXValidator.java. > > Thanks, > Xuelei From henry.jen at oracle.com Wed Jun 4 17:52:08 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 04 Jun 2014 10:52:08 -0700 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538E74B8.20603@oracle.com> References: <538E74B8.20603@oracle.com> Message-ID: <538F5CC8.3050702@oracle.com> Thanks for all reviewing and feedbacks on core-libs-dev[1], I tried to respond to feedbacks with this email and send off to other mailing lists. I am wondering if jdk9-dev is the appropriate list for such a trivious but broad change, so that we can have one instead of many lists, and we still probably miss another. Lets follow up this thread on jdk9-dev. Regarding to whether we should keep JDK, the later convention is 1.#, and as David pointed out the document also list @since that way, I think we should settle on that. For other standards such as SAX or JCE, I propose to convert them to the version of JDK those APIs are included. To retain that information, we can introduce a custom tag, perhaps @standard or @conformingTo? @conformingTo [, ]* For example, @conformingTo SAX 2.0. Repo wise, I think it's best if I can commit to jdk9/dev as a single commit instead of scattering to dev and client. But I can cope if this is absolutely necessary. Some changes to implementation classes, as I mentioned, only when it is straightforward. Essentially, I did a s/(@since *)JDK(.*)/\1\2 against all files. Some changes not obvious are simply remove tailing space, a (positive) side effect of the tools I use so I kept them. Cheers, Henry [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027113.html On 06/03/2014 06:22 PM, Henry Jen wrote: > Hi, > > In an effort to determine APIs availability in a given version, it > became obvious that a consistent way to express @since tag would be > beneficial. > > So started with the most obvious ones, where we have various expression > for JDK version, this webrev make sure we use @since 1.n[.n] for JDK > versions. > > The main focus is on public APIs, private ones are taken care if it is > straightforward, otherwise, we try to keep the information. > > Some public APIs are using @since format, > they are also preserved for now, but I think it worth discussion whether > we want to change to the version as included in J2SE. > > There are APIs without @since information, separate webrevs will be > coming to complete those information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > The webrev can be found at > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > but it's probably easier just look into the raw diff, > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > > Cheers, > Henry From bradford.wetmore at oracle.com Wed Jun 4 18:00:57 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 04 Jun 2014 11:00:57 -0700 Subject: Code review request, 8044771, PKIXValidator indent cleanup In-Reply-To: <538EE91D.9060802@oracle.com> References: <538EE91D.9060802@oracle.com> Message-ID: <538F5ED9.2070903@oracle.com> On 6/4/2014 2:38 AM, Xuelei Fan wrote: > Webrev toolkit ignore space update so the webrev above looks strange. > The major update is cleanup the indentation. For example, 4 leading > space are removed at line 250 of PKIXValidator.java. Use the -b option in webrev to force whitespace changes to appear. Brad From xuelei.fan at oracle.com Wed Jun 4 22:41:06 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 05 Jun 2014 06:41:06 +0800 Subject: Code review request, 8044771, PKIXValidator indent cleanup In-Reply-To: <538F5ED9.2070903@oracle.com> References: <538EE91D.9060802@oracle.com> <538F5ED9.2070903@oracle.com> Message-ID: <538FA082.2080706@oracle.com> On 6/5/2014 2:00 AM, Bradford Wetmore wrote: > > On 6/4/2014 2:38 AM, Xuelei Fan wrote: >> Webrev toolkit ignore space update so the webrev above looks strange. >> The major update is cleanup the indentation. For example, 4 leading >> space are removed at line 250 of PKIXValidator.java. > > Use the -b option in webrev to force whitespace changes to appear. > Thanks! Xuelei From jamil.j.nimeh at oracle.com Wed Jun 4 23:29:50 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 04 Jun 2014 16:29:50 -0700 Subject: Webrev request: JDK-8015081 In-Reply-To: <53853393.6020108@oracle.com> References: <53853393.6020108@oracle.com> Message-ID: <538FABEE.5070902@oracle.com> Hello all, This is an update to the webrev for JDK-8015081 that takes into account review changes and adds a few more tests. http://cr.openjdk.java.net/~ascarpino/8015081/webrev.03 Thanks! --Jamil On 05/27/2014 05:53 PM, Jamil Nimeh wrote: > Hello all, > > This bug was originally to resolve issues where Subject principal and > credential Set fields containing null elements could cause > NullPointerException to be thrown. It was decided to make the Subject > throw NullPointerException when attempts to construct or modify > Subjects will null elements. In addition, certain Set methods called > upon principals and credentials where the input Collection contained > null elements could have different effects depending on which set. > These methods, when called with Collections containing null elements > as input now throw NullPointerException as well. > > Operation Before After > (Prin/Pub/Priv) (Prin/Pub/Priv) (Prin/Pub/Priv) > ---------------------------------------------------------------------------- > > add(null) SecurityException/true/true NPE/NPE/NPE > remove(null) false/false/false (*) NPE/NPE/NPE > contains(null) false/false/false (*) NPE/NPE/NPE > addAll(collection w/ null) SecurityException/true/true NPE/NPE/NPE > removeAll(collection w/ null) true/true/true (**) NPE/NPE/NPE > containsAll(coll. w/ null) false/false/NPE NPE/NPE/NPE > retainAll(collection w/ null) true/true/true (***) NPE/NPE/NPE > > * - Assumes Subject has no null values in its private SecureSet > collections > ** - Assumes input collection has at least one non-null element that > exists in the target SecureSet > *** - Assumes input collection is not equivalent to or a superset of > the target SecureSet (which would cause no change) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8015081 > Webrev: http://cr.openjdk.java.net/~ascarpino/8015081/webrev.02 > > Thanks, > --Jamil From weijun.wang at oracle.com Thu Jun 5 07:24:10 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Jun 2014 15:24:10 +0800 Subject: RFR 8044755: Add a test for algorithm constraints check in jarsigner In-Reply-To: References: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> <538ED6CE.8060501@oracle.com> Message-ID: <211ADEE5-C215-4F94-936C-501D3903893B@oracle.com> On Jun 4, 2014, at 16:26, Wang Weijun wrote: > Oh, I was just updating the webrev to > > http://cr.openjdk.java.net/~weijun/8044755/webrev.01/ Are you OK with this 2nd version of webrev? Thanks Max > > As we've just discussed offline, the reason the 2nd jarsigner call fails is a double weakness, not only the signer's key is 512 bit, but also signer's cert is signed by a 512 key (of CA). > > Therefore I update the test to use a weak signature alg -- MD2withRSA. This time I believe the weakness of CA's cert won't infect the its signature when signing signer. > > Thanks > Max > > On Jun 4, 2014, at 16:20, Xuelei Fan wrote: > >> Looks fine to me. >> >> FYI, I'd like to remove the temporary files (a.jar, ks, etc) after a >> testing. >> >> Xuelei >> >> On 6/4/2014 2:21 PM, Wang Weijun wrote: >>> Please review a new test at >>> >>> http://cr.openjdk.java.net/~weijun/8044755/webrev.00/ >>> >>> It makes sure the CertPath validation check in jarsigner matches the algorithm constraints check on key sizes. >>> >>> Thanks >>> Max >>> >> > From xuelei.fan at oracle.com Thu Jun 5 07:24:59 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 05 Jun 2014 15:24:59 +0800 Subject: RFR 8044755: Add a test for algorithm constraints check in jarsigner In-Reply-To: <211ADEE5-C215-4F94-936C-501D3903893B@oracle.com> References: <2CF215DD-28EE-4019-A130-03BB37E71652@oracle.com> <538ED6CE.8060501@oracle.com> <211ADEE5-C215-4F94-936C-501D3903893B@oracle.com> Message-ID: <53901B4B.40209@oracle.com> On 6/5/2014 3:24 PM, Wang Weijun wrote: > > On Jun 4, 2014, at 16:26, Wang Weijun wrote: > >> Oh, I was just updating the webrev to >> >> http://cr.openjdk.java.net/~weijun/8044755/webrev.01/ > > Are you OK with this 2nd version of webrev? > Ok. Xuelei > Thanks > Max > >> >> As we've just discussed offline, the reason the 2nd jarsigner call fails is a double weakness, not only the signer's key is 512 bit, but also signer's cert is signed by a 512 key (of CA). >> >> Therefore I update the test to use a weak signature alg -- MD2withRSA. This time I believe the weakness of CA's cert won't infect the its signature when signing signer. >> >> Thanks >> Max >> >> On Jun 4, 2014, at 16:20, Xuelei Fan wrote: >> >>> Looks fine to me. >>> >>> FYI, I'd like to remove the temporary files (a.jar, ks, etc) after a >>> testing. >>> >>> Xuelei >>> >>> On 6/4/2014 2:21 PM, Wang Weijun wrote: >>>> Please review a new test at >>>> >>>> http://cr.openjdk.java.net/~weijun/8044755/webrev.00/ >>>> >>>> It makes sure the CertPath validation check in jarsigner matches the algorithm constraints check on key sizes. >>>> >>>> Thanks >>>> Max >>>> >>> >> > From sean.mullan at oracle.com Thu Jun 5 19:49:09 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 05 Jun 2014 15:49:09 -0400 Subject: Locking/Singleton in JCAUtil In-Reply-To: <20140523023413.000071eb.ecki@zusammenkunft.net> References: <20140523023413.000071eb.ecki@zusammenkunft.net> Message-ID: <5390C9B5.30908@oracle.com> On 05/22/2014 08:34 PM, Bernd Eckenfels wrote: > Hello, > > by browsing the source code I run across the JCAUtil class. It is > (among other stuff) responsible for providing a SecureRandom singleton. > The code looks a bit strange. > > First of all, it defines a LOCK object, but instead of using an > unreachable instancde (which is a common pattern for those kind of LOCK > objects) it uses the public class itself: > > private static final Object LOCK = JCAUtil.class; > > Typical this would be a problem as I can lock up the class. In this > specific case the LOCK is only used in one place, and there it is used > for a double checked locking, which is I guess good as it only checks > the monitor before any user code can lock it. Nevertheless, I would > recommend to change this to a more common pattern (or remove the field > and us synchronized(JCAUtil.class) to make it more explicite. > > Another option would be to get rid of all the volatile/lock/DCL by > having a static initialisation. If this is not possible for dependency > reasons, I would have expected a comment like "this needs to be lazy > because..." > > With final and without volatile it also looks more predictable: > > private static final SecureRandom secureRandom = new SecureRandom(); > public static SecureRandom getSecureRandom() { return secureRandom; } > > WDYT? That would work, but then you lose the performance benefits of the existing code, which only creates the SecureRandom object if the getSecureRandom method is called. I think that using the Initialization-on-demand pattern [1] is a better solution which avoids the locking and is thread-safe. When this code was written, it probably wasn't a well-known pattern. --Sean [1] http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom From sean.mullan at oracle.com Thu Jun 5 21:06:15 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 05 Jun 2014 17:06:15 -0400 Subject: Webrev request: JDK-8015081 In-Reply-To: <538FABEE.5070902@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> Message-ID: <5390DBC7.9060405@oracle.com> On 06/04/2014 07:29 PM, Jamil Nimeh wrote: > Hello all, > > This is an update to the webrev for JDK-8015081 that takes into account > review changes and adds a few more tests. > > http://cr.openjdk.java.net/~ascarpino/8015081/webrev.03 > [1012] // A null-hostile collection may choose to return null if I think you meant to say "may choose to throw NPE if" Looks good otherwise! --Sean > > Thanks! > --Jamil > > On 05/27/2014 05:53 PM, Jamil Nimeh wrote: >> Hello all, >> >> This bug was originally to resolve issues where Subject principal and >> credential Set fields containing null elements could cause >> NullPointerException to be thrown. It was decided to make the Subject >> throw NullPointerException when attempts to construct or modify >> Subjects will null elements. In addition, certain Set methods called >> upon principals and credentials where the input Collection contained >> null elements could have different effects depending on which set. >> These methods, when called with Collections containing null elements >> as input now throw NullPointerException as well. >> >> Operation Before After >> (Prin/Pub/Priv) (Prin/Pub/Priv) (Prin/Pub/Priv) >> ---------------------------------------------------------------------------- >> >> add(null) SecurityException/true/true NPE/NPE/NPE >> remove(null) false/false/false (*) NPE/NPE/NPE >> contains(null) false/false/false (*) NPE/NPE/NPE >> addAll(collection w/ null) SecurityException/true/true NPE/NPE/NPE >> removeAll(collection w/ null) true/true/true (**) NPE/NPE/NPE >> containsAll(coll. w/ null) false/false/NPE NPE/NPE/NPE >> retainAll(collection w/ null) true/true/true (***) NPE/NPE/NPE >> >> * - Assumes Subject has no null values in its private SecureSet >> collections >> ** - Assumes input collection has at least one non-null element that >> exists in the target SecureSet >> *** - Assumes input collection is not equivalent to or a superset of >> the target SecureSet (which would cause no change) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8015081 >> Webrev: http://cr.openjdk.java.net/~ascarpino/8015081/webrev.02 >> >> Thanks, >> --Jamil > From weijun.wang at oracle.com Fri Jun 6 07:27:23 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Jun 2014 15:27:23 +0800 Subject: RFR 8023197: Pre-configured command line options for keytool and jarsigner Message-ID: <741090C5-D7D8-4B09-B389-46273D0C53D4@oracle.com> Please review the code changes in http://cr.openjdk.java.net/~weijun/8023197/webrev.02 This enhancement allows you to put frequently used keytool/jarsigner options into a property file and use -conf to load it. Like this: # A Pre-configured options file keytool.all = -storepass:env PASS -keypass:env PASS -keystore ${user.dir}/.p12 -storetype pkcs12 keytool.genkeypair = -keyalg rsa -keysize 2048 -sigalg SHA256withRSA -validity 365 Thanks Max From weijun.wang at oracle.com Fri Jun 6 08:58:19 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Jun 2014 16:58:19 +0800 Subject: RFR: 8044747: [TESTBUG] Test sun/security/tools/policytool/i18n.sh fails after clicking 'Done' button in test frame Message-ID: <6A5A5C3D-4B75-4044-AD49-8F98EF88E033@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8044747/webrev.00 which is just a simple -if [ -e $HOME/.java.policy ]; then +if [ -f $HOME/.java.policy ]; then I always forget that Solaris sh does not support test -e. Thanks Max From xuelei.fan at oracle.com Fri Jun 6 11:04:39 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 06 Jun 2014 19:04:39 +0800 Subject: RFR: 8044747: [TESTBUG] Test sun/security/tools/policytool/i18n.sh fails after clicking 'Done' button in test frame In-Reply-To: <6A5A5C3D-4B75-4044-AD49-8F98EF88E033@oracle.com> References: <6A5A5C3D-4B75-4044-AD49-8F98EF88E033@oracle.com> Message-ID: <5391A047.60803@oracle.com> Looks fine to me. Xuelei On 6/6/2014 4:58 PM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8044747/webrev.00 > > which is just a simple > > -if [ -e $HOME/.java.policy ]; then > +if [ -f $HOME/.java.policy ]; then > > I always forget that Solaris sh does not support test -e. > > Thanks > Max > From xuelei.fan at oracle.com Fri Jun 6 12:22:41 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 06 Jun 2014 20:22:41 +0800 Subject: RFR 8023197: Pre-configured command line options for keytool and jarsigner In-Reply-To: <741090C5-D7D8-4B09-B389-46273D0C53D4@oracle.com> References: <741090C5-D7D8-4B09-B389-46273D0C53D4@oracle.com> Message-ID: <5391B291.3020108@oracle.com> src/share/classes/sun/security/tools/KeyStoreUtil.java ====================================================== 224 throw new IOException("Cannot have both " + c1 + " and " + c2); "Cannot have both pre-configured options ..."? 176 st.whitespaceChars(0x00, 0x20); 177 st.wordChars(0x21, 0xFF); I'm not sure of the code above, would you like have to test for none-ASCII characters? 194 * @param c1 the name of the command, must not be null 195 * @param c2 the alternative command name, null if none. Mention that c1 and c2 need to come with leading '-'? src/share/classes/sun/security/tools/jarsigner/Main.java ======================================================== 293 for (n=0; n < args.length; n++) { Break after the found of the target options? 313 System.out.println("Command line args: " + Define a new resource? src/share/classes/sun/security/tools/keytool/Main.java 404 for (i=0; i < args.length; i++) { Break after the found of the target options? Or loop from the end of the array? 429 System.out.println("Command line args: " + Define a new resource? Otherwise, looks fine to me. Thanks, Xuelei On 6/6/2014 3:27 PM, Wang Weijun wrote: > Please review the code changes in > > http://cr.openjdk.java.net/~weijun/8023197/webrev.02 > > This enhancement allows you to put frequently used keytool/jarsigner options into a property file and use -conf to load it. Like this: > > # A Pre-configured options file > keytool.all = -storepass:env PASS -keypass:env PASS -keystore ${user.dir}/.p12 -storetype pkcs12 > keytool.genkeypair = -keyalg rsa -keysize 2048 -sigalg SHA256withRSA -validity 365 > > Thanks > Max > From jamil.j.nimeh at oracle.com Fri Jun 6 22:16:35 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 06 Jun 2014 15:16:35 -0700 Subject: Webrev request: JDK-8015081 In-Reply-To: <538FABEE.5070902@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> Message-ID: <53923DC3.2080107@oracle.com> One more version of this webrev with minor comment changes: http://cr.openjdk.java.net/~ascarpino/8015081/webrev.04 Thanks, --Jamil On 06/04/2014 04:29 PM, Jamil Nimeh wrote: > Hello all, > > This is an update to the webrev for JDK-8015081 that takes into > account review changes and adds a few more tests. > > http://cr.openjdk.java.net/~ascarpino/8015081/webrev.03 > > > Thanks! > --Jamil > > On 05/27/2014 05:53 PM, Jamil Nimeh wrote: >> Hello all, >> >> This bug was originally to resolve issues where Subject principal and >> credential Set fields containing null elements could cause >> NullPointerException to be thrown. It was decided to make the >> Subject throw NullPointerException when attempts to construct or >> modify Subjects will null elements. In addition, certain Set methods >> called upon principals and credentials where the input Collection >> contained null elements could have different effects depending on >> which set. These methods, when called with Collections containing >> null elements as input now throw NullPointerException as well. >> >> Operation Before After >> (Prin/Pub/Priv) (Prin/Pub/Priv) (Prin/Pub/Priv) >> ---------------------------------------------------------------------------- >> >> add(null) SecurityException/true/true NPE/NPE/NPE >> remove(null) false/false/false (*) NPE/NPE/NPE >> contains(null) false/false/false (*) NPE/NPE/NPE >> addAll(collection w/ null) SecurityException/true/true NPE/NPE/NPE >> removeAll(collection w/ null) true/true/true (**) NPE/NPE/NPE >> containsAll(coll. w/ null) false/false/NPE NPE/NPE/NPE >> retainAll(collection w/ null) true/true/true (***) NPE/NPE/NPE >> >> * - Assumes Subject has no null values in its private SecureSet >> collections >> ** - Assumes input collection has at least one non-null element that >> exists in the target SecureSet >> *** - Assumes input collection is not equivalent to or a superset of >> the target SecureSet (which would cause no change) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8015081 >> Webrev: http://cr.openjdk.java.net/~ascarpino/8015081/webrev.02 >> >> Thanks, >> --Jamil > From anthony.scarpino at oracle.com Tue Jun 10 02:53:33 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 9 Jun 2014 19:53:33 -0700 Subject: RFR: 8039212 SecretKeyBasic.sh needs to avoid NSS libnss3 and libsoftokn3 version mismatches Message-ID: <16F2ACDE-E771-4B47-B5D7-A96590EC0011@oracle.com> Hi, I need a review to address a failure in the SecretKeyBasic test. If the libnss3 and libsoftokn3 do not match we skip this test. http://cr.openjdk.java.net/~ascarpino/8039212/webrev.00/ thanks Tony From weijun.wang at oracle.com Tue Jun 10 04:37:16 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 Jun 2014 12:37:16 +0800 Subject: RFR 8023197: Pre-configured command line options for keytool and jarsigner In-Reply-To: <5391B291.3020108@oracle.com> References: <741090C5-D7D8-4B09-B389-46273D0C53D4@oracle.com> <5391B291.3020108@oracle.com> Message-ID: <78ED9AAA-5D98-4A57-9386-85DE64EF96DF@oracle.com> On Jun 6, 2014, at 20:22, Xuelei Fan wrote: > src/share/classes/sun/security/tools/KeyStoreUtil.java > ====================================================== > 224 throw new IOException("Cannot have both " + c1 + " and " + c2); > "Cannot have both pre-configured options ..."? This means you cannot define both "keytool.genkeypair" and "keytool.genkey". -genkey is an obsolete command name but we still support it secretly. > > 176 st.whitespaceChars(0x00, 0x20); > 177 st.wordChars(0x21, 0xFF); > I'm not sure of the code above, would you like have to test for > none-ASCII characters? I cannot find any spec on this, but the source has ctype = c < 256 ? ct[c] : CT_ALPHA; which means every non-ASCII is a word char (no support for wide numerals). StreamTokenizer only allows you to categorize the ASCII chars. > > 194 * @param c1 the name of the command, must not be null > 195 * @param c2 the alternative command name, null if none. > Mention that c1 and c2 need to come with leading '-'? I'll add "with the "-" prefix". > > src/share/classes/sun/security/tools/jarsigner/Main.java > ======================================================== > 293 for (n=0; n < args.length; n++) { > Break after the found of the target options? I'm looking for both -conf and -verify (and their last appearances). It will be complex to maintain two flags. > > 313 System.out.println("Command line args: " + > Define a new resource? I suppose it's not necessary to localize debug outputs. The -debug option is also not documented. > > src/share/classes/sun/security/tools/keytool/Main.java > 404 for (i=0; i < args.length; i++) { > Break after the found of the target options? Or loop from the end of > the array? Same reason as above. > > 429 System.out.println("Command line args: " + > Define a new resource? Same reason as above. Thanks Max > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > On 6/6/2014 3:27 PM, Wang Weijun wrote: >> Please review the code changes in >> >> http://cr.openjdk.java.net/~weijun/8023197/webrev.02 >> >> This enhancement allows you to put frequently used keytool/jarsigner options into a property file and use -conf to load it. Like this: >> >> # A Pre-configured options file >> keytool.all = -storepass:env PASS -keypass:env PASS -keystore ${user.dir}/.p12 -storetype pkcs12 >> keytool.genkeypair = -keyalg rsa -keysize 2048 -sigalg SHA256withRSA -validity 365 >> >> Thanks >> Max >> > From jamil.j.nimeh at oracle.com Tue Jun 10 06:01:51 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 09 Jun 2014 23:01:51 -0700 Subject: RFR: JDK-8046368 Message-ID: <53969F4F.4020206@oracle.com> Hello all, These are some minor clean-up changes in SeedGenerator.java that were found while fixing a different issue. http://cr.openjdk.java.net/~xuelei/7176176/webrev.01 Thank you, --Jamil From xuelei.fan at oracle.com Tue Jun 10 06:01:52 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Jun 2014 14:01:52 +0800 Subject: RFR 8023197: Pre-configured command line options for keytool and jarsigner In-Reply-To: <78ED9AAA-5D98-4A57-9386-85DE64EF96DF@oracle.com> References: <741090C5-D7D8-4B09-B389-46273D0C53D4@oracle.com> <5391B291.3020108@oracle.com> <78ED9AAA-5D98-4A57-9386-85DE64EF96DF@oracle.com> Message-ID: <53969F50.5000703@oracle.com> On 6/10/2014 12:37 PM, Wang Weijun wrote: > > On Jun 6, 2014, at 20:22, Xuelei Fan wrote: > >> src/share/classes/sun/security/tools/KeyStoreUtil.java >> ====================================================== >> 224 throw new IOException("Cannot have both " + c1 + " and " + c2); >> "Cannot have both pre-configured options ..."? > > This means you cannot define both "keytool.genkeypair" and "keytool.genkey". -genkey is an obsolete command name but we still support it secretly. > I mean you may want to mention that this exception occurs in "pre-configured options". >> >> 176 st.whitespaceChars(0x00, 0x20); >> 177 st.wordChars(0x21, 0xFF); >> I'm not sure of the code above, would you like have to test for >> none-ASCII characters? > > I cannot find any spec on this, but the source has > > ctype = c < 256 ? ct[c] : CT_ALPHA; > > which means every non-ASCII is a word char (no support for wide numerals). > > StreamTokenizer only allows you to categorize the ASCII chars. > I'm not sure too. If "0x01 0x05" is a character, does the above code treat the "0x01" and "0x05" as white space? Here is a Unicode table: http://www.tamasoft.co.jp/en/general-info/unicode.html >> >> 194 * @param c1 the name of the command, must not be null >> 195 * @param c2 the alternative command name, null if none. >> Mention that c1 and c2 need to come with leading '-'? > > I'll add "with the "-" prefix". > >> >> src/share/classes/sun/security/tools/jarsigner/Main.java >> ======================================================== >> 293 for (n=0; n < args.length; n++) { >> Break after the found of the target options? > > I'm looking for both -conf and -verify (and their last appearances). It will be complex to maintain two flags. > One int flag (0, 1, 2) should be enough, and simple. >> >> 313 System.out.println("Command line args: " + >> Define a new resource? > > I suppose it's not necessary to localize debug outputs. The -debug option is also not documented. > OK, please add a comment line. >> >> src/share/classes/sun/security/tools/keytool/Main.java >> 404 for (i=0; i < args.length; i++) { >> Break after the found of the target options? Or loop from the end of >> the array? > > Same reason as above. > See above. >> >> 429 System.out.println("Command line args: " + >> Define a new resource? > > Same reason as above. > See above. Xuelei > Thanks > Max > >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> On 6/6/2014 3:27 PM, Wang Weijun wrote: >>> Please review the code changes in >>> >>> http://cr.openjdk.java.net/~weijun/8023197/webrev.02 >>> >>> This enhancement allows you to put frequently used keytool/jarsigner options into a property file and use -conf to load it. Like this: >>> >>> # A Pre-configured options file >>> keytool.all = -storepass:env PASS -keypass:env PASS -keystore ${user.dir}/.p12 -storetype pkcs12 >>> keytool.genkeypair = -keyalg rsa -keysize 2048 -sigalg SHA256withRSA -validity 365 >>> >>> Thanks >>> Max >>> >> > From weijun.wang at oracle.com Tue Jun 10 06:17:55 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 Jun 2014 14:17:55 +0800 Subject: RFR 8023197: Pre-configured command line options for keytool and jarsigner In-Reply-To: <53969F50.5000703@oracle.com> References: <741090C5-D7D8-4B09-B389-46273D0C53D4@oracle.com> <5391B291.3020108@oracle.com> <78ED9AAA-5D98-4A57-9386-85DE64EF96DF@oracle.com> <53969F50.5000703@oracle.com> Message-ID: On Jun 10, 2014, at 14:01, Xuelei Fan wrote: > On 6/10/2014 12:37 PM, Wang Weijun wrote: >> >> On Jun 6, 2014, at 20:22, Xuelei Fan wrote: >> >>> src/share/classes/sun/security/tools/KeyStoreUtil.java >>> ====================================================== >>> 224 throw new IOException("Cannot have both " + c1 + " and " + c2); >>> "Cannot have both pre-configured options ..."? >> >> This means you cannot define both "keytool.genkeypair" and "keytool.genkey". -genkey is an obsolete command name but we still support it secretly. >> > I mean you may want to mention that this exception occurs in > "pre-configured options". OK. > >>> >>> 176 st.whitespaceChars(0x00, 0x20); >>> 177 st.wordChars(0x21, 0xFF); >>> I'm not sure of the code above, would you like have to test for >>> none-ASCII characters? >> >> I cannot find any spec on this, but the source has >> >> ctype = c < 256 ? ct[c] : CT_ALPHA; >> >> which means every non-ASCII is a word char (no support for wide numerals). >> >> StreamTokenizer only allows you to categorize the ASCII chars. >> > I'm not sure too. If "0x01 0x05" is a character, does the above code > treat the "0x01" and "0x05" as white space? Here the input of StreamTokenizer is char array. If you mean "0x01 0x05" as two chars, then they are both treated as white spaces. If you mean \u0105, it's a word char. > > Here is a Unicode table: > http://www.tamasoft.co.jp/en/general-info/unicode.html > >>> >>> 194 * @param c1 the name of the command, must not be null >>> 195 * @param c2 the alternative command name, null if none. >>> Mention that c1 and c2 need to come with leading '-'? >> >> I'll add "with the "-" prefix". >> >>> >>> src/share/classes/sun/security/tools/jarsigner/Main.java >>> ======================================================== >>> 293 for (n=0; n < args.length; n++) { >>> Break after the found of the target options? >> >> I'm looking for both -conf and -verify (and their last appearances). It will be complex to maintain two flags. >> > One int flag (0, 1, 2) should be enough, and simple. The two flags are independent, yes, I can use 2 bits of an int int found = 0; for (int i=len-1; i>=0 && found < 3; i--) { if (found & 1 == 0) { if (is -conf) { conf = next arg; found |= 1; } } if (found & 2 == 0) { if (is -verify) { verify = true; found |= 2; } } } and iterating through the arg list is fast. > >>> >>> 313 System.out.println("Command line args: " + >>> Define a new resource? >> >> I suppose it's not necessary to localize debug outputs. The -debug option is also not documented. >> > OK, please add a comment line. OK. Thanks Max > >>> >>> src/share/classes/sun/security/tools/keytool/Main.java >>> 404 for (i=0; i < args.length; i++) { >>> Break after the found of the target options? Or loop from the end of >>> the array? >> >> Same reason as above. >> > See above. > >>> >>> 429 System.out.println("Command line args: " + >>> Define a new resource? >> >> Same reason as above. >> > See above. > > Xuelei > >> Thanks >> Max >> >>> >>> Otherwise, looks fine to me. >>> >>> Thanks, >>> Xuelei >>> >>> On 6/6/2014 3:27 PM, Wang Weijun wrote: >>>> Please review the code changes in >>>> >>>> http://cr.openjdk.java.net/~weijun/8023197/webrev.02 >>>> >>>> This enhancement allows you to put frequently used keytool/jarsigner options into a property file and use -conf to load it. Like this: >>>> >>>> # A Pre-configured options file >>>> keytool.all = -storepass:env PASS -keypass:env PASS -keystore ${user.dir}/.p12 -storetype pkcs12 >>>> keytool.genkeypair = -keyalg rsa -keysize 2048 -sigalg SHA256withRSA -validity 365 >>>> >>>> Thanks >>>> Max From xuelei.fan at oracle.com Tue Jun 10 08:13:09 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Jun 2014 16:13:09 +0800 Subject: RFR 8023197: Pre-configured command line options for keytool and jarsigner In-Reply-To: References: <741090C5-D7D8-4B09-B389-46273D0C53D4@oracle.com> <5391B291.3020108@oracle.com> <78ED9AAA-5D98-4A57-9386-85DE64EF96DF@oracle.com> <53969F50.5000703@oracle.com> Message-ID: <5396BE15.5020609@oracle.com> On 6/10/2014 2:17 PM, Wang Weijun wrote: >>>> >>> 176 st.whitespaceChars(0x00, 0x20); >>>> >>> 177 st.wordChars(0x21, 0xFF); >>>> >>> I'm not sure of the code above, would you like have to test for >>>> >>> none-ASCII characters? >>> >> >>> >> I cannot find any spec on this, but the source has >>> >> >>> >> ctype = c < 256 ? ct[c] : CT_ALPHA; >>> >> >>> >> which means every non-ASCII is a word char (no support for wide numerals). >>> >> >>> >> StreamTokenizer only allows you to categorize the ASCII chars. >>> >> >> > I'm not sure too. If "0x01 0x05" is a character, does the above code >> > treat the "0x01" and "0x05" as white space? > Here the input of StreamTokenizer is char array. If you mean "0x01 0x05" as two chars, then they are both treated as white spaces. If you mean \u0105, it's a word char. > OK. Xuelei From vincent.x.ryan at oracle.com Tue Jun 10 10:16:20 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 10 Jun 2014 11:16:20 +0100 Subject: RFR: 8039212 SecretKeyBasic.sh needs to avoid NSS libnss3 and libsoftokn3 version mismatches In-Reply-To: <16F2ACDE-E771-4B47-B5D7-A96590EC0011@oracle.com> References: <16F2ACDE-E771-4B47-B5D7-A96590EC0011@oracle.com> Message-ID: <069489A1-9A11-4393-A232-BAA117AAA7A4@oracle.com> This looks fine until the NSS issue is resolved. On 10 Jun 2014, at 03:53, Anthony Scarpino wrote: > Hi, > > I need a review to address a failure in the SecretKeyBasic test. If the libnss3 and libsoftokn3 do not match we skip this test. > > http://cr.openjdk.java.net/~ascarpino/8039212/webrev.00/ > > thanks > > Tony > From sean.mullan at oracle.com Tue Jun 10 12:07:10 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 Jun 2014 08:07:10 -0400 Subject: RFR: JDK-8046368 In-Reply-To: <53969F4F.4020206@oracle.com> References: <53969F4F.4020206@oracle.com> Message-ID: <5396F4EE.9040404@oracle.com> Looks fine to me. Since there is no regression test, please add a "noreg-cleanup" label to the bug. Thanks, Sean On 06/10/2014 02:01 AM, Jamil Nimeh wrote: > Hello all, > > These are some minor clean-up changes in SeedGenerator.java that were > found while fixing a different issue. > > http://cr.openjdk.java.net/~xuelei/7176176/webrev.01 > > Thank you, > --Jamil From vincent.x.ryan at oracle.com Tue Jun 10 13:43:25 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 10 Jun 2014 14:43:25 +0100 Subject: [9] review request for 8040812: Uninitialised memory in jdk/src/share/native/sun/security/ec/impl/mpi.c Message-ID: Please review this trivial fix to initialize a local variable before use: Bug: https://bugs.openjdk.java.net/browse/JDK-8040812 Webrev: http://cr.openjdk.java.net/~vinnie/8040812/webrev.00/ Thanks. From sean.mullan at oracle.com Tue Jun 10 14:10:05 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 Jun 2014 10:10:05 -0400 Subject: [9] review request for 8040812: Uninitialised memory in jdk/src/share/native/sun/security/ec/impl/mpi.c In-Reply-To: References: Message-ID: <539711BD.7040205@oracle.com> Looks fine to me. Please add a noreg label to the bug before you push. --Sean On 06/10/2014 09:43 AM, Vincent Ryan wrote: > Please review this trivial fix to initialize a local variable before use: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8040812 > Webrev: http://cr.openjdk.java.net/~vinnie/8040812/webrev.00/ > > Thanks. > From vincent.x.ryan at oracle.com Tue Jun 10 14:39:34 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 10 Jun 2014 15:39:34 +0100 Subject: [9] review request for 8040812: Uninitialised memory in jdk/src/share/native/sun/security/ec/impl/mpi.c In-Reply-To: <539711BD.7040205@oracle.com> References: <539711BD.7040205@oracle.com> Message-ID: <070E68BB-84E0-434C-B29F-0B9C0ECF10CC@oracle.com> Thanks. On 10 Jun 2014, at 15:10, Sean Mullan wrote: > Looks fine to me. Please add a noreg label to the bug before you push. > > --Sean > > On 06/10/2014 09:43 AM, Vincent Ryan wrote: >> Please review this trivial fix to initialize a local variable before use: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8040812 >> Webrev: http://cr.openjdk.java.net/~vinnie/8040812/webrev.00/ >> >> Thanks. >> From vincent.x.ryan at oracle.com Tue Jun 10 15:02:44 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 10 Jun 2014 16:02:44 +0100 Subject: [9] review request for 8036613: [parfait] JNI exception pending in jdk/src/windows/native/sun/security/provider/WinCAPISeedGenerator.c Message-ID: <35B88E29-B329-45AC-BD40-3D82EA8C01BD@oracle.com> Please review this fix to check for a memory allocation failure and clean-up: Bug: https://bugs.openjdk.java.net/browse/JDK-8036613 Webrev: http://cr.openjdk.java.net/~vinnie/8036613/webrev.00/ Thanks. From sean.mullan at oracle.com Tue Jun 10 15:32:13 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 Jun 2014 11:32:13 -0400 Subject: Webrev request: JDK-8015081 In-Reply-To: <53923DC3.2080107@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> <53923DC3.2080107@oracle.com> Message-ID: <539724FD.1020501@oracle.com> Looks good to me. --Sean On 06/06/2014 06:16 PM, Jamil Nimeh wrote: > One more version of this webrev with minor comment changes: > > http://cr.openjdk.java.net/~ascarpino/8015081/webrev.04 > > Thanks, > --Jamil > > On 06/04/2014 04:29 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is an update to the webrev for JDK-8015081 that takes into >> account review changes and adds a few more tests. >> >> http://cr.openjdk.java.net/~ascarpino/8015081/webrev.03 >> >> >> Thanks! >> --Jamil >> >> On 05/27/2014 05:53 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This bug was originally to resolve issues where Subject principal and >>> credential Set fields containing null elements could cause >>> NullPointerException to be thrown. It was decided to make the >>> Subject throw NullPointerException when attempts to construct or >>> modify Subjects will null elements. In addition, certain Set methods >>> called upon principals and credentials where the input Collection >>> contained null elements could have different effects depending on >>> which set. These methods, when called with Collections containing >>> null elements as input now throw NullPointerException as well. >>> >>> Operation Before After >>> (Prin/Pub/Priv) (Prin/Pub/Priv) (Prin/Pub/Priv) >>> ---------------------------------------------------------------------------- >>> >>> add(null) SecurityException/true/true NPE/NPE/NPE >>> remove(null) false/false/false (*) NPE/NPE/NPE >>> contains(null) false/false/false (*) NPE/NPE/NPE >>> addAll(collection w/ null) SecurityException/true/true NPE/NPE/NPE >>> removeAll(collection w/ null) true/true/true (**) NPE/NPE/NPE >>> containsAll(coll. w/ null) false/false/NPE NPE/NPE/NPE >>> retainAll(collection w/ null) true/true/true (***) NPE/NPE/NPE >>> >>> * - Assumes Subject has no null values in its private SecureSet >>> collections >>> ** - Assumes input collection has at least one non-null element that >>> exists in the target SecureSet >>> *** - Assumes input collection is not equivalent to or a superset of >>> the target SecureSet (which would cause no change) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015081 >>> Webrev: http://cr.openjdk.java.net/~ascarpino/8015081/webrev.02 >>> >>> Thanks, >>> --Jamil >> > From weijun.wang at oracle.com Wed Jun 11 02:24:03 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 Jun 2014 10:24:03 +0800 Subject: Webrev request: JDK-8015081 In-Reply-To: <539724FD.1020501@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> <53923DC3.2080107@oracle.com> <539724FD.1020501@oracle.com> Message-ID: <158CE453-1A12-4DC8-90F3-88EB5F6AC369@oracle.com> Hi Jamil Sorry I've just read the webrev. If you always throw an NPE after a collectionNullClean() call, isn't it simpler to let the method throw the NPE? Also, Objects.requireNonNull(o, msg) can be used in those "if (o == null)" cases. Thanks Max On Jun 10, 2014, at 23:32, Sean Mullan wrote: > Looks good to me. > > --Sean > > On 06/06/2014 06:16 PM, Jamil Nimeh wrote: >> One more version of this webrev with minor comment changes: >> >> http://cr.openjdk.java.net/~ascarpino/8015081/webrev.04 >> >> Thanks, >> --Jamil From jamil.j.nimeh at oracle.com Wed Jun 11 04:01:17 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 10 Jun 2014 21:01:17 -0700 Subject: Webrev request: JDK-8015081 In-Reply-To: <158CE453-1A12-4DC8-90F3-88EB5F6AC369@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> <53923DC3.2080107@oracle.com> <539724FD.1020501@oracle.com> <158CE453-1A12-4DC8-90F3-88EB5F6AC369@oracle.com> Message-ID: <5397D48D.7040801@oracle.com> Hi Max, You're probably right about collectionNullClean/throw question. When I first wrote that method I wasn't sure I'd always throw NPE as a consequent of it returning false, but it ended up working out that way. I'm already reworking a couple tests so I'll take a look at implementing those comments tonight and kick another review out. Thanks for the comments. --Jamil On 06/10/2014 07:24 PM, Wang Weijun wrote: > Hi Jamil > > Sorry I've just read the webrev. > > If you always throw an NPE after a collectionNullClean() call, isn't it simpler to let the method throw the NPE? > > Also, Objects.requireNonNull(o, msg) can be used in those "if (o == null)" cases. > > Thanks > Max > > On Jun 10, 2014, at 23:32, Sean Mullan wrote: > >> Looks good to me. >> >> --Sean >> >> On 06/06/2014 06:16 PM, Jamil Nimeh wrote: >>> One more version of this webrev with minor comment changes: >>> >>> http://cr.openjdk.java.net/~ascarpino/8015081/webrev.04 >>> >>> Thanks, >>> --Jamil From weijun.wang at oracle.com Wed Jun 11 05:37:48 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 Jun 2014 13:37:48 +0800 Subject: RFR 8046499: nativecache.c prints to stdout in debug build Message-ID: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8046499/webrev.00/ It simply removes all #ifdef DEBUG blocks. They are not really useful but the output pollutes the stdout stream. We can use the sun.security.krb5.debug system property if there are future debug info worth showing. Thanks Max From xuelei.fan at oracle.com Wed Jun 11 07:39:16 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jun 2014 15:39:16 +0800 Subject: RFR 8046499: nativecache.c prints to stdout in debug build In-Reply-To: References: Message-ID: <539807A4.9080108@oracle.com> Looks fine to me. Xuelei On 6/11/2014 1:37 PM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8046499/webrev.00/ > > It simply removes all #ifdef DEBUG blocks. They are not really useful but the output pollutes the stdout stream. We can use the sun.security.krb5.debug system property if there are future debug info worth showing. > > Thanks > Max > From weijun.wang at oracle.com Thu Jun 12 06:07:49 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 Jun 2014 14:07:49 +0800 Subject: RFR 7150092: NTLM authentication fail if user specified a different realm Message-ID: <4C46F4A8-4CCB-4075-B594-FA9B51C2F692@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/7150092/webrev.00/ The problem is that in NTLM, the server might prompt for a domain name (in Type 2 message), and the client can also provide one. Before this fix, if the two are different, the client chooses the one from the server. After this fix, the client will always uses its own even if it's empty. This is confirmed by looking at the behavior of IE/Firefox/Chrome. The server sent domain name was designed to be used to create the NTLMv2 response but it's now obsoleted by alist. Chrome/Firefox simply ignore it, so will Java. (IE does use it if there is no alist) There are some other small changes: Client.java ----------- 96-108: No one sends hostname and domain in the Type 1 message, so they are removed. Everyone adds a 0x4 flag which means Request Target. Removed old 137-139: That's the major change. 159: I used to detect whether there is an alist by looking at the length. This is not accurate if the domain is very long. The correct way is to look at the flag (0x800000 means alist is there) Server.java ----------- 98: Adds a flag 0x10000 which means the target name (line 99) written into the message is a domain 135: Always uses the client provided domain to search for password. This is also a part of the major change. NTLMClient.java --------------- If user has not responded to NameCallback and/or RealmCallback, it means they accept the default value. NTLMServer.java --------------- ntdomain could be empty or null, the 2-arg constructor of RealmCallback could fail in this case. Use 1-arg constructor. NTLMAuthentication.java ----------------------- According to my observation of IE/Firefox/Chrome, when user does not type in a domain name in the password prompting dialog, the domain sent to server is an empty string, and the host name is always full name. Update Java to be the same. NTLMTest.java ------------- Update the test to reflect code changes. Thanks Max From dingxmin at linux.vnet.ibm.com Thu Jun 12 06:14:28 2014 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 12 Jun 2014 14:14:28 +0800 Subject: A Bug in AccessControlContext.equals() and hashCode()? Message-ID: Hi Guys, Recently, we noticed that JEP-140 has altered the behavior of AccessControlContext equality and comparson semantics. To be more precisely, AccessControlContext.equals() takes fields "DomainCombiner combiner" & "ProtectionDomain[] context" and some others into consideration (both Java 7 & 8) whereas AccessControlContext.hashCode() only cares about "ProtectionDomain[] context". This is weird. My questions are: 1. Though spec doesn't require two objects with same hashcode are equal, what's the particular reason that field "DomainCombiner combiner" are used for equal() but not hashCode()? 2. Is it expected that two AccessControlContext objects considered equal via method equals() should return same results for AccessControlContext.checkPermission()? In addition, current JCK tests (both Java 7 & 8) validate AccessControlContext.hashCode() by calculating only field "ProtectionDomain[] context". Does it make sense to challenge JCK if I would like add more fields for hashCode calculation? Your insight is appreciated. Thanks, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Thu Jun 12 09:26:54 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 12 Jun 2014 02:26:54 -0700 Subject: Webrev request: JDK-8015081 In-Reply-To: <539724FD.1020501@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> <53923DC3.2080107@oracle.com> <539724FD.1020501@oracle.com> Message-ID: <5399725E.5070407@oracle.com> Next round: This one incorporates Weijun's comments and cleans up a couple warnings in the test code. http://cr.openjdk.java.net/~weijun/8015081/webrev.05/ --Jamil > On 06/06/2014 06:16 PM, Jamil Nimeh wrote: >> One more version of this webrev with minor comment changes: >> >> http://cr.openjdk.java.net/~ascarpino/8015081/webrev.04 >> >> Thanks, >> --Jamil >> >> On 06/04/2014 04:29 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This is an update to the webrev for JDK-8015081 that takes into >>> account review changes and adds a few more tests. >>> >>> http://cr.openjdk.java.net/~ascarpino/8015081/webrev.03 >>> >>> >>> Thanks! >>> --Jamil >>> >>> On 05/27/2014 05:53 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This bug was originally to resolve issues where Subject principal and >>>> credential Set fields containing null elements could cause >>>> NullPointerException to be thrown. It was decided to make the >>>> Subject throw NullPointerException when attempts to construct or >>>> modify Subjects will null elements. In addition, certain Set methods >>>> called upon principals and credentials where the input Collection >>>> contained null elements could have different effects depending on >>>> which set. These methods, when called with Collections containing >>>> null elements as input now throw NullPointerException as well. >>>> >>>> Operation Before After >>>> (Prin/Pub/Priv) (Prin/Pub/Priv) (Prin/Pub/Priv) >>>> ---------------------------------------------------------------------------- >>>> >>>> >>>> add(null) SecurityException/true/true NPE/NPE/NPE >>>> remove(null) false/false/false (*) NPE/NPE/NPE >>>> contains(null) false/false/false (*) NPE/NPE/NPE >>>> addAll(collection w/ null) SecurityException/true/true NPE/NPE/NPE >>>> removeAll(collection w/ null) true/true/true (**) NPE/NPE/NPE >>>> containsAll(coll. w/ null) false/false/NPE NPE/NPE/NPE >>>> retainAll(collection w/ null) true/true/true (***) NPE/NPE/NPE >>>> >>>> * - Assumes Subject has no null values in its private SecureSet >>>> collections >>>> ** - Assumes input collection has at least one non-null element that >>>> exists in the target SecureSet >>>> *** - Assumes input collection is not equivalent to or a superset of >>>> the target SecureSet (which would cause no change) >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015081 >>>> Webrev: http://cr.openjdk.java.net/~ascarpino/8015081/webrev.02 >>>> >>>> Thanks, >>>> --Jamil >>> >> From weijun.wang at oracle.com Thu Jun 12 09:40:37 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 Jun 2014 17:40:37 +0800 Subject: Webrev request: JDK-8015081 In-Reply-To: <5399725E.5070407@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> <53923DC3.2080107@oracle.com> <539724FD.1020501@oracle.com> <5399725E.5070407@oracle.com> Message-ID: <9B0B323B-1D8F-4180-9ADF-1905071B6C65@oracle.com> Why @@ -968,14 +963,10 @@ readOnly = gf.get("readOnly", false); Set inputPrincs = (Set)gf.get("principals", null); // Rewrap the principals into a SecureSet - if (inputPrincs == null) { - throw new NullPointerException - (ResourcesMgr.getString("invalid.null.input.s.")); - } try { principals = Collections.synchronizedSet(new SecureSet (this, PRINCIPAL_SET, inputPrincs)); } catch (NullPointerException npe) { // Sometimes people deserialize the principals set only. It looks you accept principals being null in serialized form. (Of course, the new object contains a non-null one). Thanks Max On Jun 12, 2014, at 17:26, Jamil Nimeh wrote: > Next round: This one incorporates Weijun's comments and cleans up a couple warnings in the test code. > > http://cr.openjdk.java.net/~weijun/8015081/webrev.05/ > > --Jamil From weijun.wang at oracle.com Thu Jun 12 14:57:31 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 Jun 2014 22:57:31 +0800 Subject: RFR 8046702: default_options.sh test failure on Solaris Message-ID: Oh, I made the mistake again, on Solaris "export ENV=var" is not always correct. Please review the code change at http://cr.openjdk.java.net/~weijun/8046702/webrev.00/ The fix is as simple as -----START----- diff --git a/test/sun/security/tools/keytool/default_options.sh b/test/sun/security/tools/keytool/default_options.sh --- a/test/sun/security/tools/keytool/default_options.sh +++ b/test/sun/security/tools/keytool/default_options.sh @@ -38,7 +38,8 @@ rm $KS 2> /dev/null -export PASS=changeit +PASS=changeit +export PASS # keytool -----END----- I was using "-storepass changeit" but at the final second I changed it to export PASS=changeit keytool -storepass:env PASS and thought it looks more secure. I should have run it on all platforms again. Thanks Max From jamil.j.nimeh at oracle.com Thu Jun 12 14:58:28 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 12 Jun 2014 07:58:28 -0700 Subject: Webrev request: JDK-8015081 In-Reply-To: <9B0B323B-1D8F-4180-9ADF-1905071B6C65@oracle.com> References: <53853393.6020108@oracle.com> <538FABEE.5070902@oracle.com> <53923DC3.2080107@oracle.com> <539724FD.1020501@oracle.com> <5399725E.5070407@oracle.com> <9B0B323B-1D8F-4180-9ADF-1905071B6C65@oracle.com> Message-ID: <5399C014.70707@oracle.com> The Subject's readObject can get called in one of two scenarios: When a Subject is deserialized and if a SecureSet is deserialized (because of the reference to the containing Subject in SecureSet). In the latter case, accessing the contents of inputPrincs before deserialization is complete causes NPEs (even in valid cases) because the Subject is being deserialized before the SecureSet - chicken/egg thing. I believe I could add that simple null check for the object itself back in without breaking things, but SecureSet's readObject is now checking the contents. I'll put it back in and re-run the tests to make sure it'll work. --Jamil On 06/12/2014 02:40 AM, Wang Weijun wrote: > Why > > @@ -968,14 +963,10 @@ > > readOnly = gf.get("readOnly", false); > > Set inputPrincs = (Set)gf.get("principals", null); > > // Rewrap the principals into a SecureSet > > - if (inputPrincs == null) { > - throw new NullPointerException > - (ResourcesMgr.getString("invalid.null.input.s.")); > - } > > try { > principals = Collections.synchronizedSet(new SecureSet > (this, PRINCIPAL_SET, inputPrincs)); > } catch (NullPointerException npe) { > // Sometimes people deserialize the principals set only. > > > It looks you accept principals being null in serialized form. (Of course, the new object contains a non-null one). > > Thanks > Max > > On Jun 12, 2014, at 17:26, Jamil Nimeh wrote: > >> Next round: This one incorporates Weijun's comments and cleans up a couple warnings in the test code. >> >> http://cr.openjdk.java.net/~weijun/8015081/webrev.05/ >> >> --Jamil From Xuelei.Fan at Oracle.Com Thu Jun 12 15:12:34 2014 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 12 Jun 2014 23:12:34 +0800 Subject: RFR 8046702: default_options.sh test failure on Solaris In-Reply-To: References: Message-ID: Looks fine to me. Xuelei > On Jun 12, 2014, at 10:57 PM, Wang Weijun wrote: > > Oh, I made the mistake again, on Solaris "export ENV=var" is not always correct. > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8046702/webrev.00/ > > The fix is as simple as > > -----START----- > diff --git a/test/sun/security/tools/keytool/default_options.sh b/test/sun/security/tools/keytool/default_options.sh > --- a/test/sun/security/tools/keytool/default_options.sh > +++ b/test/sun/security/tools/keytool/default_options.sh > @@ -38,7 +38,8 @@ > > rm $KS 2> /dev/null > > -export PASS=changeit > +PASS=changeit > +export PASS > > # keytool > -----END----- > > I was using "-storepass changeit" but at the final second I changed it to > > export PASS=changeit > keytool -storepass:env PASS > > and thought it looks more secure. I should have run it on all platforms again. > > Thanks > Max > From jeffrey.nisewanger at oracle.com Thu Jun 12 16:21:01 2014 From: jeffrey.nisewanger at oracle.com (Jeff Nisewanger) Date: Thu, 12 Jun 2014 09:21:01 -0700 Subject: A Bug in AccessControlContext.equals() and hashCode()? In-Reply-To: References: Message-ID: > On Jun 11, 2014, at 11:14 PM, Frank Ding wrote: > My questions are: > 1. Though spec doesn't require two objects with same hashcode are equal, what's the particular reason that field "DomainCombiner combiner" are used for equal() but not hashCode()? As you pointed out, the value returned by hashCode() is a quick heuristic or optimization for comparing equality and it is perfectly normal (but sub-optimal) for two unequal instances to share the same hash code value. The hash code calculation based on the array of ProtectionDomains is quick and easy and applies to all AccessControlContext instances. A useful hash code calculation for any DomainCombiner or other relevant instance state is less obvious and extending the calculation was deferred to a future release. > 2. Is it expected that two AccessControlContext objects considered equal via method equals() should return same results for AccessControlContext.checkPermission()? Yes. > > In addition, current JCK tests (both Java 7 & 8) validate AccessControlContext.hashCode() by calculating only field "ProtectionDomain[] context". Does it make sense to challenge JCK if I would like add more fields for hashCode calculation? I will follow up and answer your JCK question next week. Jeff From sean.mullan at oracle.com Fri Jun 13 20:42:17 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jun 2014 16:42:17 -0400 Subject: [9] review request for 8036613: [parfait] JNI exception pending in jdk/src/windows/native/sun/security/provider/WinCAPISeedGenerator.c In-Reply-To: <35B88E29-B329-45AC-BD40-3D82EA8C01BD@oracle.com> References: <35B88E29-B329-45AC-BD40-3D82EA8C01BD@oracle.com> Message-ID: <539B6229.7020504@oracle.com> Looks ok to me. Bug needs a noreg label. --Sean On 06/10/2014 11:02 AM, Vincent Ryan wrote: > Please review this fix to check for a memory allocation failure and clean-up: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8036613 > Webrev: http://cr.openjdk.java.net/~vinnie/8036613/webrev.00/ > > Thanks. > From yonathan at gmail.com Fri Jun 13 23:45:15 2014 From: yonathan at gmail.com (Yonathan) Date: Fri, 13 Jun 2014 16:45:15 -0700 Subject: (smartcardio) Confusing bug fix for wrong DWORD typedef Message-ID: In a commit about a month ago[1], Ivan Gerasimov fixed a long-standing bug in using javax.smartcardio on OS X that I previously mentioned[2]. I am uncomfortable with this fix, because to determine whether it was successful requires study of x86_64 calling conventions. Recall that the bug was that LPDWORD is typedef?d to unsigned long* in pcsc.c, but the dylib is actually expecting uint32_t*. The ?fix? was to initialize variables with 0 before each function call. Instead, the fix should have been to typedef DWORD to uint32_t to match the library header. Consider this library declaration: LONG SCardStatus(SCARDHANDLE hCard, LPTSTR mszReaderNames, LPDWORD pcchReaderLen, LPDWORD pdwState, LPDWORD pdwProtocol, LPBYTE pbAtr, LPDWORD pcbAtrLen); When pcsc.c calls the function, does the function read/write the correct addresses? You have to think about the calling convention: hCard: %rdi ? 8B stack variable; lib reads 4B little end mszReaderNames: %rsi ? byte buffer on stack; lib read/writes bytes pcchReaderLen: %rdx ? 8B stack variable; lib read/writes 4B little end unsigned and we interpret it as 8B long pdwState: %rcx ? 8B stack variable; lib writes 4B little end bitmask pdwProtocol: %r8 ? 8B stack variable; lib writes 4B little end enum pbAtr: %r9 ? byte buffer on stack; lib writes bytes pcbAtrLen: 8B (%esp) ? 8B stack variable; lib writes 4B little end and we interpret it as 8B long Because we assume x86_64 with 8-byte registers/8 byte parameter alignment and little-endian integers and all of them are unsigned, and the variables we write are bigger than the variables that the library reads, the fix should work, I think. But why not just typedef DWORD to match the typedef in the PCSC system header[3] on OS X so we don?t have to go through this analysis? Moreover, there is no comment in the code to state these assumptions, so this apparently redundant initialization is confusing. By the way, you can also simplify the related struct declaration fix[4] by using the same DWORD in it instead of declaring it in two different places. Thank you for your consideration. Yonathan [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-May/010515.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006913.html [3] /System/Library/Frameworks/PCSC.framework/Headers/wintypes.h [4] http://mail.openjdk.java.net/pipermail/security-dev/2014-May/010498.html From ivan.gerasimov at oracle.com Sat Jun 14 10:32:13 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 14 Jun 2014 14:32:13 +0400 Subject: (smartcardio) Confusing bug fix for wrong DWORD typedef In-Reply-To: References: Message-ID: <539C24AD.4010500@oracle.com> Hi Yonathan! Thank you for your close attention and analysis you've done. I mostly agree with your conclusion that having correct typedefs for MacOSX would be a better solution here. Even more radical approach would be to remove our own API declarations altogether and switch to the one provided with pcsc-lite. That's what Ludovic Rousseau, the pcsc-lite author, has suggested in his blogpost [1]. If we ever decide to move this way, the problem you've mentioned will be gone along with many other problems of this kind. With respect to the fix of 8043507, I've pushed, the solution was meant to be with the lowest possible risk of regression. I only had to verify that it solves the problem on MacOSX. Anything bigger might have required comprehensive testing across different platforms/hardware. Sincerely yours, Ivan [1] http://ludovicrousseau.blogspot.co.uk/2013/03/oracle-javaxsmartcardio-failures.html On 14.06.2014 3:45, Yonathan wrote: > In a commit about a month ago[1], Ivan Gerasimov fixed a long-standing > bug in using javax.smartcardio on OS X that I previously mentioned[2]. > I am uncomfortable with this fix, because to determine whether it was > successful requires study of x86_64 calling conventions. > > Recall that the bug was that LPDWORD is typedef?d to unsigned long* in > pcsc.c, but the dylib is actually expecting uint32_t*. The ?fix? was > to initialize variables with 0 before each function call. Instead, the > fix should have been to typedef DWORD to uint32_t to match the library > header. Consider this library declaration: > > LONG SCardStatus(SCARDHANDLE hCard, > LPTSTR mszReaderNames, LPDWORD pcchReaderLen, > LPDWORD pdwState, > LPDWORD pdwProtocol, > LPBYTE pbAtr, LPDWORD pcbAtrLen); > > When pcsc.c calls the function, does the function read/write the > correct addresses? You have to think about the calling convention: > > hCard: %rdi ? 8B stack variable; lib reads 4B little end > > mszReaderNames: %rsi ? byte buffer on stack; lib read/writes bytes > > pcchReaderLen: %rdx ? 8B stack variable; lib read/writes 4B little end > unsigned and we interpret it as 8B long > > pdwState: %rcx ? 8B stack variable; lib writes 4B little end bitmask > > pdwProtocol: %r8 ? 8B stack variable; lib writes 4B little end enum > > pbAtr: %r9 ? byte buffer on stack; lib writes bytes > > pcbAtrLen: 8B (%esp) ? 8B stack variable; lib writes 4B little end and > we interpret it as 8B long > > Because we assume x86_64 with 8-byte registers/8 byte parameter > alignment and little-endian integers and all of them are unsigned, and > the variables we write are bigger than the variables that the library > reads, the fix should work, I think. > > But why not just typedef DWORD to match the typedef in the PCSC system > header[3] on OS X so we don?t have to go through this analysis? > Moreover, there is no comment in the code to state these assumptions, > so this apparently redundant initialization is confusing. > > By the way, you can also simplify the related struct declaration > fix[4] by using the same DWORD in it instead of declaring it in two > different places. > > Thank you for your consideration. > > Yonathan > > [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-May/010515.html > [2] http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006913.html > [3] /System/Library/Frameworks/PCSC.framework/Headers/wintypes.h > [4] http://mail.openjdk.java.net/pipermail/security-dev/2014-May/010498.html > > From yonathan at gmail.com Sat Jun 14 17:41:34 2014 From: yonathan at gmail.com (Yonathan) Date: Sat, 14 Jun 2014 10:41:34 -0700 Subject: (smartcardio) Confusing bug fix for wrong DWORD typedef In-Reply-To: <539C24AD.4010500@oracle.com> References: <539C24AD.4010500@oracle.com> Message-ID: Thanks Ivan. The current solution does make sense if the cleaner solution would trigger difficult testing. And I do think the solution works, as you have initialized all DWORDs before calls. Cheers, Yonathan On Sat, Jun 14, 2014 at 3:32 AM, Ivan Gerasimov wrote: > Hi Yonathan! > > Thank you for your close attention and analysis you've done. > I mostly agree with your conclusion that having correct typedefs for MacOSX > would be a better solution here. > Even more radical approach would be to remove our own API declarations > altogether and switch to the one provided with pcsc-lite. > That's what Ludovic Rousseau, the pcsc-lite author, has suggested in his > blogpost [1]. > > If we ever decide to move this way, the problem you've mentioned will be > gone along with many other problems of this kind. > > With respect to the fix of 8043507, I've pushed, the solution was meant to > be with the lowest possible risk of regression. > I only had to verify that it solves the problem on MacOSX. > Anything bigger might have required comprehensive testing across different > platforms/hardware. > > Sincerely yours, > Ivan > > [1] > http://ludovicrousseau.blogspot.co.uk/2013/03/oracle-javaxsmartcardio-failures.html > > > > > On 14.06.2014 3:45, Yonathan wrote: >> >> In a commit about a month ago[1], Ivan Gerasimov fixed a long-standing >> bug in using javax.smartcardio on OS X that I previously mentioned[2]. >> I am uncomfortable with this fix, because to determine whether it was >> successful requires study of x86_64 calling conventions. >> >> Recall that the bug was that LPDWORD is typedef?d to unsigned long* in >> pcsc.c, but the dylib is actually expecting uint32_t*. The ?fix? was >> to initialize variables with 0 before each function call. Instead, the >> fix should have been to typedef DWORD to uint32_t to match the library >> header. Consider this library declaration: >> >> LONG SCardStatus(SCARDHANDLE hCard, >> LPTSTR mszReaderNames, LPDWORD pcchReaderLen, >> LPDWORD pdwState, >> LPDWORD pdwProtocol, >> LPBYTE pbAtr, LPDWORD pcbAtrLen); >> >> When pcsc.c calls the function, does the function read/write the >> correct addresses? You have to think about the calling convention: >> >> hCard: %rdi ? 8B stack variable; lib reads 4B little end >> >> mszReaderNames: %rsi ? byte buffer on stack; lib read/writes bytes >> >> pcchReaderLen: %rdx ? 8B stack variable; lib read/writes 4B little end >> unsigned and we interpret it as 8B long >> >> pdwState: %rcx ? 8B stack variable; lib writes 4B little end bitmask >> >> pdwProtocol: %r8 ? 8B stack variable; lib writes 4B little end enum >> >> pbAtr: %r9 ? byte buffer on stack; lib writes bytes >> >> pcbAtrLen: 8B (%esp) ? 8B stack variable; lib writes 4B little end and >> we interpret it as 8B long >> >> Because we assume x86_64 with 8-byte registers/8 byte parameter >> alignment and little-endian integers and all of them are unsigned, and >> the variables we write are bigger than the variables that the library >> reads, the fix should work, I think. >> >> But why not just typedef DWORD to match the typedef in the PCSC system >> header[3] on OS X so we don?t have to go through this analysis? >> Moreover, there is no comment in the code to state these assumptions, >> so this apparently redundant initialization is confusing. >> >> By the way, you can also simplify the related struct declaration >> fix[4] by using the same DWORD in it instead of declaring it in two >> different places. >> >> Thank you for your consideration. >> >> Yonathan >> >> [1] >> http://mail.openjdk.java.net/pipermail/security-dev/2014-May/010515.html >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006913.html >> [3] /System/Library/Frameworks/PCSC.framework/Headers/wintypes.h >> [4] >> http://mail.openjdk.java.net/pipermail/security-dev/2014-May/010498.html >> >> > From dingxmin at linux.vnet.ibm.com Mon Jun 16 14:19:49 2014 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Mon, 16 Jun 2014 22:19:49 +0800 Subject: A Bug in AccessControlContext.equals() and hashCode()? Message-ID: Hi Jeff, Thanks for your reply. One further question is that you confirmed that two AccessControlContext objects considered equal via method equals() should return same results for AccessControlContext.checkPermission() but test shows that 2 AccessControlContext objects are equal regardless of isLimited, limitedContext, parent, permissions, or privilegedContext. Does it make sense and apply to Java 8 AccessControlContext with JEP140? Best regards, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Mon Jun 16 14:40:18 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 16 Jun 2014 09:40:18 -0500 Subject: A Bug in AccessControlContext.equals() and hashCode()? In-Reply-To: References: Message-ID: <539F01D2.4000406@redhat.com> On 06/16/2014 09:19 AM, Frank Ding wrote: > Hi Jeff, > Thanks for your reply. One further question is that you confirmed > that two AccessControlContext objects considered equal via method > equals() should return same results for > AccessControlContext.checkPermission() but test shows that 2 > AccessControlContext objects are equal regardless of isLimited, > limitedContext, parent, permissions, or privilegedContext. Does it make > sense and apply to Java 8 AccessControlContext with JEP140? Is it not true that a limited privileged context simply adds a protection domain that restricts permissions to the limited set? This seems to be the "obvious" implementation of the feature. If so, then equals() should have taken it into account as a matter of course. -- - DML From sean.mullan at oracle.com Mon Jun 16 15:04:11 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Jun 2014 11:04:11 -0400 Subject: RFR: JDK-8046044 : Fix raw and unchecked lint warnings in XML Signature Impl Message-ID: <539F076B.8070108@oracle.com> This is a subtask of the task to eliminate all raw and unchecked lint warnings from the JDK. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8046044/webrev.00/ Note that some warnings still require the Suppressed annotation (see DOMXMLSignatureFactory, DOMKeyInfoFactory). These can eventually be removed when the javax.xml.crypto API is generified, which we will try to get to later in the JDK 9 timeframe. Thanks, Sean From joe.darcy at oracle.com Mon Jun 16 16:38:40 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 16 Jun 2014 09:38:40 -0700 Subject: RFR: JDK-8046044 : Fix raw and unchecked lint warnings in XML Signature Impl In-Reply-To: <539F076B.8070108@oracle.com> References: <539F076B.8070108@oracle.com> Message-ID: <539F1D90.9070207@oracle.com> Looks fine Sean; thanks, -Joe On 06/16/2014 08:04 AM, Sean Mullan wrote: > This is a subtask of the task to eliminate all raw and unchecked lint > warnings from the JDK. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8046044/webrev.00/ > > Note that some warnings still require the Suppressed annotation (see > DOMXMLSignatureFactory, DOMKeyInfoFactory). These can eventually be > removed when the javax.xml.crypto API is generified, which we will try > to get to later in the JDK 9 timeframe. > > Thanks, > Sean > From jamil.j.nimeh at oracle.com Mon Jun 16 18:05:39 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 16 Jun 2014 11:05:39 -0700 Subject: RFR: 8015081 (Episode VI) Message-ID: <539F31F3.2070700@oracle.com> Hello all, This is an update to the fix 8015081: * Incorporate Max's comments from the previous revision * Remove binary file test input and bring test data into SubjectNullTests.java as byte arrays (with descriptions on how they were made). http://cr.openjdk.java.net/~ascarpino/8015081/webrev.06 Thanks, --Jamil From vincent.x.ryan at oracle.com Tue Jun 17 18:41:51 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 17 Jun 2014 19:41:51 +0100 Subject: [9] RfR 8047085: PKCS11/NSS tests failing intermittently on Windows Message-ID: <12707D2C-0108-4623-9A10-96737236F178@oracle.com> Please review the following changeset to refresh the version of NSS that is included with the PKCS11 test suite. The old version of NSS 3.13.1 is replaced with NSS 3.16 which has been built with VS2010 on Windows 32-bit and 64-bit. This corrects an intermittent failure with PKCS11 tests on Windows. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8047085 Webrev: http://cr.openjdk.java.net/~vinnie/8047085/webrev.00/ From sean.mullan at oracle.com Tue Jun 17 18:55:03 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Jun 2014 14:55:03 -0400 Subject: [9] RfR 8047085: PKCS11/NSS tests failing intermittently on Windows In-Reply-To: <12707D2C-0108-4623-9A10-96737236F178@oracle.com> References: <12707D2C-0108-4623-9A10-96737236F178@oracle.com> Message-ID: <53A08F07.2090605@oracle.com> The bug needs a noreg label. Also the subcomponent should probably be javax.crypto:pkcs11. Otherwise looks fine to me. --Sean On 06/17/2014 02:41 PM, Vincent Ryan wrote: > Please review the following changeset to refresh the version of NSS that is included with > the PKCS11 test suite. > > The old version of NSS 3.13.1 is replaced with NSS 3.16 which has been built with VS2010 > on Windows 32-bit and 64-bit. This corrects an intermittent failure with PKCS11 tests on Windows. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047085 > Webrev: http://cr.openjdk.java.net/~vinnie/8047085/webrev.00/ > From vincent.x.ryan at oracle.com Wed Jun 18 09:59:11 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 18 Jun 2014 10:59:11 +0100 Subject: [9] RfR 8047085: PKCS11/NSS tests failing intermittently on Windows In-Reply-To: <53A08F07.2090605@oracle.com> References: <12707D2C-0108-4623-9A10-96737236F178@oracle.com> <53A08F07.2090605@oracle.com> Message-ID: <2C1C1257-EC06-4F8A-853F-B2132F9F7429@oracle.com> Thanks Sean. Our existing PKCS11 tests are sufficient as regression tests so I?ve added ?noreg-self?. Also, I didn?t set a subcomponent value as only the PKCS11 testsuite has changed not the PKCS11 implementation. On 17 Jun 2014, at 19:55, Sean Mullan wrote: > The bug needs a noreg label. Also the subcomponent should probably be javax.crypto:pkcs11. Otherwise looks fine to me. > > --Sean > > On 06/17/2014 02:41 PM, Vincent Ryan wrote: >> Please review the following changeset to refresh the version of NSS that is included with >> the PKCS11 test suite. >> >> The old version of NSS 3.13.1 is replaced with NSS 3.16 which has been built with VS2010 >> on Windows 32-bit and 64-bit. This corrects an intermittent failure with PKCS11 tests on Windows. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8047085 >> Webrev: http://cr.openjdk.java.net/~vinnie/8047085/webrev.00/ >> From sean.mullan at oracle.com Wed Jun 18 16:17:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Jun 2014 12:17:18 -0400 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf In-Reply-To: <53468310.2090506@oracle.com> References: <53468310.2090506@oracle.com> Message-ID: <53A1BB8E.6040200@oracle.com> Just a few comments on Config.java: 479 if (dups.contains(file)) { 480 throw new IOException("Profile path included more than once"); 481 } else { 482 dups.add(file); 483 } This could be compressed into one call as: if (!dups.add(file)) { throw new IOException("Profile path included more than once"); } 506 // if dir is abosulte, so is p typo: absolute 511 } else if (line.startsWith("include ")) { why doesn't the file name syntax check on line 505 also apply to include? 570 public Void run() throws Exception { This can be declared to throw IOException, then you can change lines 586-591 to: throw pe.getException(); --Sean On 04/10/2014 07:40 AM, Weijun Wang wrote: > Hi All > > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8029994/webrev.01/ > > Two major changes made: > > 1. The include and includedir directives are supported now. Read > http://web.mit.edu/kerberos/krb5-current/doc/admin/conf_files/krb5_conf.html > for a description. The part we support in this RFE is: > > -----START----- > The krb5.conf file can include other files using either of the following > directives at the beginning of a line: > > include FILENAME > includedir DIRNAME > > FILENAME or DIRNAME should be an absolute path. The named file or > directory must exist and be readable. Including a directory includes all > files within the directory whose names consist solely of alphanumeric > characters, dashes, or underscores. Included profile files are > syntactically independent of their parents, so each included file must > begin with a section header. > -----END----- > > 2. When the same key appears more than once in krb5.conf, Java used to > choose the last value, while MIT krb5 chooses the first one. While it's > debatable whether latecomers should be able to override earlier > definitions or not, it's more important to have consistent behavior > across implementations. Therefore we adopt the MIT krb5 way. The > compatibility risk should be very low since it's very unlikely people > assigns values to duplicate keys in a single krb5.conf file, which is > what we support before this enhancement. > > One code change that might look strange is in the Config constructor: > > } catch (IOException ioe) { > - // I/O error, mostly like krb5.conf missing. > - // No problem. We'll use DNS or system property etc. > + throw new KrbException(ioe); > } > > Before this, the only possible IOException thrown is > FileNotFoundException when krb5.conf is not found, but now there can be > much more. So I move the FNFE check inside the loadConfigFile() method as > > + Path path = Paths.get(fileName); > + if (!Files.exists(path)) { > + // This is OK. There are other ways to get > + // Kerberos 5 settings > + return null; > + } else { > + return readConfigFileLines( > + fullp, raw, dupsCheck); > + } > > Thanks > Max From sean.mullan at oracle.com Wed Jun 18 17:06:25 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Jun 2014 13:06:25 -0400 Subject: [9] RfR 8047085: PKCS11/NSS tests failing intermittently on Windows In-Reply-To: <2C1C1257-EC06-4F8A-853F-B2132F9F7429@oracle.com> References: <12707D2C-0108-4623-9A10-96737236F178@oracle.com> <53A08F07.2090605@oracle.com> <2C1C1257-EC06-4F8A-853F-B2132F9F7429@oracle.com> Message-ID: <53A1C711.10005@oracle.com> On 06/18/2014 05:59 AM, Vincent Ryan wrote: > Thanks Sean. > > Our existing PKCS11 tests are sufficient as regression tests so I?ve added ?noreg-self?. > Also, I didn?t set a subcomponent value as only the PKCS11 testsuite has changed not > the PKCS11 implementation. Hmm. I've always considered the subcomponent to also apply to the package or area a test is testing. --Sean > > On 17 Jun 2014, at 19:55, Sean Mullan wrote: > >> The bug needs a noreg label. Also the subcomponent should probably be javax.crypto:pkcs11. Otherwise looks fine to me. >> >> --Sean >> >> On 06/17/2014 02:41 PM, Vincent Ryan wrote: >>> Please review the following changeset to refresh the version of NSS that is included with >>> the PKCS11 test suite. >>> >>> The old version of NSS 3.13.1 is replaced with NSS 3.16 which has been built with VS2010 >>> on Windows 32-bit and 64-bit. This corrects an intermittent failure with PKCS11 tests on Windows. >>> >>> Thanks. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047085 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8047085/webrev.00/ >>> > From vincent.x.ryan at oracle.com Wed Jun 18 17:12:46 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 18 Jun 2014 18:12:46 +0100 Subject: [9] RfR 8047085: PKCS11/NSS tests failing intermittently on Windows In-Reply-To: <53A1C711.10005@oracle.com> References: <12707D2C-0108-4623-9A10-96737236F178@oracle.com> <53A08F07.2090605@oracle.com> <2C1C1257-EC06-4F8A-853F-B2132F9F7429@oracle.com> <53A1C711.10005@oracle.com> Message-ID: <95D14ED6-0E0D-4921-A3D9-EBF0802792A0@oracle.com> OK. I?ve updated both bug reports. On 18 Jun 2014, at 18:06, Sean Mullan wrote: > On 06/18/2014 05:59 AM, Vincent Ryan wrote: >> Thanks Sean. >> >> Our existing PKCS11 tests are sufficient as regression tests so I?ve added ?noreg-self?. >> Also, I didn?t set a subcomponent value as only the PKCS11 testsuite has changed not >> the PKCS11 implementation. > > Hmm. I've always considered the subcomponent to also apply to the package or area a test is testing. > > --Sean > >> >> On 17 Jun 2014, at 19:55, Sean Mullan wrote: >> >>> The bug needs a noreg label. Also the subcomponent should probably be javax.crypto:pkcs11. Otherwise looks fine to me. >>> >>> --Sean >>> >>> On 06/17/2014 02:41 PM, Vincent Ryan wrote: >>>> Please review the following changeset to refresh the version of NSS that is included with >>>> the PKCS11 test suite. >>>> >>>> The old version of NSS 3.13.1 is replaced with NSS 3.16 which has been built with VS2010 >>>> on Windows 32-bit and 64-bit. This corrects an intermittent failure with PKCS11 tests on Windows. >>>> >>>> Thanks. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047085 >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8047085/webrev.00/ >>>> >> From valerie.peng at oracle.com Wed Jun 18 21:53:11 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Jun 2014 14:53:11 -0700 Subject: RFR 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics In-Reply-To: <537548EE.5050909@oracle.com> References: <537548EE.5050909@oracle.com> Message-ID: <53A20A47.4010602@oracle.com> Tony or Vinnie, either of you have time to review? Thanks, Valerie On 5/15/2014 4:08 PM, Valerie (Yu-Ching) Peng wrote: > > Can someone help reviewing this SunJCE provider fix? Essentially, > CipherCore class is updated to minimize memory allocation and data > copying. The fix has been verified against the wls_webapp_atomics > benchmark. > > Webrev: http://cr.openjdk.java.net/~valeriep/8027575/webrev.00/ > > Thanks, > Valerie From rajan.halade at oracle.com Wed Jun 18 22:36:48 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 18 Jun 2014 15:36:48 -0700 Subject: [JDK 9] RFR: 8041781: Need new regression tests for PBE keys Message-ID: <53A21480.40808@oracle.com> May I request you to review these 3 new tests to be added for PBE keys. New tests are added to address following: - seal/unseal works correctly with PBE algorithms - key wrapper works correctly with PBEKey - SecretKeyFactory.translateKey() method works JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8041781 Webrev: http://cr.openjdk.java.net/~rhalade/8041781/webrev.00/ Thanks, Rajan From valerie.peng at oracle.com Wed Jun 18 22:51:46 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Jun 2014 15:51:46 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible Message-ID: <53A21802.7040209@oracle.com> Sean, Not sure if you can get to reviewing this before your vacation. If not, I will find someone else to help... Webrev: http://cr.openjdk.java.net/~valeriep/8043406/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Wed Jun 18 23:04:11 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Jun 2014 16:04:11 -0700 Subject: RFR 8046046: Test sun/security/pkcs11/Signature/TestDSAKeyLength.java fails intermittently on Solaris 11 in 8u40 nightly Message-ID: <53A21AEB.6080000@oracle.com> Tony, Can you please help reviewing this trivial fix? Changes are about overriding the SHA1withDSA signature upper limit to 1024 when larger DSA key size is supported. Webrev: http://cr.openjdk.java.net/~valeriep/8046046/webrev.00/ Thanks, Valerie From anthony.scarpino at oracle.com Thu Jun 19 04:39:08 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 18 Jun 2014 21:39:08 -0700 Subject: RFR 8046046: Test sun/security/pkcs11/Signature/TestDSAKeyLength.java fails intermittently on Solaris 11 in 8u40 nightly In-Reply-To: <53A21AEB.6080000@oracle.com> References: <53A21AEB.6080000@oracle.com> Message-ID: <53A2696C.3070809@oracle.com> On 06/18/2014 04:04 PM, Valerie Peng wrote: > Tony, > > Can you please help reviewing this trivial fix? > Changes are about overriding the SHA1withDSA signature upper limit to > 1024 when larger DSA key size is supported. > > Webrev: http://cr.openjdk.java.net/~valeriep/8046046/webrev.00/ > > Thanks, > Valerie The change looks good to me. Tony From anthony.scarpino at oracle.com Thu Jun 19 05:02:16 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 18 Jun 2014 22:02:16 -0700 Subject: RFR 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics In-Reply-To: <53A20A47.4010602@oracle.com> References: <537548EE.5050909@oracle.com> <53A20A47.4010602@oracle.com> Message-ID: <53A26ED8.70908@oracle.com> The code change looks fine. Do you think this is worth a regression test? Since the in-place operation wasn't caught it sound like there might be no in-place tests Tony On 06/18/2014 02:53 PM, Valerie Peng wrote: > > Tony or Vinnie, either of you have time to review? > Thanks, > Valerie > > On 5/15/2014 4:08 PM, Valerie (Yu-Ching) Peng wrote: >> >> Can someone help reviewing this SunJCE provider fix? Essentially, >> CipherCore class is updated to minimize memory allocation and data >> copying. The fix has been verified against the wls_webapp_atomics >> benchmark. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8027575/webrev.00/ >> >> Thanks, >> Valerie From weijun.wang at oracle.com Thu Jun 19 05:39:52 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Jun 2014 13:39:52 +0800 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf In-Reply-To: <53A1BB8E.6040200@oracle.com> References: <53468310.2090506@oracle.com> <53A1BB8E.6040200@oracle.com> Message-ID: On Jun 19, 2014, at 0:17, Sean Mullan wrote: > Just a few comments on Config.java: > > 479 if (dups.contains(file)) { > 480 throw new IOException("Profile path included more than once"); > 481 } else { > 482 dups.add(file); > 483 } > > This could be compressed into one call as: > > if (!dups.add(file)) { > throw new IOException("Profile path included more than once"); > } OK. > > 506 // if dir is abosulte, so is p > > typo: absolute OK. > > 511 } else if (line.startsWith("include ")) { > > why doesn't the file name syntax check on line 505 also apply to include? According to http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html include FILENAME includedir DIRNAME FILENAME or DIRNAME should be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. Included profile files are syntactically independent of their parents, so each included file must begin with a section header. So the syntax check is only done when iterating through all files for an includedir directive. I think the reason is that when using "include" to include a file, the writer spells out the file name explicitly and we should respect his choice. On the other hand, when using "includedir", there will be files in the directory that the writer might not intend to include. For example, file system browser generates .DS_Store on Mac and desktop.ini on Windows, Dropbox generates .dropbox, etc. > > 570 public Void run() throws Exception { > > This can be declared to throw IOException, then you can change lines 586-591 to: > > throw pe.getException(); You mean javac will be smart enough to find out that pe's cause can only be IOException? It does not compile here. Thanks Max > > --Sean > > On 04/10/2014 07:40 AM, Weijun Wang wrote: >> Hi All >> >> Please review the code changes at >> >> http://cr.openjdk.java.net/~weijun/8029994/webrev.01/ >> >> Two major changes made: >> >> 1. The include and includedir directives are supported now. Read >> http://web.mit.edu/kerberos/krb5-current/doc/admin/conf_files/krb5_conf.html >> for a description. The part we support in this RFE is: >> >> -----START----- >> The krb5.conf file can include other files using either of the following >> directives at the beginning of a line: >> >> include FILENAME >> includedir DIRNAME >> >> FILENAME or DIRNAME should be an absolute path. The named file or >> directory must exist and be readable. Including a directory includes all >> files within the directory whose names consist solely of alphanumeric >> characters, dashes, or underscores. Included profile files are >> syntactically independent of their parents, so each included file must >> begin with a section header. >> -----END----- >> >> 2. When the same key appears more than once in krb5.conf, Java used to >> choose the last value, while MIT krb5 chooses the first one. While it's >> debatable whether latecomers should be able to override earlier >> definitions or not, it's more important to have consistent behavior >> across implementations. Therefore we adopt the MIT krb5 way. The >> compatibility risk should be very low since it's very unlikely people >> assigns values to duplicate keys in a single krb5.conf file, which is >> what we support before this enhancement. >> >> One code change that might look strange is in the Config constructor: >> >> } catch (IOException ioe) { >> - // I/O error, mostly like krb5.conf missing. >> - // No problem. We'll use DNS or system property etc. >> + throw new KrbException(ioe); >> } >> >> Before this, the only possible IOException thrown is >> FileNotFoundException when krb5.conf is not found, but now there can be >> much more. So I move the FNFE check inside the loadConfigFile() method as >> >> + Path path = Paths.get(fileName); >> + if (!Files.exists(path)) { >> + // This is OK. There are other ways to get >> + // Kerberos 5 settings >> + return null; >> + } else { >> + return readConfigFileLines( >> + fullp, raw, dupsCheck); >> + } >> >> Thanks >> Max From sean.mullan at oracle.com Thu Jun 19 11:29:43 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Jun 2014 07:29:43 -0400 Subject: RFR 8046046: Test sun/security/pkcs11/Signature/TestDSAKeyLength.java fails intermittently on Solaris 11 in 8u40 nightly In-Reply-To: <53A21AEB.6080000@oracle.com> References: <53A21AEB.6080000@oracle.com> Message-ID: <53A2C9A7.7000709@oracle.com> Looks ok to me. --Sean On 06/18/2014 07:04 PM, Valerie Peng wrote: > Tony, > > Can you please help reviewing this trivial fix? > Changes are about overriding the SHA1withDSA signature upper limit to > 1024 when larger DSA key size is supported. > > Webrev: http://cr.openjdk.java.net/~valeriep/8046046/webrev.00/ > > Thanks, > Valerie From sean.mullan at oracle.com Thu Jun 19 13:52:45 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Jun 2014 09:52:45 -0400 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf In-Reply-To: References: <53468310.2090506@oracle.com> <53A1BB8E.6040200@oracle.com> Message-ID: <53A2EB2D.2070506@oracle.com> On 06/19/2014 01:39 AM, Wang Weijun wrote: >> >570 public Void run() throws Exception { >> > >> >This can be declared to throw IOException, then you can change lines 586-591 to: >> > >> >throw pe.getException(); > You mean javac will be smart enough to find out that pe's cause can only be IOException? It does not compile here. Sorry, you are right, you still need to cast it to IOException, but you don't need to catch any other Exceptions. See the example/rationale in the AccessController class description. --Sean From weijun.wang at oracle.com Thu Jun 19 14:15:39 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Jun 2014 22:15:39 +0800 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf In-Reply-To: <53A2EB2D.2070506@oracle.com> References: <53468310.2090506@oracle.com> <53A1BB8E.6040200@oracle.com> <53A2EB2D.2070506@oracle.com> Message-ID: <67D7034B-74D1-4E80-8C6A-7817E0F570D1@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8029994/webrev.02/ Besides your suggestions, I've changed the final line in the constructor from throw new KrbException(joe) to 202 if (DEBUG) { 203 System.out.println("Exception thrown in loading config:"); 204 ioe.printStackTrace(System.out); 205 } 206 throw new KrbException("krb5.conf loading failed"); If the IOE contains info like "/etc/krb5.conf.2 not found", the file name will be removed. On Jun 19, 2014, at 21:52, Sean Mullan wrote: > On 06/19/2014 01:39 AM, Wang Weijun wrote: >>> >570 public Void run() throws Exception { >>> > >>> >This can be declared to throw IOException, then you can change lines 586-591 to: >>> > >>> >throw pe.getException(); >> You mean javac will be smart enough to find out that pe's cause can only be IOException? It does not compile here. > > Sorry, you are right, you still need to cast it to IOException, but you don't need to catch any other Exceptions. See the example/rationale in the AccessController class description. Maybe we can change PrivilegedActionException to PrivilegedActionException? Thanks Max From sean.mullan at oracle.com Thu Jun 19 14:39:32 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Jun 2014 10:39:32 -0400 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf In-Reply-To: <67D7034B-74D1-4E80-8C6A-7817E0F570D1@oracle.com> References: <53468310.2090506@oracle.com> <53A1BB8E.6040200@oracle.com> <53A2EB2D.2070506@oracle.com> <67D7034B-74D1-4E80-8C6A-7817E0F570D1@oracle.com> Message-ID: <53A2F624.70303@oracle.com> Looks good to me. --Sean On 06/19/2014 10:15 AM, Wang Weijun wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8029994/webrev.02/ > > Besides your suggestions, I've changed the final line in the constructor from > > throw new KrbException(joe) > > to > > 202 if (DEBUG) { > 203 System.out.println("Exception thrown in loading config:"); > 204 ioe.printStackTrace(System.out); > 205 } > 206 throw new KrbException("krb5.conf loading failed"); > > If the IOE contains info like "/etc/krb5.conf.2 not found", the file name will be removed. > > On Jun 19, 2014, at 21:52, Sean Mullan wrote: > >> On 06/19/2014 01:39 AM, Wang Weijun wrote: >>>>> 570 public Void run() throws Exception { >>>>> >>>>> This can be declared to throw IOException, then you can change lines 586-591 to: >>>>> >>>>> throw pe.getException(); >>> You mean javac will be smart enough to find out that pe's cause can only be IOException? It does not compile here. >> >> Sorry, you are right, you still need to cast it to IOException, but you don't need to catch any other Exceptions. See the example/rationale in the AccessController class description. > > Maybe we can change PrivilegedActionException to PrivilegedActionException? > > Thanks > Max > From vincent.x.ryan at oracle.com Thu Jun 19 16:59:20 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 19 Jun 2014 17:59:20 +0100 Subject: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded Message-ID: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com> Please review the following simple changeset to identify the offending JAR file following a signature verification error. Previously, only the offending entry in the JAR was identified. This helps during troubleshooting when several JAR files being processed. The request was originally submitted by Aaron Digulla. Bug: https://bugs.openjdk.java.net/browse/JDK-8047353 Webrev: http://cr.openjdk.java.net/~vinnie/8047353/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Thu Jun 19 21:21:59 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 19 Jun 2014 22:21:59 +0100 Subject: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded In-Reply-To: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com> References: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com> Message-ID: I shortened the output to display only the JAR filename to avoid leaking filesystem information. I?ve updated the webrev in-place. Thanks. On 19 Jun 2014, at 17:59, Vincent Ryan wrote: > Please review the following simple changeset to identify the offending JAR file following a signature verification error. > Previously, only the offending entry in the JAR was identified. > > This helps during troubleshooting when several JAR files being processed. > > The request was originally submitted by Aaron Digulla. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047353 > Webrev: http://cr.openjdk.java.net/~vinnie/8047353/webrev.00/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jun 19 21:49:32 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 19 Jun 2014 14:49:32 -0700 Subject: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded In-Reply-To: References: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com> Message-ID: <53A35AEC.9080708@oracle.com> Hello, I'd prefer to see the CheckJarSigError.sh as a Java program. Cheers, -Joe On 06/19/2014 02:21 PM, Vincent Ryan wrote: > I shortened the output to display only the JAR filename to avoid leaking filesystem information. > I?ve updated the webrev in-place. > > Thanks. > > > On 19 Jun 2014, at 17:59, Vincent Ryan wrote: > >> Please review the following simple changeset to identify the offending JAR file following a signature verification error. >> Previously, only the offending entry in the JAR was identified. >> >> This helps during troubleshooting when several JAR files being processed. >> >> The request was originally submitted by Aaron Digulla. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8047353 >> Webrev: http://cr.openjdk.java.net/~vinnie/8047353/webrev.00/ >> >> From jason.uh at oracle.com Fri Jun 20 00:25:01 2014 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 19 Jun 2014 17:25:01 -0700 Subject: [9] Request for Review: 7065233: To interpret case-insensitive string locale independently Message-ID: <53A37F5D.1020005@oracle.com> Hi Xuelei, Could you please review this change? webrev: http://cr.openjdk.java.net/~juh/7065233/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-7065233 I don't think any of the strings in the lines I changed would be locale-sensitive. There are a few cases fixed here that weren't included in the bug description. noreg-trivial. Thanks, Jason From jamil.j.nimeh at oracle.com Fri Jun 20 01:11:19 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 19 Jun 2014 18:11:19 -0700 Subject: RFR: 8015081 In-Reply-To: <539F31F3.2070700@oracle.com> References: <539F31F3.2070700@oracle.com> Message-ID: <53A38A37.8090909@oracle.com> Hello all, This revision for the fix for 8015081 has the following test changes: Removal of the static byte buffers for serialized data in lieu of a more dynamic approach. A stripped down version of Subject in its own package is now being compiled alongside SubjectNullTests.java. This version of Subject allows the creation and serialization of Subjects with null elements in the principals SecureSet. Immediately following serialization, this special Subject's class designation is overwritten to be javax.security.auth.Subject. When deserialization occurs, the correct (JDK 9) version of Subject will be used and null element checks will take place. Thanks go to Weijun Wang for this testing approach. http://cr.openjdk.java.net/~weijun/8015081/webrev.07 --Jamil From xuelei.fan at oracle.com Fri Jun 20 01:40:19 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 20 Jun 2014 09:40:19 +0800 Subject: [9] Request for Review: 7065233: To interpret case-insensitive string locale independently In-Reply-To: <53A37F5D.1020005@oracle.com> References: <53A37F5D.1020005@oracle.com> Message-ID: <53A39103.5030607@oracle.com> Looks fine to me. Thanks, Xuelei On 6/20/2014 8:25 AM, Jason Uh wrote: > Hi Xuelei, > > Could you please review this change? > webrev: http://cr.openjdk.java.net/~juh/7065233/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-7065233 > > I don't think any of the strings in the lines I changed would be > locale-sensitive. There are a few cases fixed here that weren't included > in the bug description. > > noreg-trivial. > > Thanks, > Jason From vincent.x.ryan at oracle.com Fri Jun 20 12:21:46 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 20 Jun 2014 13:21:46 +0100 Subject: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded In-Reply-To: <26b8-53a40600-d-41ced200@248413781> References: <26b8-53a40600-d-41ced200@248413781> Message-ID: Hello Aaron, I considered using your testcase that manually generates the necessary malformed JAR but as there was a suitable signed JAR already in the test suite I decided to re-use that. I think it makes sense to re-work the test as a Java program. Unfortunately I?ll be on vacation from today but I?ll return to this issue when I get back. Thanks. On 20 Jun 2014, at 11:00, Aaron Digulla wrote: > Am Donnerstag, 19. Juni 2014 23:49 CEST, Joe Darcy schrieb: > >> I'd prefer to see the CheckJarSigError.sh as a Java program. > > There original bug report contains a full self-contained test case in Java. Why was that split into several files? > > I'm also a bit uneasy about the "just show the file name". I have thousands of JARs with the same name on my harddisk (several Maven repos, target folders, you name it). If you strip the path from the error message, then I have to somehow figure out the classpath which was used. > > That might work when I run Java from the command line but when I use complex frameworks like OSGi or Maven which do all kinds of magic to determine which JARs they might want to load, then this doesn't help much. > > > At least add a command line option / system property which allows to see the full path. > > Regards, > > -- > Aaron "Optimizer" Digulla a.k.a. Philmann Dark > "It's not the universe that's limited, it's our imagination. > Follow me and I'll show you something beyond the limits." > http://blog.pdark.de/ From vincent.x.ryan at oracle.com Fri Jun 20 12:58:00 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 20 Jun 2014 13:58:00 +0100 Subject: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded In-Reply-To: References: <26b8-53a40600-d-41ced200@248413781> Message-ID: There is precedence for revealing the full pathname only when a security manager is not running. Would that be acceptable? On 20 Jun 2014, at 13:21, Vincent Ryan wrote: > Hello Aaron, > > I considered using your testcase that manually generates the necessary malformed JAR > but as there was a suitable signed JAR already in the test suite I decided to re-use that. > > I think it makes sense to re-work the test as a Java program. Unfortunately I?ll be on vacation > from today but I?ll return to this issue when I get back. > > Thanks. > > > > On 20 Jun 2014, at 11:00, Aaron Digulla wrote: > >> Am Donnerstag, 19. Juni 2014 23:49 CEST, Joe Darcy schrieb: >> >>> I'd prefer to see the CheckJarSigError.sh as a Java program. >> >> There original bug report contains a full self-contained test case in Java. Why was that split into several files? >> >> I'm also a bit uneasy about the "just show the file name". I have thousands of JARs with the same name on my harddisk (several Maven repos, target folders, you name it). If you strip the path from the error message, then I have to somehow figure out the classpath which was used. >> >> That might work when I run Java from the command line but when I use complex frameworks like OSGi or Maven which do all kinds of magic to determine which JARs they might want to load, then this doesn't help much. >> >> >> At least add a command line option / system property which allows to see the full path. >> >> Regards, >> >> -- >> Aaron "Optimizer" Digulla a.k.a. Philmann Dark >> "It's not the universe that's limited, it's our imagination. >> Follow me and I'll show you something beyond the limits." >> http://blog.pdark.de/ > From sean.mullan at oracle.com Fri Jun 20 15:46:47 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Jun 2014 11:46:47 -0400 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53A21802.7040209@oracle.com> References: <53A21802.7040209@oracle.com> Message-ID: <53A45767.1090602@oracle.com> 36 // Needed by Runtime.loadLibrary(String) call 37 permission java.io.FilePermission "<>", "read"; It seems like this is due to a bug in Runtime.loadLibrary, since you have already granted the provider the permission to load the library. I think possibly the call to ClassLoader.loadLibrary should be inside a doPrivileged. The workaround is ok for now, but can you file a separate bug for this? --Sean On 06/18/2014 06:51 PM, Valerie Peng wrote: > Sean, > > Not sure if you can get to reviewing this before your vacation. > If not, I will find someone else to help... > > Webrev: http://cr.openjdk.java.net/~valeriep/8043406/webrev.00/ > > Thanks, > Valerie From henry.jen at oracle.com Fri Jun 20 18:46:55 2014 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 20 Jun 2014 11:46:55 -0700 Subject: RFR: 8047721: @since should have JDK version Message-ID: <53A4819F.5080906@oracle.com> Hi, Please review a trivial webrev to add JDK version to @since in a format as Mark suggested[1]. http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/ [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html Appened is the diff as in the webrev. Cheers, Henry diff --git a/src/share/classes/java/lang/Package.java b/src/share/classes/java/lang/Package.java --- a/src/share/classes/java/lang/Package.java +++ b/src/share/classes/java/lang/Package.java @@ -107,6 +107,7 @@ * loader to be found. * * @see ClassLoader#definePackage + * @since 1.2 */ public class Package implements java.lang.reflect.AnnotatedElement { /** diff --git a/src/share/classes/javax/crypto/CipherInputStream.java b/src/share/classes/javax/crypto/CipherInputStream.java --- a/src/share/classes/javax/crypto/CipherInputStream.java +++ b/src/share/classes/javax/crypto/CipherInputStream.java @@ -170,7 +170,7 @@ * @return the next byte of data, or -1 if the end of the * stream is reached. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int read() throws IOException { if (ostart >= ofinish) { @@ -196,7 +196,7 @@ * the stream has been reached. * @exception IOException if an I/O error occurs. * @see java.io.InputStream#read(byte[], int, int) - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int read(byte b[]) throws IOException { return read(b, 0, b.length); @@ -217,7 +217,7 @@ * the stream has been reached. * @exception IOException if an I/O error occurs. * @see java.io.InputStream#read() - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int read(byte b[], int off, int len) throws IOException { if (ostart >= ofinish) { @@ -254,7 +254,7 @@ * @param n the number of bytes to be skipped. * @return the actual number of bytes skipped. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public long skip(long n) throws IOException { int available = ofinish - ostart; @@ -277,7 +277,7 @@ * @return the number of bytes that can be read from this input stream * without blocking. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int available() throws IOException { return (ofinish - ostart); @@ -292,7 +292,7 @@ * stream. * * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void close() throws IOException { if (closed) { @@ -321,7 +321,7 @@ * mark and reset methods. * @see java.io.InputStream#mark(int) * @see java.io.InputStream#reset() - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public boolean markSupported() { return false; diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java b/src/share/classes/javax/crypto/CipherOutputStream.java --- a/src/share/classes/javax/crypto/CipherOutputStream.java +++ b/src/share/classes/javax/crypto/CipherOutputStream.java @@ -114,7 +114,7 @@ * * @param b the byte. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void write(int b) throws IOException { ibuffer[0] = (byte) b; @@ -138,7 +138,7 @@ * @exception NullPointerException if b is null. * @exception IOException if an I/O error occurs. * @see javax.crypto.CipherOutputStream#write(byte[], int, int) - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void write(byte b[]) throws IOException { write(b, 0, b.length); @@ -152,7 +152,7 @@ * @param off the start offset in the data. * @param len the number of bytes to write. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void write(byte b[], int off, int len) throws IOException { obuffer = cipher.update(b, off, len); @@ -174,7 +174,7 @@ * the cipher's block size, no bytes will be written out. * * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void flush() throws IOException { if (obuffer != null) { @@ -198,7 +198,7 @@ * stream. * * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void close() throws IOException { if (closed) { diff --git a/src/share/classes/javax/naming/InitialContext.java b/src/share/classes/javax/naming/InitialContext.java --- a/src/share/classes/javax/naming/InitialContext.java +++ b/src/share/classes/javax/naming/InitialContext.java @@ -125,7 +125,7 @@ * @see Context * @see NamingManager#setInitialContextFactoryBuilder * NamingManager.setInitialContextFactoryBuilder - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 + * @since 1.3, JNDI 1.1 */ public class InitialContext implements Context { From valerie.peng at oracle.com Fri Jun 20 22:30:44 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 20 Jun 2014 15:30:44 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53A45767.1090602@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> Message-ID: <53A4B614.90900@oracle.com> Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8043406/webrev.01 Sure, I will file a bug after Mandy's confirmation. Thanks, Valerie On 6/20/2014 8:46 AM, Sean Mullan wrote: > 36 // Needed by Runtime.loadLibrary(String) call > 37 permission java.io.FilePermission "<>", "read"; > > It seems like this is due to a bug in Runtime.loadLibrary, since you > have already granted the provider the permission to load the library. > I think possibly the call to ClassLoader.loadLibrary should be inside > a doPrivileged. The workaround is ok for now, but can you file a > separate bug for this? > > --Sean > > On 06/18/2014 06:51 PM, Valerie Peng wrote: >> Sean, >> >> Not sure if you can get to reviewing this before your vacation. >> If not, I will find someone else to help... >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8043406/webrev.00/ >> >> Thanks, >> Valerie From valerie.peng at oracle.com Fri Jun 20 22:32:59 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 20 Jun 2014 15:32:59 -0700 Subject: RFR 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics In-Reply-To: <53A26ED8.70908@oracle.com> References: <537548EE.5050909@oracle.com> <53A20A47.4010602@oracle.com> <53A26ED8.70908@oracle.com> Message-ID: <53A4B69B.6030001@oracle.com> Hmm, maybe. I will add one. Thanks for the review. Valerie On 6/18/2014 10:02 PM, Anthony Scarpino wrote: > The code change looks fine. Do you think this is worth a regression > test? Since the in-place operation wasn't caught it sound like there > might be no in-place tests > > Tony > > On 06/18/2014 02:53 PM, Valerie Peng wrote: >> >> Tony or Vinnie, either of you have time to review? >> Thanks, >> Valerie >> >> On 5/15/2014 4:08 PM, Valerie (Yu-Ching) Peng wrote: >>> >>> Can someone help reviewing this SunJCE provider fix? Essentially, >>> CipherCore class is updated to minimize memory allocation and data >>> copying. The fix has been verified against the wls_webapp_atomics >>> benchmark. >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8027575/webrev.00/ >>> >>> Thanks, >>> Valerie > From mandy.chung at oracle.com Fri Jun 20 23:57:26 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Jun 2014 16:57:26 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53A4B614.90900@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> Message-ID: <53A4CA66.6060407@oracle.com> On 6/20/2014 3:30 PM, Valerie Peng wrote: > > Webrev is updated at: > http://cr.openjdk.java.net/~valeriep/8043406/webrev.01 Thanks Valerie. Good to see the security providers granting only the permissions it requires. Looks okay to me. > Sure, I will file a bug after Mandy's confirmation. Yes please file a bug and it does look like a bug in the loadLibrary. I'll look into it. It'd be helpful if you can include a stack trace in the JBS issue without granting FilePermission to access all files. Thanks Mandy > Thanks, > Valerie > > On 6/20/2014 8:46 AM, Sean Mullan wrote: >> 36 // Needed by Runtime.loadLibrary(String) call >> 37 permission java.io.FilePermission "<>", "read"; >> >> It seems like this is due to a bug in Runtime.loadLibrary, since you >> have already granted the provider the permission to load the library. >> I think possibly the call to ClassLoader.loadLibrary should be inside >> a doPrivileged. The workaround is ok for now, but can you file a >> separate bug for this? >> >> --Sean >> >> On 06/18/2014 06:51 PM, Valerie Peng wrote: >>> Sean, >>> >>> Not sure if you can get to reviewing this before your vacation. >>> If not, I will find someone else to help... >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8043406/webrev.00/ >>> >>> Thanks, >>> Valerie From martinrb at google.com Sun Jun 22 04:05:23 2014 From: martinrb at google.com (Martin Buchholz) Date: Sat, 21 Jun 2014 21:05:23 -0700 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53A44C3A.6000607@oracle.com> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> Message-ID: While looking at NativePRNG, I filed https://bugs.openjdk.java.net/browse/JDK-8047769 SecureRandom should be more frugal with file descriptors If I run this java program on Linux public class SecureRandoms { public static void main(String[] args) throws Throwable { new java.security.SecureRandom(); } } it creates 6 file descriptors for /dev/random and /dev/urandom, as shown by: strace -q -ff -e open java SecureRandoms |& grep /dev/ [pid 20769] open("/dev/random", O_RDONLY) = 5 [pid 20769] open("/dev/urandom", O_RDONLY) = 6 [pid 20769] open("/dev/random", O_RDONLY) = 7 [pid 20769] open("/dev/random", O_RDONLY) = 8 [pid 20769] open("/dev/urandom", O_RDONLY) = 9 [pid 20769] open("/dev/urandom", O_RDONLY) = 10 Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java it looks like 2 file descriptors are created for every variant of NativePRNG, whether or not they are ever used. Which is wasteful. In fact, you only ever need at most two file descriptors, one for /dev/random and one for /dev/urandom. Further, it would be nice if the file descriptors were closed when idle and lazily re-created. Especially /dev/random should typically be used at startup and never thereafter. On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman wrote: > On 20/06/2014 15:02, Peter Levart wrote: > >> >> And, as Martin pointed out, it seems to be used for tests that exercise >> particular responses from NameService API to test the behaviour of JDK >> classes. It would be a shame for those tests to go away. >> > We've been talking about removing it for many years because it has been so > troublesome. If we really need to having something for testing then I don't > think it needs to be general purpose, we can get right of the lookup at > least. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Sun Jun 22 17:12:02 2014 From: martinrb at google.com (Martin Buchholz) Date: Sun, 22 Jun 2014 10:12:02 -0700 Subject: ThreadLocalRandom clinit troubles In-Reply-To: References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> Message-ID: We know that loading the networking machinery is problematic. On Linux we would be content to hard-code a read from /dev/urandom, which is safer and strictly more random than the existing network hardware determination, but y'all will reject that as too system-dependent (insufficient machinery!). Hmmmm .... maybe not .... as long as we code up a good fallback ... I learned that SecureRandom by default on Unix uses /dev/random for "seed bytes" and /dev/urandom for nextBytes. Here's my proposal, that in the default case on Unix doesn't load any machinery, and as a fallback loads the SecureRandom machinery instead of the network machinery, while maintaining the ultra-secure behavior of the java.util.secureRandomSeed system property: private static long initialSeed() { byte[] seedBytes = initialSeedBytes(); long s = (long)(seedBytes[0]) & 0xffL; for (int i = 1; i < seedBytes.length; ++i) s = (s << 8) | ((long)(seedBytes[i]) & 0xffL); return s ^ mix64(System.currentTimeMillis()) ^ mix64(System.nanoTime()); } private static byte[] initialSeedBytes() { String pp = java.security.AccessController.doPrivileged( new sun.security.action.GetPropertyAction( "java.util.secureRandomSeed")); boolean secureRandomSeed = (pp != null && pp.equalsIgnoreCase("true")); if (secureRandomSeed) return java.security.SecureRandom.getSeed(8); final byte[] seedBytes = new byte[8]; File seedSource = new File("/dev/urandom"); if (seedSource.exists()) { try (FileInputStream stream = new FileInputStream(seedSource)) { if (stream.read(seedBytes) == 8) return seedBytes; } catch (IOException ignore) { } } new java.security.SecureRandom().nextBytes(seedBytes); return seedBytes; } On Sat, Jun 21, 2014 at 9:05 PM, Martin Buchholz wrote: > While looking at NativePRNG, I filed > > https://bugs.openjdk.java.net/browse/JDK-8047769 > > SecureRandom should be more frugal with file descriptors > > If I run this java program on Linux > > public class SecureRandoms { > public static void main(String[] args) throws Throwable { > new java.security.SecureRandom(); > } > } > > it creates 6 file descriptors for /dev/random and /dev/urandom, as shown > by: > > strace -q -ff -e open java SecureRandoms |& grep /dev/ > [pid 20769] open("/dev/random", O_RDONLY) = 5 > [pid 20769] open("/dev/urandom", O_RDONLY) = 6 > [pid 20769] open("/dev/random", O_RDONLY) = 7 > [pid 20769] open("/dev/random", O_RDONLY) = 8 > [pid 20769] open("/dev/urandom", O_RDONLY) = 9 > [pid 20769] open("/dev/urandom", O_RDONLY) = 10 > > Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java > it looks like 2 file descriptors are created for every variant of > NativePRNG, whether or not they are ever used. Which is wasteful. In fact, > you only ever need at most two file descriptors, one for /dev/random and > one for /dev/urandom. > > Further, it would be nice if the file descriptors were closed when idle > and lazily re-created. Especially /dev/random should typically be used at > startup and never thereafter. > > > On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman > wrote: > >> On 20/06/2014 15:02, Peter Levart wrote: >> >>> >>> And, as Martin pointed out, it seems to be used for tests that exercise >>> particular responses from NameService API to test the behaviour of JDK >>> classes. It would be a shame for those tests to go away. >>> >> We've been talking about removing it for many years because it has been >> so troublesome. If we really need to having something for testing then I >> don't think it needs to be general purpose, we can get right of the lookup >> at least. >> >> -Alan. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Sun Jun 22 18:54:24 2014 From: martinrb at google.com (Martin Buchholz) Date: Sun, 22 Jun 2014 11:54:24 -0700 Subject: [concurrency-interest] ThreadLocalRandom.nextSecondarySeed() re-initializes TLR's seed In-Reply-To: <53A3F3F7.9010506@gmail.com> References: <53A2A155.3040509@gmail.com> <53A2A3D8.8000602@gmail.com> <53A2D13E.4020006@cs.oswego.edu> <53A3F3F7.9010506@gmail.com> Message-ID: On Fri, Jun 20, 2014 at 1:42 AM, Peter Levart wrote: > > This pertains to the other thread (ThreadLocalRandom clinit troubles) > started by Martin Buchholz, right? He's making a valid point. The "seeder" > static field is still uninitialized during either NetworkInterface class > initialization (as a result of NetworkInterface.getNetworkInterfaces() > call) or during SecureRandom.getSeed() call. Either of which can execute > user code in some configurations which might in turn use ThreadLocalRandom. > If this happens, TLR.current() throws a NPE. I proposed a re-arrangement of > class initialization that allows TLR to be fully functional even during > it's initialization, albeit with a less randomized seed, and does not > change the behaviour otherwise (since it triggers re-initialization at the > end). See the proposed patch in the other thread. > I tried this same approach, and found that: yes, we see some previously failing tests that start passing when the TLR is functional even while executing its own clinit method, BUT there are other tests that still fail, and only start passing when the network init code is removed ... for unknown reasons. We could debug them, but the fundamental danger remains - TLR may be invoked very early during JDK startup, and it is simply too risky to load higher-level libraries so early, possibly invoking foreign code that might do anything. Which is why I keep trying to minimize TLR's external dependencies. Whatever we decide to do here, the same changes should be made to SplittableRandom. Maybe there's scope for some refactoring/sharing, both of code and of file system access at runtime. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Jun 23 08:09:09 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 23 Jun 2014 16:09:09 +0800 Subject: RFR 7150092: NTLM authentication fail if user specified a different realm In-Reply-To: <4C46F4A8-4CCB-4075-B594-FA9B51C2F692@oracle.com> References: <4C46F4A8-4CCB-4075-B594-FA9B51C2F692@oracle.com> Message-ID: Ping again. On Jun 12, 2014, at 14:07, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/7150092/webrev.00/ > > The problem is that in NTLM, the server might prompt for a domain name (in Type 2 message), and the client can also provide one. Before this fix, if the two are different, the client chooses the one from the server. After this fix, the client will always uses its own even if it's empty. This is confirmed by looking at the behavior of IE/Firefox/Chrome. The server sent domain name was designed to be used to create the NTLMv2 response but it's now obsoleted by alist. Chrome/Firefox simply ignore it, so will Java. (IE does use it if there is no alist) > > There are some other small changes: > > Client.java > ----------- > > 96-108: No one sends hostname and domain in the Type 1 message, so they are removed. Everyone adds a 0x4 flag which means Request Target. > > Removed old 137-139: That's the major change. > > 159: I used to detect whether there is an alist by looking at the length. This is not accurate if the domain is very long. The correct way is to look at the flag (0x800000 means alist is there) > > Server.java > ----------- > > 98: Adds a flag 0x10000 which means the target name (line 99) written into the message is a domain > > 135: Always uses the client provided domain to search for password. This is also a part of the major change. > > NTLMClient.java > --------------- > > If user has not responded to NameCallback and/or RealmCallback, it means they accept the default value. > > NTLMServer.java > --------------- > > ntdomain could be empty or null, the 2-arg constructor of RealmCallback could fail in this case. Use 1-arg constructor. > > NTLMAuthentication.java > ----------------------- > > According to my observation of IE/Firefox/Chrome, when user does not type in a domain name in the password prompting dialog, the domain sent to server is an empty string, and the host name is always full name. Update Java to be the same. > > NTLMTest.java > ------------- > > Update the test to reflect code changes. > > Thanks > Max > From bradford.wetmore at oracle.com Mon Jun 23 17:04:34 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 23 Jun 2014 10:04:34 -0700 Subject: RFR: 8047721: @since should have JDK version In-Reply-To: <53A4819F.5080906@oracle.com> References: <53A4819F.5080906@oracle.com> Message-ID: <53A85E22.1000009@oracle.com> I would prefer that JCE1.2 be pulled out completely in the Cipher* classes. I will be sending you a separate note about JCE logistics. Thanks for doing this cleanup. Brad On 6/20/2014 11:46 AM, Henry Jen wrote: > Hi, > > Please review a trivial webrev to add JDK version to @since in a format > as Mark suggested[1]. > > http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/ > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html > > Appened is the diff as in the webrev. > > Cheers, > Henry > > > diff --git a/src/share/classes/java/lang/Package.java > b/src/share/classes/java/lang/Package.java > --- a/src/share/classes/java/lang/Package.java > +++ b/src/share/classes/java/lang/Package.java > @@ -107,6 +107,7 @@ > * loader to be found. > * > * @see ClassLoader#definePackage > + * @since 1.2 > */ > public class Package implements java.lang.reflect.AnnotatedElement { > /** > diff --git a/src/share/classes/javax/crypto/CipherInputStream.java > b/src/share/classes/javax/crypto/CipherInputStream.java > --- a/src/share/classes/javax/crypto/CipherInputStream.java > +++ b/src/share/classes/javax/crypto/CipherInputStream.java > @@ -170,7 +170,7 @@ > * @return the next byte of data, or -1 if the end > of the > * stream is reached. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int read() throws IOException { > if (ostart >= ofinish) { > @@ -196,7 +196,7 @@ > * the stream has been reached. > * @exception IOException if an I/O error occurs. > * @see java.io.InputStream#read(byte[], int, int) > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int read(byte b[]) throws IOException { > return read(b, 0, b.length); > @@ -217,7 +217,7 @@ > * the stream has been reached. > * @exception IOException if an I/O error occurs. > * @see java.io.InputStream#read() > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int read(byte b[], int off, int len) throws IOException { > if (ostart >= ofinish) { > @@ -254,7 +254,7 @@ > * @param n the number of bytes to be skipped. > * @return the actual number of bytes skipped. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public long skip(long n) throws IOException { > int available = ofinish - ostart; > @@ -277,7 +277,7 @@ > * @return the number of bytes that can be read from this > input stream > * without blocking. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int available() throws IOException { > return (ofinish - ostart); > @@ -292,7 +292,7 @@ > * stream. > * > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void close() throws IOException { > if (closed) { > @@ -321,7 +321,7 @@ > * mark and reset methods. > * @see java.io.InputStream#mark(int) > * @see java.io.InputStream#reset() > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public boolean markSupported() { > return false; > diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java > b/src/share/classes/javax/crypto/CipherOutputStream.java > --- a/src/share/classes/javax/crypto/CipherOutputStream.java > +++ b/src/share/classes/javax/crypto/CipherOutputStream.java > @@ -114,7 +114,7 @@ > * > * @param b the byte. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void write(int b) throws IOException { > ibuffer[0] = (byte) b; > @@ -138,7 +138,7 @@ > * @exception NullPointerException if b is null. > * @exception IOException if an I/O error occurs. > * @see javax.crypto.CipherOutputStream#write(byte[], int, > int) > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void write(byte b[]) throws IOException { > write(b, 0, b.length); > @@ -152,7 +152,7 @@ > * @param off the start offset in the data. > * @param len the number of bytes to write. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void write(byte b[], int off, int len) throws IOException { > obuffer = cipher.update(b, off, len); > @@ -174,7 +174,7 @@ > * the cipher's block size, no bytes will be written out. > * > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void flush() throws IOException { > if (obuffer != null) { > @@ -198,7 +198,7 @@ > * stream. > * > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void close() throws IOException { > if (closed) { > diff --git a/src/share/classes/javax/naming/InitialContext.java > b/src/share/classes/javax/naming/InitialContext.java > --- a/src/share/classes/javax/naming/InitialContext.java > +++ b/src/share/classes/javax/naming/InitialContext.java > @@ -125,7 +125,7 @@ > * @see Context > * @see NamingManager#setInitialContextFactoryBuilder > * NamingManager.setInitialContextFactoryBuilder > - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 > + * @since 1.3, JNDI 1.1 > */ > > public class InitialContext implements Context { > From bradford.wetmore at oracle.com Mon Jun 23 17:43:39 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 23 Jun 2014 10:43:39 -0700 Subject: ThreadLocalRandom clinit troubles In-Reply-To: References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> Message-ID: <53A8674B.9080000@oracle.com> Martin, Thanks for filing. I was positive there was already a bug for this, but for the life of me I can't find it now. There's some other more minor cleanup that needs to take place, but seems like I've been in escalation/firefighting mode for more than a year now and it hasn't bubbled to the top. Brad On 6/21/2014 9:05 PM, Martin Buchholz wrote: > While looking at NativePRNG, I filed > > https://bugs.openjdk.java.net/browse/JDK-8047769 > > SecureRandom should be more frugal with file descriptors > > If I run this java program on Linux > > public class SecureRandoms { > public static void main(String[] args) throws Throwable { > new java.security.SecureRandom(); > } > } > > it creates 6 file descriptors for /dev/random and /dev/urandom, as shown > by: > > strace -q -ff -e open java SecureRandoms |& grep /dev/ > [pid 20769] open("/dev/random", O_RDONLY) = 5 > [pid 20769] open("/dev/urandom", O_RDONLY) = 6 > [pid 20769] open("/dev/random", O_RDONLY) = 7 > [pid 20769] open("/dev/random", O_RDONLY) = 8 > [pid 20769] open("/dev/urandom", O_RDONLY) = 9 > [pid 20769] open("/dev/urandom", O_RDONLY) = 10 > > Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java > it looks like 2 file descriptors are created for every variant of > NativePRNG, whether or not they are ever used. Which is wasteful. In > fact, you only ever need at most two file descriptors, one for > /dev/random and one for /dev/urandom. > > Further, it would be nice if the file descriptors were closed when idle > and lazily re-created. Especially /dev/random should typically be used > at startup and never thereafter. > > > On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman > wrote: > > On 20/06/2014 15:02, Peter Levart wrote: > > > And, as Martin pointed out, it seems to be used for tests that > exercise particular responses from NameService API to test the > behaviour of JDK classes. It would be a shame for those tests to > go away. > > We've been talking about removing it for many years because it has > been so troublesome. If we really need to having something for > testing then I don't think it needs to be general purpose, we can > get right of the lookup at least. > > -Alan. > > From mandy.chung at oracle.com Mon Jun 23 20:18:49 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Jun 2014 13:18:49 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53A4CA66.6060407@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> <53A4CA66.6060407@oracle.com> Message-ID: <53A88BA9.2060409@oracle.com> Valerie, On 6/20/14 4:57 PM, Mandy Chung wrote: > > Yes please file a bug and it does look like a bug in the loadLibrary. > I'll look into it. It'd be helpful if you can include a stack trace > in the JBS issue without granting FilePermission to access all files. I have a patch and going to send the review request to core-libs. So I went ahead and file the bug: https://bugs.openjdk.java.net/browse/JDK-8047904 Thanks Mandy From henry.jen at oracle.com Mon Jun 23 20:50:03 2014 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 23 Jun 2014 13:50:03 -0700 Subject: RFR: 8047721: @since should have JDK version In-Reply-To: <53A85E22.1000009@oracle.com> References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com> Message-ID: <53A892FB.8060507@oracle.com> OK, I'll remove all @since JCE line, as the class already has @since 1.4 as Joe pointed out earlier. Uodated webrev at http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/ Cheers, Henry On 06/23/2014 10:04 AM, Bradford Wetmore wrote: > I would prefer that JCE1.2 be pulled out completely in the Cipher* > classes. I will be sending you a separate note about JCE logistics. > > Thanks for doing this cleanup. > > Brad > > > On 6/20/2014 11:46 AM, Henry Jen wrote: >> Hi, >> >> Please review a trivial webrev to add JDK version to @since in a format >> as Mark suggested[1]. >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/ >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html >> >> Appened is the diff as in the webrev. >> >> Cheers, >> Henry >> >> >> diff --git a/src/share/classes/java/lang/Package.java >> b/src/share/classes/java/lang/Package.java >> --- a/src/share/classes/java/lang/Package.java >> +++ b/src/share/classes/java/lang/Package.java >> @@ -107,6 +107,7 @@ >> * loader to be found. >> * >> * @see ClassLoader#definePackage >> + * @since 1.2 >> */ >> public class Package implements java.lang.reflect.AnnotatedElement { >> /** >> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java >> b/src/share/classes/javax/crypto/CipherInputStream.java >> --- a/src/share/classes/javax/crypto/CipherInputStream.java >> +++ b/src/share/classes/javax/crypto/CipherInputStream.java >> @@ -170,7 +170,7 @@ >> * @return the next byte of data, or -1 if the end >> of the >> * stream is reached. >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public int read() throws IOException { >> if (ostart >= ofinish) { >> @@ -196,7 +196,7 @@ >> * the stream has been reached. >> * @exception IOException if an I/O error occurs. >> * @see java.io.InputStream#read(byte[], int, int) >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public int read(byte b[]) throws IOException { >> return read(b, 0, b.length); >> @@ -217,7 +217,7 @@ >> * the stream has been reached. >> * @exception IOException if an I/O error occurs. >> * @see java.io.InputStream#read() >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public int read(byte b[], int off, int len) throws IOException { >> if (ostart >= ofinish) { >> @@ -254,7 +254,7 @@ >> * @param n the number of bytes to be skipped. >> * @return the actual number of bytes skipped. >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public long skip(long n) throws IOException { >> int available = ofinish - ostart; >> @@ -277,7 +277,7 @@ >> * @return the number of bytes that can be read from this >> input stream >> * without blocking. >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public int available() throws IOException { >> return (ofinish - ostart); >> @@ -292,7 +292,7 @@ >> * stream. >> * >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public void close() throws IOException { >> if (closed) { >> @@ -321,7 +321,7 @@ >> * mark and reset methods. >> * @see java.io.InputStream#mark(int) >> * @see java.io.InputStream#reset() >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public boolean markSupported() { >> return false; >> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java >> b/src/share/classes/javax/crypto/CipherOutputStream.java >> --- a/src/share/classes/javax/crypto/CipherOutputStream.java >> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java >> @@ -114,7 +114,7 @@ >> * >> * @param b the byte. >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public void write(int b) throws IOException { >> ibuffer[0] = (byte) b; >> @@ -138,7 +138,7 @@ >> * @exception NullPointerException if b is null. >> * @exception IOException if an I/O error occurs. >> * @see javax.crypto.CipherOutputStream#write(byte[], int, >> int) >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public void write(byte b[]) throws IOException { >> write(b, 0, b.length); >> @@ -152,7 +152,7 @@ >> * @param off the start offset in the data. >> * @param len the number of bytes to write. >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public void write(byte b[], int off, int len) throws IOException { >> obuffer = cipher.update(b, off, len); >> @@ -174,7 +174,7 @@ >> * the cipher's block size, no bytes will be written out. >> * >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public void flush() throws IOException { >> if (obuffer != null) { >> @@ -198,7 +198,7 @@ >> * stream. >> * >> * @exception IOException if an I/O error occurs. >> - * @since JCE1.2 >> + * @since 1.4, JCE1.2 >> */ >> public void close() throws IOException { >> if (closed) { >> diff --git a/src/share/classes/javax/naming/InitialContext.java >> b/src/share/classes/javax/naming/InitialContext.java >> --- a/src/share/classes/javax/naming/InitialContext.java >> +++ b/src/share/classes/javax/naming/InitialContext.java >> @@ -125,7 +125,7 @@ >> * @see Context >> * @see NamingManager#setInitialContextFactoryBuilder >> * NamingManager.setInitialContextFactoryBuilder >> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 >> + * @since 1.3, JNDI 1.1 >> */ >> >> public class InitialContext implements Context { >> From joe.darcy at oracle.com Mon Jun 23 20:54:22 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 23 Jun 2014 13:54:22 -0700 Subject: RFR: 8047721: @since should have JDK version In-Reply-To: <53A892FB.8060507@oracle.com> References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com> <53A892FB.8060507@oracle.com> Message-ID: <53A893FE.90001@oracle.com> Looks good to me; thanks, -Joe On 06/23/2014 01:50 PM, Henry Jen wrote: > OK, I'll remove all @since JCE line, as the class already has @since > 1.4 as Joe pointed out earlier. > > Uodated webrev at > > http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/ > > Cheers, > Henry > > > On 06/23/2014 10:04 AM, Bradford Wetmore wrote: >> I would prefer that JCE1.2 be pulled out completely in the Cipher* >> classes. I will be sending you a separate note about JCE logistics. >> >> Thanks for doing this cleanup. >> >> Brad >> >> >> On 6/20/2014 11:46 AM, Henry Jen wrote: >>> Hi, >>> >>> Please review a trivial webrev to add JDK version to @since in a format >>> as Mark suggested[1]. >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/ >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html >>> >>> Appened is the diff as in the webrev. >>> >>> Cheers, >>> Henry >>> >>> >>> diff --git a/src/share/classes/java/lang/Package.java >>> b/src/share/classes/java/lang/Package.java >>> --- a/src/share/classes/java/lang/Package.java >>> +++ b/src/share/classes/java/lang/Package.java >>> @@ -107,6 +107,7 @@ >>> * loader to be found. >>> * >>> * @see ClassLoader#definePackage >>> + * @since 1.2 >>> */ >>> public class Package implements java.lang.reflect.AnnotatedElement { >>> /** >>> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java >>> b/src/share/classes/javax/crypto/CipherInputStream.java >>> --- a/src/share/classes/javax/crypto/CipherInputStream.java >>> +++ b/src/share/classes/javax/crypto/CipherInputStream.java >>> @@ -170,7 +170,7 @@ >>> * @return the next byte of data, or -1 if the end >>> of the >>> * stream is reached. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read() throws IOException { >>> if (ostart >= ofinish) { >>> @@ -196,7 +196,7 @@ >>> * the stream has been reached. >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.InputStream#read(byte[], int, int) >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read(byte b[]) throws IOException { >>> return read(b, 0, b.length); >>> @@ -217,7 +217,7 @@ >>> * the stream has been reached. >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.InputStream#read() >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read(byte b[], int off, int len) throws IOException { >>> if (ostart >= ofinish) { >>> @@ -254,7 +254,7 @@ >>> * @param n the number of bytes to be skipped. >>> * @return the actual number of bytes skipped. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public long skip(long n) throws IOException { >>> int available = ofinish - ostart; >>> @@ -277,7 +277,7 @@ >>> * @return the number of bytes that can be read from this >>> input stream >>> * without blocking. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int available() throws IOException { >>> return (ofinish - ostart); >>> @@ -292,7 +292,7 @@ >>> * stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void close() throws IOException { >>> if (closed) { >>> @@ -321,7 +321,7 @@ >>> * mark and reset methods. >>> * @see java.io.InputStream#mark(int) >>> * @see java.io.InputStream#reset() >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public boolean markSupported() { >>> return false; >>> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java >>> b/src/share/classes/javax/crypto/CipherOutputStream.java >>> --- a/src/share/classes/javax/crypto/CipherOutputStream.java >>> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java >>> @@ -114,7 +114,7 @@ >>> * >>> * @param b the byte. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(int b) throws IOException { >>> ibuffer[0] = (byte) b; >>> @@ -138,7 +138,7 @@ >>> * @exception NullPointerException if b is null. >>> * @exception IOException if an I/O error occurs. >>> * @see javax.crypto.CipherOutputStream#write(byte[], int, >>> int) >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(byte b[]) throws IOException { >>> write(b, 0, b.length); >>> @@ -152,7 +152,7 @@ >>> * @param off the start offset in the data. >>> * @param len the number of bytes to write. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(byte b[], int off, int len) throws >>> IOException { >>> obuffer = cipher.update(b, off, len); >>> @@ -174,7 +174,7 @@ >>> * the cipher's block size, no bytes will be written out. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void flush() throws IOException { >>> if (obuffer != null) { >>> @@ -198,7 +198,7 @@ >>> * stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void close() throws IOException { >>> if (closed) { >>> diff --git a/src/share/classes/javax/naming/InitialContext.java >>> b/src/share/classes/javax/naming/InitialContext.java >>> --- a/src/share/classes/javax/naming/InitialContext.java >>> +++ b/src/share/classes/javax/naming/InitialContext.java >>> @@ -125,7 +125,7 @@ >>> * @see Context >>> * @see NamingManager#setInitialContextFactoryBuilder >>> * NamingManager.setInitialContextFactoryBuilder >>> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 >>> + * @since 1.3, JNDI 1.1 >>> */ >>> >>> public class InitialContext implements Context { >>> From bradford.wetmore at oracle.com Mon Jun 23 21:24:21 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 23 Jun 2014 14:24:21 -0700 Subject: RFR: 8047721: @since should have JDK version In-Reply-To: <53A892FB.8060507@oracle.com> References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com> <53A892FB.8060507@oracle.com> Message-ID: <53A89B05.4030509@oracle.com> JCE (Cipher) changes look good to me. Let me know if there's any problem with the point I mentioned in the other email. Brad On 6/23/2014 1:50 PM, Henry Jen wrote: > OK, I'll remove all @since JCE line, as the class already has @since 1.4 > as Joe pointed out earlier. > > Uodated webrev at > > http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/ > > Cheers, > Henry > > > On 06/23/2014 10:04 AM, Bradford Wetmore wrote: >> I would prefer that JCE1.2 be pulled out completely in the Cipher* >> classes. I will be sending you a separate note about JCE logistics. >> >> Thanks for doing this cleanup. >> >> Brad >> >> >> On 6/20/2014 11:46 AM, Henry Jen wrote: >>> Hi, >>> >>> Please review a trivial webrev to add JDK version to @since in a format >>> as Mark suggested[1]. >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/ >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html >>> >>> Appened is the diff as in the webrev. >>> >>> Cheers, >>> Henry >>> >>> >>> diff --git a/src/share/classes/java/lang/Package.java >>> b/src/share/classes/java/lang/Package.java >>> --- a/src/share/classes/java/lang/Package.java >>> +++ b/src/share/classes/java/lang/Package.java >>> @@ -107,6 +107,7 @@ >>> * loader to be found. >>> * >>> * @see ClassLoader#definePackage >>> + * @since 1.2 >>> */ >>> public class Package implements java.lang.reflect.AnnotatedElement { >>> /** >>> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java >>> b/src/share/classes/javax/crypto/CipherInputStream.java >>> --- a/src/share/classes/javax/crypto/CipherInputStream.java >>> +++ b/src/share/classes/javax/crypto/CipherInputStream.java >>> @@ -170,7 +170,7 @@ >>> * @return the next byte of data, or -1 if the end >>> of the >>> * stream is reached. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read() throws IOException { >>> if (ostart >= ofinish) { >>> @@ -196,7 +196,7 @@ >>> * the stream has been reached. >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.InputStream#read(byte[], int, int) >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read(byte b[]) throws IOException { >>> return read(b, 0, b.length); >>> @@ -217,7 +217,7 @@ >>> * the stream has been reached. >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.InputStream#read() >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read(byte b[], int off, int len) throws IOException { >>> if (ostart >= ofinish) { >>> @@ -254,7 +254,7 @@ >>> * @param n the number of bytes to be skipped. >>> * @return the actual number of bytes skipped. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public long skip(long n) throws IOException { >>> int available = ofinish - ostart; >>> @@ -277,7 +277,7 @@ >>> * @return the number of bytes that can be read from this >>> input stream >>> * without blocking. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int available() throws IOException { >>> return (ofinish - ostart); >>> @@ -292,7 +292,7 @@ >>> * stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void close() throws IOException { >>> if (closed) { >>> @@ -321,7 +321,7 @@ >>> * mark and reset methods. >>> * @see java.io.InputStream#mark(int) >>> * @see java.io.InputStream#reset() >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public boolean markSupported() { >>> return false; >>> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java >>> b/src/share/classes/javax/crypto/CipherOutputStream.java >>> --- a/src/share/classes/javax/crypto/CipherOutputStream.java >>> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java >>> @@ -114,7 +114,7 @@ >>> * >>> * @param b the byte. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(int b) throws IOException { >>> ibuffer[0] = (byte) b; >>> @@ -138,7 +138,7 @@ >>> * @exception NullPointerException if b is null. >>> * @exception IOException if an I/O error occurs. >>> * @see javax.crypto.CipherOutputStream#write(byte[], int, >>> int) >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(byte b[]) throws IOException { >>> write(b, 0, b.length); >>> @@ -152,7 +152,7 @@ >>> * @param off the start offset in the data. >>> * @param len the number of bytes to write. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(byte b[], int off, int len) throws IOException { >>> obuffer = cipher.update(b, off, len); >>> @@ -174,7 +174,7 @@ >>> * the cipher's block size, no bytes will be written out. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void flush() throws IOException { >>> if (obuffer != null) { >>> @@ -198,7 +198,7 @@ >>> * stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void close() throws IOException { >>> if (closed) { >>> diff --git a/src/share/classes/javax/naming/InitialContext.java >>> b/src/share/classes/javax/naming/InitialContext.java >>> --- a/src/share/classes/javax/naming/InitialContext.java >>> +++ b/src/share/classes/javax/naming/InitialContext.java >>> @@ -125,7 +125,7 @@ >>> * @see Context >>> * @see NamingManager#setInitialContextFactoryBuilder >>> * NamingManager.setInitialContextFactoryBuilder >>> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 >>> + * @since 1.3, JNDI 1.1 >>> */ >>> >>> public class InitialContext implements Context { >>> From bradford.wetmore at oracle.com Mon Jun 23 22:44:58 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 23 Jun 2014 15:44:58 -0700 Subject: RFR: 8047721: @since should have JDK version In-Reply-To: References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com> <53A892FB.8060507@oracle.com> Message-ID: <53A8ADEA.7030904@oracle.com> Except for these two classes, none of the JCE APIs ever contained @since until the JCE was put into JDK 1.4 back in 2002. The unbundled JCE hasn't been shipped in probably almost a decade. None of the unbundled JSSE/JGSS should have them either. Carrying around this old information is just cruft, IMO. Brad On 6/23/2014 2:28 PM, Paul Benedict wrote: > What's the rationale for removing the secondary version? Or I guess the > question should really be: when are secondary versions useful? At least > in the EE specs, the EE version plus the spec version are listed in many > places like this. > > > Cheers, > Paul > > > On Mon, Jun 23, 2014 at 3:50 PM, Henry Jen > wrote: > > OK, I'll remove all @since JCE line, as the class already has @since > 1.4 as Joe pointed out earlier. > > Uodated webrev at > > http://cr.openjdk.java.net/~__henryjen/jdk9/8047721/2/__webrev/ > > > Cheers, > Henry > > > > On 06/23/2014 10:04 AM, Bradford Wetmore wrote: > > I would prefer that JCE1.2 be pulled out completely in the Cipher* > classes. I will be sending you a separate note about JCE logistics. > > Thanks for doing this cleanup. > > Brad > > > On 6/20/2014 11:46 AM, Henry Jen wrote: > > Hi, > > Please review a trivial webrev to add JDK version to @since > in a format > as Mark suggested[1]. > > http://cr.openjdk.java.net/~__henryjen/jdk9/8047721/0/__webrev/ > > > [1] > http://mail.openjdk.java.net/__pipermail/jdk9-dev/2014-June/__000806.html > > > Appened is the diff as in the webrev. > > Cheers, > Henry > > > diff --git a/src/share/classes/java/lang/__Package.java > b/src/share/classes/java/lang/__Package.java > --- a/src/share/classes/java/lang/__Package.java > +++ b/src/share/classes/java/lang/__Package.java > @@ -107,6 +107,7 @@ > * loader to be found. > * > * @see ClassLoader#definePackage > + * @since 1.2 > */ > public class Package implements > java.lang.reflect.__AnnotatedElement { > /** > diff --git > a/src/share/classes/javax/__crypto/CipherInputStream.java > b/src/share/classes/javax/__crypto/CipherInputStream.java > --- a/src/share/classes/javax/__crypto/CipherInputStream.java > +++ b/src/share/classes/javax/__crypto/CipherInputStream.java > @@ -170,7 +170,7 @@ > * @return the next byte of data, or -1 > if the end > of the > * stream is reached. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int read() throws IOException { > if (ostart >= ofinish) { > @@ -196,7 +196,7 @@ > * the stream has been reached. > * @exception IOException if an I/O error occurs. > * @see java.io.InputStream#read(byte[__], > int, int) > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int read(byte b[]) throws IOException { > return read(b, 0, b.length); > @@ -217,7 +217,7 @@ > * the stream has been reached. > * @exception IOException if an I/O error occurs. > * @see java.io.InputStream#read() > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int read(byte b[], int off, int len) throws > IOException { > if (ostart >= ofinish) { > @@ -254,7 +254,7 @@ > * @param n the number of bytes to be skipped. > * @return the actual number of bytes skipped. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public long skip(long n) throws IOException { > int available = ofinish - ostart; > @@ -277,7 +277,7 @@ > * @return the number of bytes that can be read > from this > input stream > * without blocking. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public int available() throws IOException { > return (ofinish - ostart); > @@ -292,7 +292,7 @@ > * stream. > * > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void close() throws IOException { > if (closed) { > @@ -321,7 +321,7 @@ > * mark and reset > methods. > * @see java.io.InputStream#mark(int) > * @see java.io.InputStream#reset() > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public boolean markSupported() { > return false; > diff --git > a/src/share/classes/javax/__crypto/CipherOutputStream.java > b/src/share/classes/javax/__crypto/CipherOutputStream.java > --- a/src/share/classes/javax/__crypto/CipherOutputStream.java > +++ b/src/share/classes/javax/__crypto/CipherOutputStream.java > @@ -114,7 +114,7 @@ > * > * @param b the byte. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void write(int b) throws IOException { > ibuffer[0] = (byte) b; > @@ -138,7 +138,7 @@ > * @exception NullPointerException if b > is null. > * @exception IOException if an I/O error occurs. > * @see > javax.crypto.__CipherOutputStream#write(byte[__], int, > int) > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void write(byte b[]) throws IOException { > write(b, 0, b.length); > @@ -152,7 +152,7 @@ > * @param off the start offset in the data. > * @param len the number of bytes to write. > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void write(byte b[], int off, int len) throws > IOException { > obuffer = cipher.update(b, off, len); > @@ -174,7 +174,7 @@ > * the cipher's block size, no bytes will be written out. > * > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void flush() throws IOException { > if (obuffer != null) { > @@ -198,7 +198,7 @@ > * stream. > * > * @exception IOException if an I/O error occurs. > - * @since JCE1.2 > + * @since 1.4, JCE1.2 > */ > public void close() throws IOException { > if (closed) { > diff --git > a/src/share/classes/javax/__naming/InitialContext.java > b/src/share/classes/javax/__naming/InitialContext.java > --- a/src/share/classes/javax/__naming/InitialContext.java > +++ b/src/share/classes/javax/__naming/InitialContext.java > @@ -125,7 +125,7 @@ > * @see Context > * @see NamingManager#__setInitialContextFactoryBuilde__r > * NamingManager.__setInitialContextFactoryBuilde__r > - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 > + * @since 1.3, JNDI 1.1 > */ > > public class InitialContext implements Context { > > From weijun.wang at oracle.com Tue Jun 24 08:17:39 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 24 Jun 2014 16:17:39 +0800 Subject: RFR 8014870: Faster KDC availability check in Kerberos Message-ID: <17D2CB8C-001B-4929-8BD8-956ADF1E97DE@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8014870/webrev.00/ In Kerberos, when trying to request for a ticket, we tried multiple KDC servers for multiple times. Before this fix, we connect to a server, wait for 30 seconds (the default kdc_timeout). If there is no answer, go to the next KDC, wait for another 30 seconds, and so on. If none of the KDCs replies. We do more rounds (max_retries, default 3) of connections, and fail at last. Altogether with 3 KDCs we will wait at most 3*30*3=270 seconds. After this fix, connections are non-blocking and made every second, so they can wait at the same time. The kdc_timeout default is also reduced to 10 seconds (the same as other vendors). At the worst case, we will wait 3*3+10=19 seconds. You might say that changing kdc_timeout to 10 seconds matters a lot here but actually the wait-together style is much more helpful. Suppose only the 3rd KDC is alive, the old code needs to wait for 60 seconds to be able to connect to it, while the new one only needs to wait for 2 seconds, and this has nothing to do with kdc_timeout. Because of this, I've thrown away the old krb5.kdc.bad.policy security property. It's now not worth remembering which KDC is alive and which is not. All changes are inside the KdcComm.java file. Others are test and removal of useless things. I've included net-dev@ because these are all NIO calls, which I was no familiar with. Thanks Max From martinrb at google.com Tue Jun 24 15:40:18 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 Jun 2014 08:40:18 -0700 Subject: [concurrency-interest] Deadlock In-Reply-To: <53A9897A.7010803@gmail.com> References: <53A98733.4060401@gmail.com> <53A9897A.7010803@gmail.com> Message-ID: [+openjdk mailing lists] Yeah, I'm trying to excise all the networking code from TLR and SplittableRandom. There is also likely to be a missing wrapping in doPrivileged. On Tue, Jun 24, 2014 at 7:21 AM, Peter Levart wrote: > On 06/24/2014 04:12 PM, Peter Levart wrote: > >> On 06/24/2014 01:09 PM, David Holmes wrote: >> >>> Hi Peter, >>> >>> What a strange coincidence - the fact that the initialization of >>> ThreadLocalRandom can lead to arbitrary code execution has just been a >>> topic >>> of discussion, and it looks like your deadlock is related to that. >>> >> >> Uf, this time it's a combination of a custom SecurityManager being in >> effect when NetworkInterface.getHardwareAddress() is called. It looks >> like we should not use any networking code at all for TLR's initialization. >> > > Or make NetworkInterface.getHardwareAddress() a @CallerSensitive method > and avoid SecurityManager invocation when called from one of system > classes. That's still an alternative. > > Peter > > > >> Regards, Peter >> >> >>> David Holmes >>> >>> -----Original Message----- >>>> From: concurrency-interest-bounces at cs.oswego.edu >>>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter >>>> Firmstone >>>> Sent: Tuesday, 24 June 2014 8:25 PM >>>> To: concurrency-interest at cs.oswego.edu >>>> Subject: [concurrency-interest] Deadlock >>>> >>>> >>>> This appears to be a ClassLoader deadlock in Java 7. >>>> >>>> The stack trace from the main thread is missing. >>>> >>>> Any ideas? >>>> >>>> Regards, >>>> >>>> Peter. >>>> >>>> Attaching to process ID 7124, please wait... >>>> Debugger attached successfully. >>>> Client compiler detected. >>>> JVM version is 25.0-b70 >>>> Deadlock Detection: >>>> >>>> Found one Java-level deadlock: >>>> ============================= >>>> >>>> "main": >>>> waiting to lock Monitor at 0x0094bb2c (Object at 0x03d73c38, a >>>> java/lang/Object), >>>> which is held by "Thread-1" >>>> "Thread-1": >>>> waiting to lock Monitor at 0x0094c99c (Object at 0x03f02e50, a [I), >>>> which is held by "main" >>>> >>>> Found a total of 1 deadlock. >>>> >>>> Thread 8: (state = BLOCKED) >>>> - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229, >>>> line=60 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=37, line=128 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=4, line=44 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, >>>> boolean, boolean) @bci=7, line=248 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) @bci=8, line=67 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) @bci=161, line=260 (Interpreted frame) >>>> - >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTr >>>> ustPermission(java.lang.Class) >>>> @bci=59, line=1848 (Interpreted frame) >>>> - >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBea >>>> n(java.lang.Object, >>>> javax.management.ObjectName) @bci=25, line=322 (Interpreted frame) >>>> - com.sun.jmx.mbeanserver.JmxMBeanServer$2.run() @bci=17, line=1225 >>>> (Interpreted frame) >>>> - >>>> java.security.AccessController.doPrivileged(java.security.Privileg >>>> edExceptionAction) >>>> @bci=0 (Interpreted frame) >>>> - com.sun.jmx.mbeanserver.JmxMBeanServer.initialize() @bci=25, >>>> line=1223 (Interpreted frame) >>>> - com.sun.jmx.mbeanserver.JmxMBeanServer.(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> com.sun.jmx.mbeanserver.MBeanInstantiator, boolean, boolean) @bci=133, >>>> line=255 (Interpreted frame) >>>> - >>>> com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> boolean) @bci=13, line=1437 (Interpreted frame) >>>> - javax.management.MBeanServerBuilder.newMBeanServer(java.lang. >>>> String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate) >>>> @bci=4, line=110 (Interpreted frame) >>>> - javax.management.MBeanServerFactory.newMBeanServer(java.lang. >>>> String) >>>> @bci=36, line=329 (Interpreted frame) >>>> - >>>> javax.management.MBeanServerFactory.createMBeanServer(java.lang.String) >>>> @bci=6, line=231 (Interpreted frame) >>>> - javax.management.MBeanServerFactory.createMBeanServer() @bci=1, >>>> line=192 (Interpreted frame) >>>> - java.lang.management.ManagementFactory.getPlatformMBeanServer() >>>> @bci=29, line=468 (Interpreted frame) >>>> - >>>> sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer() >>>> @bci=66, line=518 (Interpreted frame) >>>> - sun.management.Agent.startLocalManagementAgent() @bci=13, line=138 >>>> (Interpreted frame) >>>> - sun.management.Agent.startAgent(java.util.Properties) @bci=76, >>>> line=260 (Interpreted frame) >>>> - sun.management.Agent.agentmain(java.lang.String) @bci=45, line=128 >>>> (Interpreted frame) >>>> - >>>> sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >>>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >>>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >>>> - java.lang.reflect.Method.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=56, line=483 (Interpreted frame) >>>> - >>>> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(java.lan >>>> g.String, >>>> java.lang.String, java.lang.String) @bci=192, line=388 (Interpreted >>>> frame) >>>> - >>>> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(java. >>>> lang.String, >>>> java.lang.String) @bci=5, line=411 (Interpreted frame) >>>> >>>> >>>> Thread 7: (state = BLOCKED) >>>> >>>> >>>> Thread 5: (state = BLOCKED) >>>> - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229, >>>> line=60 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=37, line=128 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=4, line=44 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, >>>> boolean, boolean) @bci=7, line=248 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) @bci=8, line=67 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) @bci=161, line=260 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission) >>>> @bci=27, line=202 (Interpreted frame) >>>> - java.net.NetworkInterface.getHardwareAddress() @bci=18, line=447 >>>> (Interpreted frame) >>>> - java.util.concurrent.ThreadLocalRandom.initialSeed() @bci=116, >>>> line=158 (Interpreted frame) >>>> - java.util.concurrent.ThreadLocalRandom.() @bci=14, >>>> line=137 >>>> (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.fullAddCount(long, boolean) >>>> @bci=0, line=2526 (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.addCount(long, int) >>>> @bci=104, >>>> line=2266 (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.putVal(java.lang.Object, >>>> java.lang.Object, boolean) @bci=357, line=1070 (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.putIfAbsent( >>>> java.lang.Object, >>>> java.lang.Object) @bci=4, line=1535 (Interpreted frame) >>>> - java.lang.ClassLoader.getClassLoadingLock(java.lang.String) >>>> @bci=23, >>>> line=463 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String, boolean) @bci=2, >>>> line=404 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String, boolean) >>>> @bci=38, >>>> line=411 (Interpreted frame) >>>> - sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, >>>> boolean) @bci=36, line=308 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String) @bci=3, line=357 >>>> (Interpreted frame) >>>> - >>>> org.cliffc.high_scale_lib.NonBlockingHashMap$SnapshotK.(org. >>>> >>> cliffc.high_scale_lib.NonBlockingHashMap) >>> >>>> @bci=10, line=1167 (Interpreted frame) >>>> - org.cliffc.high_scale_lib.NonBlockingHashMap$2.iterator() @bci=8, >>>> line=1200 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run() >>>> @bci=15, line=166 (Interpreted frame) >>>> - java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, >>>> line=511 (Interpreted frame) >>>> - java.util.concurrent.FutureTask.runAndReset() @bci=47, line=308 >>>> (Interpreted frame) >>>> - >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$Sch >>>> eduledFutureTask) >>>> @bci=1, line=180 (Interpreted frame) >>>> - >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.run() >>>> @bci=37, line=294 (Interpreted frame) >>>> - >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concur >>>> rent.ThreadPoolExecutor$Worker) >>>> @bci=95, line=1142 (Interpreted frame) >>>> - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, >>>> line=617 (Interpreted frame) >>>> - java.lang.Thread.run() @bci=11, line=744 (Interpreted frame) >>>> >>>> >>>> Thread 4: (state = BLOCKED) >>>> - java.lang.Object.wait(long) @bci=0 (Interpreted frame) >>>> - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=142 >>>> (Interpreted frame) >>>> - java.lang.ref.ReferenceQueue.remove() @bci=2, line=158 >>>> (Interpreted >>>> frame) >>>> - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 >>>> (Interpreted frame) >>>> >>>> >>>> Thread 3: (state = BLOCKED) >>>> - java.lang.Object.wait(long) @bci=0 (Interpreted frame) >>>> - java.lang.Object.wait() @bci=2, line=502 (Interpreted frame) >>>> - java.lang.ref.Reference$ReferenceHandler.run() @bci=36, line=157 >>>> (Interpreted frame) >>>> >>>> >>>> Thread 1: (state = BLOCKED) >>>> - java.lang.ClassLoader.loadClass(java.lang.String, boolean) @bci=8, >>>> line=406 (Interpreted frame) >>>> - sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, >>>> boolean) @bci=36, line=308 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String) @bci=3, line=357 >>>> (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229, >>>> line=60 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=37, line=128 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=4, line=44 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, >>>> boolean, boolean) @bci=7, line=248 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) @bci=8, line=67 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) @bci=161, line=260 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission) >>>> @bci=27, line=202 (Interpreted frame) >>>> - java.lang.System.checkIO() @bci=18, line=253 (Interpreted frame) >>>> - java.lang.System.setErr(java.io.PrintStream) @bci=0, line=199 >>>> (Interpreted frame) >>>> - com.sun.jini.qa.harness.MasterTest.main(java.lang.String[]) >>>> @bci=9, >>>> line=84 (Interpreted frame) >>>> >>>> The long version: >>>> >>>> Attaching to process ID 7124, please wait... >>>> Debugger attached successfully. >>>> Client compiler detected. >>>> JVM version is 25.0-b70 >>>> Deadlock Detection: >>>> >>>> Found one Java-level deadlock: >>>> ============================= >>>> >>>> "main": >>>> waiting to lock Monitor at 0x0094bb2c (Object at 0x03d73c38, a >>>> java/lang/Object), >>>> which is held by "Thread-1" >>>> "Thread-1": >>>> waiting to lock Monitor at 0x0094c99c (Object at 0x03f02e50, a [I), >>>> which is held by "main" >>>> >>>> Found a total of 1 deadlock. >>>> >>>> ----------------- 0 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x00e64d7b java + 0x4d7b >>>> 0x00e631ca java + 0x31ca >>>> 0x00e642ab java + 0x42ab >>>> 0x00e63440 java + 0x3440 >>>> 0x00130138 ???????? >>>> ----------------- 1 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal at 4 + 0x286d >>>> 0x5bf7857e jvm!JVM_GetThreadStateNames + 0x4c12e >>>> 0x5bf78b23 jvm!JVM_GetThreadStateNames + 0x4c6d3 >>>> 0x5bf8e107 jvm!JVM_GetThreadStateNames + 0x61cb7 >>>> 0x5bf8e6be jvm!JVM_GetThreadStateNames + 0x6226e >>>> 0x5bea1b28 jvm + 0x71b28 >>>> 0x01aa1cef * java.lang.ClassLoader.loadClass(java.lang.String, >>>> boolean) bci:8 line:406 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, boolean) >>>> bci:36 line:308 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String) bci:3 >>>> line:357 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf7258f jvm!JVM_GetThreadStateNames + 0x4613f >>>> 0x5be77d6f jvm + 0x47d6f >>>> 0x5be7822a jvm + 0x4822a >>>> 0x5be794c0 jvm + 0x494c0 >>>> 0x5be7950a jvm + 0x4950a >>>> 0x5bf20de5 jvm!_JVM_FindClassFromClass at 16 + 0x135 >>>> 0x73b515cd verify + 0x15cd >>>> 0x73b51d53 verify + 0x1d53 >>>> 0x73b52c67 verify + 0x2c67 >>>> 0x14d6f5e8 ???????? >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 2 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal at 4 + 0x286d >>>> 0x5bf73ecc jvm!JVM_GetThreadStateNames + 0x47a7c >>>> 0x5bf741fc jvm!JVM_GetThreadStateNames + 0x47dac >>>> 0x5bf99671 jvm!JVM_GetThreadStateNames + 0x6d221 >>>> 0x5bf99a32 jvm!JVM_GetThreadStateNames + 0x6d5e2 >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> ----------------- 3 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal at 4 + 0x2979 >>>> 0x5bf78f56 jvm!JVM_GetThreadStateNames + 0x4cb06 >>>> 0x5bf8e334 jvm!JVM_GetThreadStateNames + 0x61ee4 >>>> 0x5bf20c15 jvm!_JVM_MonitorWait at 16 + 0x95 >>>> 0x01a9ac63 * java.lang.Object.wait(long) bci:0 (Interpreted frame) >>>> 0x01a940f4 * java.lang.Object.wait() bci:2 line:502 (Interpreted >>>> frame) >>>> 0x01a940f4 * java.lang.ref.Reference$ReferenceHandler.run() bci:36 >>>> line:157 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf72517 jvm!JVM_GetThreadStateNames + 0x460c7 >>>> 0x5bf1de0f jvm!jio_printf + 0x9f >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 4 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal at 4 + 0x2979 >>>> 0x5bf78f56 jvm!JVM_GetThreadStateNames + 0x4cb06 >>>> 0x5bf8e334 jvm!JVM_GetThreadStateNames + 0x61ee4 >>>> 0x5bf20c15 jvm!_JVM_MonitorWait at 16 + 0x95 >>>> 0x01a9ac63 * java.lang.Object.wait(long) bci:0 (Interpreted frame) >>>> 0x01a940f4 * java.lang.ref.ReferenceQueue.remove(long) bci:44 >>>> line:142 (Interpreted frame) >>>> 0x01a94054 * java.lang.ref.ReferenceQueue.remove() bci:2 line:158 >>>> (Interpreted frame) >>>> 0x01a94054 * java.lang.ref.Finalizer$FinalizerThread.run() bci:36 >>>> line:209 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf72517 jvm!JVM_GetThreadStateNames + 0x460c7 >>>> 0x5bf1de0f jvm!jio_printf + 0x9f >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 5 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal at 4 + 0x286d >>>> 0x5bf7857e jvm!JVM_GetThreadStateNames + 0x4c12e >>>> 0x5bf78b23 jvm!JVM_GetThreadStateNames + 0x4c6d3 >>>> 0x5bf8e107 jvm!JVM_GetThreadStateNames + 0x61cb7 >>>> 0x5bf8e6be jvm!JVM_GetThreadStateNames + 0x6226e >>>> 0x5bf8e78f jvm!JVM_GetThreadStateNames + 0x6233f >>>> 0x5bee0d10 jvm + 0xb0d10 >>>> 0x5bee2854 jvm + 0xb2854 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea5641 jvm + 0x75641 >>>> 0x01aa17be * >>>> au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) bci:229 >>>> line:60 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:37 line:128 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:4 line:44 (Interpreted frame) >>>> 0x01a94089 * >>>> au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, boolean, >>>> boolean) bci:7 line:248 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) bci:8 line:67 (Interpreted frame) >>>> 0x01a94089 * >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) bci:161 line:260 (Interpreted frame) >>>> 0x01a940f4 * >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission) >>>> bci:27 line:202 (Interpreted frame) >>>> 0x01a940f4 * java.net.NetworkInterface.getHardwareAddress() bci:18 >>>> line:447 (Interpreted frame) >>>> 0x01a94054 * java.util.concurrent.ThreadLocalRandom.initialSeed() >>>> bci:116 line:158 (Interpreted frame) >>>> 0x01a93e20 * java.util.concurrent.ThreadLocalRandom.() >>>> bci:14 >>>> line:137 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bee0f44 jvm + 0xb0f44 >>>> 0x5bee2b21 jvm + 0xb2b21 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea9796 jvm + 0x79796 >>>> 0x5beaa7b2 jvm + 0x7a7b2 >>>> 0x5bea5dc7 jvm + 0x75dc7 >>>> 0x01aa12ae * >>>> java.util.concurrent.ConcurrentHashMap.fullAddCount(long, boolean) >>>> bci:0 >>>> line:2526 (Interpreted frame) >>>> 0x01a940f4 * java.util.concurrent.ConcurrentHashMap.addCount(long, >>>> int) bci:104 line:2266 (Interpreted frame) >>>> 0x01a940f4 * >>>> java.util.concurrent.ConcurrentHashMap.putVal(java.lang.Object, >>>> java.lang.Object, boolean) bci:357 line:1070 (Interpreted frame) >>>> 0x01a94054 * >>>> java.util.concurrent.ConcurrentHashMap.putIfAbsent(java.lang.Object, >>>> java.lang.Object) bci:4 line:1535 (Interpreted frame) >>>> 0x01a94054 * >>>> java.lang.ClassLoader.getClassLoadingLock(java.lang.String) bci:23 >>>> line:463 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String, >>>> boolean) bci:2 line:404 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String, >>>> boolean) bci:38 line:411 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, boolean) >>>> bci:36 line:308 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String) bci:3 >>>> line:357 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf7258f jvm!JVM_GetThreadStateNames + 0x4613f >>>> 0x5be77d6f jvm + 0x47d6f >>>> 0x5be7822a jvm + 0x4822a >>>> 0x5be794c0 jvm + 0x494c0 >>>> 0x5be7950a jvm + 0x4950a >>>> 0x5be79f66 jvm + 0x49f66 >>>> 0x5be715c7 jvm + 0x415c7 >>>> 0x5be7a53c jvm + 0x4a53c >>>> 0x5be817e2 jvm + 0x517e2 >>>> 0x5be822d9 jvm + 0x522d9 >>>> 0x5be82414 jvm + 0x52414 >>>> 0x5bed85dd jvm + 0xa85dd >>>> 0x5bee0d80 jvm + 0xb0d80 >>>> 0x5bee2854 jvm + 0xb2854 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea5641 jvm + 0x75641 >>>> 0x01aa17be * >>>> org.cliffc.high_scale_lib.NonBlockingHashMap$SnapshotK.(org. >>>> >>> cliffc.high_scale_lib.NonBlockingHashMap) >>> >>>> bci:10 line:1167 (Interpreted frame) >>>> 0x01a940f4 * >>>> org.cliffc.high_scale_lib.NonBlockingHashMap$2.iterator() bci:8 >>>> line:1200 (Interpreted frame) >>>> 0x01a94089 * >>>> au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run() bci:15 >>>> line:166 (Interpreted frame) >>>> 0x01a94129 * java.util.concurrent.Executors$RunnableAdapter.call() >>>> bci:4 line:511 (Interpreted frame) >>>> 0x01a94089 * java.util.concurrent.FutureTask.runAndReset() bci:47 >>>> line:308 (Interpreted frame) >>>> 0x01a93ba0 * >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$Sch >>>> eduledFutureTask) >>>> bci:1 line:180 (Interpreted frame) >>>> 0x01a93ba0 * >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.run() >>>> bci:37 line:294 (Interpreted frame) >>>> 0x01a94129 * >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concur >>>> rent.ThreadPoolExecutor$Worker) >>>> bci:95 line:1142 (Interpreted frame) >>>> 0x01a940f4 * java.util.concurrent.ThreadPoolExecutor$Worker.run() >>>> bci:5 line:617 (Interpreted frame) >>>> 0x01a94129 * java.lang.Thread.run() bci:11 line:744 (Interpreted >>>> frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf72517 jvm!JVM_GetThreadStateNames + 0x460c7 >>>> 0x5bf1de0f jvm!jio_printf + 0x9f >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - <0x03d58650>, (a java/util/concurrent/ >>>> ThreadPoolExecutor$Worker) >>>> ----------------- 6 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> ----------------- 7 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd9539 jvm!_JVM_FindSignal at 4 + 0x5269 >>>> 0x5bfd9607 jvm!_JVM_FindSignal at 4 + 0x5337 >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 8 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal at 4 + 0x2979 >>>> 0x5bf7856b jvm!JVM_GetThreadStateNames + 0x4c11b >>>> 0x5bf78b23 jvm!JVM_GetThreadStateNames + 0x4c6d3 >>>> 0x5bf8e107 jvm!JVM_GetThreadStateNames + 0x61cb7 >>>> 0x5bf8e6be jvm!JVM_GetThreadStateNames + 0x6226e >>>> 0x5bf8e78f jvm!JVM_GetThreadStateNames + 0x6233f >>>> 0x5bee0d10 jvm + 0xb0d10 >>>> 0x5bee2854 jvm + 0xb2854 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea5641 jvm + 0x75641 >>>> 0x01aa17be * >>>> au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) bci:229 >>>> line:60 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:37 line:128 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:4 line:44 (Interpreted frame) >>>> 0x01a94089 * >>>> au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, boolean, >>>> boolean) bci:7 line:248 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) bci:8 line:67 (Interpreted frame) >>>> 0x01a94089 * >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) bci:161 line:260 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTr >>>> ustPermission(java.lang.Class) >>>> bci:59 line:1848 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBea >>>> n(java.lang.Object, >>>> javax.management.ObjectName) bci:25 line:322 (Interpreted frame) >>>> 0x01a94089 * com.sun.jmx.mbeanserver.JmxMBeanServer$2.run() bci:17 >>>> line:1225 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf299ed jvm!_JVM_DoPrivileged at 20 + 0x2bd >>>> 0x73b21047 >>>> java_73b20000!_Java_java_security_AccessController_doPrivileged__L >>>> java_security_PrivilegedExceptionAction_2 at 12 >>>> + 0x15 >>>> 0x01a94054 * com.sun.jmx.mbeanserver.JmxMBeanServer.initialize() >>>> bci:25 line:1223 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.mbeanserver.JmxMBeanServer.(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> com.sun.jmx.mbeanserver.MBeanInstantiator, boolean, boolean) bci:133 >>>> line:255 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> boolean) bci:13 line:1437 (Interpreted frame) >>>> 0x01a94054 * >>>> javax.management.MBeanServerBuilder.newMBeanServer(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate) >>>> bci:4 line:110 (Interpreted frame) >>>> 0x01a94054 * >>>> javax.management.MBeanServerFactory.newMBeanServer(java.lang.String) >>>> bci:36 line:329 (Interpreted frame) >>>> 0x01a94054 * >>>> javax.management.MBeanServerFactory.createMBeanServer(java.lang.String) >>>> bci:6 line:231 (Interpreted frame) >>>> 0x01a94054 * javax.management.MBeanServerFactory.createMBeanServer() >>>> bci:1 line:192 (Interpreted frame) >>>> 0x01a94054 * >>>> java.lang.management.ManagementFactory.getPlatformMBeanServer() bci:29 >>>> line:468 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer() >>>> bci:66 line:518 (Interpreted frame) >>>> 0x01a94054 * sun.management.Agent.startLocalManagementAgent() bci:13 >>>> line:138 (Interpreted frame) >>>> 0x01a940f4 * sun.management.Agent.startAgent(java.util.Properties) >>>> bci:76 line:260 (Interpreted frame) >>>> 0x01a940f4 * sun.management.Agent.agentmain(java.lang.String) bci:45 >>>> line:128 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf7e73a jvm!JVM_GetThreadStateNames + 0x522ea >>>> 0x5bf7e993 jvm!JVM_GetThreadStateNames + 0x52543 >>>> 0x5bf22b03 jvm!_JVM_InvokeMethod at 16 + 0xb3 >>>> 0x73b23a6e >>>> java_73b20000!_Java_sun_reflect_NativeMethodAccessorImpl_invoke0 at 20 + >>>> 0x15 >>>> 0x01a94054 * >>>> sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) bci:100 line:62 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) bci:6 line:43 (Interpreted frame) >>>> 0x01a94089 * java.lang.reflect.Method.invoke(java.lang.Object, >>>> java.lang.Object[]) bci:56 line:483 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(java.lan >>>> g.String, >>>> java.lang.String, java.lang.String) bci:192 line:388 (Interpreted frame) >>>> 0x01a940f4 * >>>> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(java. >>>> lang.String, >>>> java.lang.String) bci:5 line:411 (Interpreted frame) >>>> 0x01a903d7 >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal at 4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5befe951 jvm!JNI_GetCreatedJavaVMs + 0x71a1 >>>> 0x5bf01788 jvm!JNI_GetCreatedJavaVMs + 0x9fd8 >>>> 0x6db62878 instrument!Agent_OnAttach + 0x76b >>>> 0x6db63eea instrument!Agent_OnAttach + 0x1ddd >>>> 0x6db6234a instrument!Agent_OnAttach + 0x23d >>>> 0x5bf3c50c jvm!JVM_GetThreadStateNames + 0x100bc >>>> 0x5bf9b05e jvm!JVM_GetThreadStateNames + 0x6ec0e >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 9 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal at 4 + 0x286d >>>> 0x5bf73ecc jvm!JVM_GetThreadStateNames + 0x47a7c >>>> 0x5bf7424a jvm!JVM_GetThreadStateNames + 0x47dfa >>>> 0x5be9253b jvm + 0x6253b >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 10 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal at 4 + 0x2979 >>>> 0x5bf73ec1 jvm!JVM_GetThreadStateNames + 0x47a71 >>>> 0x5bf741fc jvm!JVM_GetThreadStateNames + 0x47dac >>>> 0x5bf829a5 jvm!JVM_GetThreadStateNames + 0x56555 >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 11 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal at 4 + 0x286d >>>> 0x5bf73ecc jvm!JVM_GetThreadStateNames + 0x47a7c >>>> 0x5bf741fc jvm!JVM_GetThreadStateNames + 0x47dac >>>> 0x5bf8f904 jvm!JVM_GetThreadStateNames + 0x634b4 >>>> 0x5bf8f9a7 jvm!JVM_GetThreadStateNames + 0x63557 >>>> 0x5bfd9186 jvm!_JVM_FindSignal at 4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> >>>> >>>> _______________________________________________ >>>> Concurrency-interest mailing list >>>> Concurrency-interest at cs.oswego.edu >>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >>>> >>> _______________________________________________ >>> Concurrency-interest mailing list >>> Concurrency-interest at cs.oswego.edu >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >>> >> >> > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jun 24 15:51:35 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 24 Jun 2014 23:51:35 +0800 Subject: RFR: 8015081 In-Reply-To: <53A38A37.8090909@oracle.com> References: <539F31F3.2070700@oracle.com> <53A38A37.8090909@oracle.com> Message-ID: <53A99E87.1050707@oracle.com> 1. Why make the following update? removeAll() is a method of AbstractSet. private static class SecureSet - extends AbstractSet - implements java.io.Serializable { + implements Set, java.io.Serializable { 2. Per Java coding conversions, please always use braces even for single line conditional statement. For example: 1365 if (o == this) 1366 return true; -> if (o == this) { return true; } 3. The implementation of SecureSet.equals() may not follow the spec of equals() method. See item 8 of "Effective Java". 1368 if (!(o instanceof Set)) 1369 return false; -> 1368 if (!(o instanceof SecureSet)) 1369 return false; Or I think you can re-use the spec of AbstractSet.equals() if SecureSet extends AbstractSet. Otherwise, looks fine to me. Xuelei On 6/20/2014 9:11 AM, Jamil Nimeh wrote: > Hello all, > > This revision for the fix for 8015081 has the following test changes: > > Removal of the static byte buffers for serialized data in lieu of a more > dynamic approach. A stripped down version of Subject in its own package > is now being compiled alongside SubjectNullTests.java. This version of > Subject allows the creation and serialization of Subjects with null > elements in the principals SecureSet. Immediately following > serialization, this special Subject's class designation is overwritten > to be javax.security.auth.Subject. When deserialization occurs, the > correct (JDK 9) version of Subject will be used and null element checks > will take place. > > Thanks go to Weijun Wang for this testing approach. > > http://cr.openjdk.java.net/~weijun/8015081/webrev.07 > > --Jamil > From martinrb at google.com Tue Jun 24 16:01:53 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 Jun 2014 09:01:53 -0700 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53A98525.9080908@gmail.com> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> Message-ID: On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart wrote: > > I would rather use SecureRandom.generateSeed() instance method instead of > SecureRandom.nextBytes(). Why? Because every SecureRandom instance has to > initialize it's seed 1st before getBytes() can provide the next random > bytes from the PRNG. Since we only need the 1st 8 bytes from the > SecureRandom instance to initialize TLR's seeder, we might as well directly > call the SecureRandom.generateSeed() method. > If I strace this program on Linux using strace -ff -q java SecureRandoms: public class SecureRandoms { public static void main(String[] args) throws Throwable { byte[] bytes = new byte[8]; new java.security.SecureRandom().nextBytes(bytes); } } I see a read from /dev/urandom, but not from /dev/random, so I conclude your intuitive understanding of how the seeding works must be wrong. It makes sense that NativePRNG doesn't need to do any special seeding of its own, since it reuses the operating system's. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Jun 24 16:31:28 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 24 Jun 2014 09:31:28 -0700 Subject: RFR: 8015081 In-Reply-To: <53A99E87.1050707@oracle.com> References: <539F31F3.2070700@oracle.com> <53A38A37.8090909@oracle.com> <53A99E87.1050707@oracle.com> Message-ID: <53A9A7E0.3030901@oracle.com> Hi Xuelei, thanks for the comments! #1: Removal of SecureSet from AbstractSet's hierarchy was a request made by Sean earlier this month. One of his concerns was to insulate SecureSet from changes/new methods added to AbstractSet, where the superclass method wouldn't work well with the implementation of SecureSet. #2: No problem. I'll look for any other instances of this and change them. #3: I will change the run-time type check to look for SecureSet. --Jamil On 06/24/2014 08:51 AM, Xuelei Fan wrote: > 1. Why make the following update? removeAll() is a method of AbstractSet. > > private static class SecureSet > - extends AbstractSet > - implements java.io.Serializable { > + implements Set, java.io.Serializable { > > 2. Per Java coding conversions, please always use braces even for single > line conditional statement. For example: > 1365 if (o == this) > 1366 return true; > -> > if (o == this) { > return true; > } > > 3. The implementation of SecureSet.equals() may not follow the spec of > equals() method. See item 8 of "Effective Java". > > 1368 if (!(o instanceof Set)) > 1369 return false; > > -> > > 1368 if (!(o instanceof SecureSet)) > 1369 return false; > > Or I think you can re-use the spec of AbstractSet.equals() if SecureSet > extends AbstractSet. > > Otherwise, looks fine to me. > > Xuelei > > On 6/20/2014 9:11 AM, Jamil Nimeh wrote: >> Hello all, >> >> This revision for the fix for 8015081 has the following test changes: >> >> Removal of the static byte buffers for serialized data in lieu of a more >> dynamic approach. A stripped down version of Subject in its own package >> is now being compiled alongside SubjectNullTests.java. This version of >> Subject allows the creation and serialization of Subjects with null >> elements in the principals SecureSet. Immediately following >> serialization, this special Subject's class designation is overwritten >> to be javax.security.auth.Subject. When deserialization occurs, the >> correct (JDK 9) version of Subject will be used and null element checks >> will take place. >> >> Thanks go to Weijun Wang for this testing approach. >> >> http://cr.openjdk.java.net/~weijun/8015081/webrev.07 >> >> --Jamil >> From digulla at hepe.com Fri Jun 20 10:00:01 2014 From: digulla at hepe.com (Aaron Digulla) Date: Fri, 20 Jun 2014 12:00:01 +0200 Subject: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded In-Reply-To: <53A35AEC.9080708@oracle.com> Message-ID: <26b8-53a40600-d-41ced200@248413781> Am Donnerstag, 19. Juni 2014 23:49 CEST, Joe Darcy schrieb: > I'd prefer to see the CheckJarSigError.sh as a Java program. There original bug report contains a full self-contained test case in Java. Why was that split into several files? I'm also a bit uneasy about the "just show the file name". I have thousands of JARs with the same name on my harddisk (several Maven repos, target folders, you name it). If you strip the path from the error message, then I have to somehow figure out the classpath which was used. That might work when I run Java from the command line but when I use complex frameworks like OSGi or Maven which do all kinds of magic to determine which JARs they might want to load, then this doesn't help much. At least add a command line option / system property which allows to see the full path. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ From pbenedict at apache.org Mon Jun 23 21:28:47 2014 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 23 Jun 2014 16:28:47 -0500 Subject: RFR: 8047721: @since should have JDK version In-Reply-To: <53A892FB.8060507@oracle.com> References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com> <53A892FB.8060507@oracle.com> Message-ID: What's the rationale for removing the secondary version? Or I guess the question should really be: when are secondary versions useful? At least in the EE specs, the EE version plus the spec version are listed in many places like this. Cheers, Paul On Mon, Jun 23, 2014 at 3:50 PM, Henry Jen wrote: > OK, I'll remove all @since JCE line, as the class already has @since 1.4 > as Joe pointed out earlier. > > Uodated webrev at > > http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/ > > Cheers, > Henry > > > > On 06/23/2014 10:04 AM, Bradford Wetmore wrote: > >> I would prefer that JCE1.2 be pulled out completely in the Cipher* >> classes. I will be sending you a separate note about JCE logistics. >> >> Thanks for doing this cleanup. >> >> Brad >> >> >> On 6/20/2014 11:46 AM, Henry Jen wrote: >> >>> Hi, >>> >>> Please review a trivial webrev to add JDK version to @since in a format >>> as Mark suggested[1]. >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/ >>> >>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/ >>> 000806.html >>> >>> Appened is the diff as in the webrev. >>> >>> Cheers, >>> Henry >>> >>> >>> diff --git a/src/share/classes/java/lang/Package.java >>> b/src/share/classes/java/lang/Package.java >>> --- a/src/share/classes/java/lang/Package.java >>> +++ b/src/share/classes/java/lang/Package.java >>> @@ -107,6 +107,7 @@ >>> * loader to be found. >>> * >>> * @see ClassLoader#definePackage >>> + * @since 1.2 >>> */ >>> public class Package implements java.lang.reflect.AnnotatedElement { >>> /** >>> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java >>> b/src/share/classes/javax/crypto/CipherInputStream.java >>> --- a/src/share/classes/javax/crypto/CipherInputStream.java >>> +++ b/src/share/classes/javax/crypto/CipherInputStream.java >>> @@ -170,7 +170,7 @@ >>> * @return the next byte of data, or -1 if the end >>> of the >>> * stream is reached. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read() throws IOException { >>> if (ostart >= ofinish) { >>> @@ -196,7 +196,7 @@ >>> * the stream has been reached. >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.InputStream#read(byte[], int, int) >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read(byte b[]) throws IOException { >>> return read(b, 0, b.length); >>> @@ -217,7 +217,7 @@ >>> * the stream has been reached. >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.InputStream#read() >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int read(byte b[], int off, int len) throws IOException { >>> if (ostart >= ofinish) { >>> @@ -254,7 +254,7 @@ >>> * @param n the number of bytes to be skipped. >>> * @return the actual number of bytes skipped. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public long skip(long n) throws IOException { >>> int available = ofinish - ostart; >>> @@ -277,7 +277,7 @@ >>> * @return the number of bytes that can be read from this >>> input stream >>> * without blocking. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public int available() throws IOException { >>> return (ofinish - ostart); >>> @@ -292,7 +292,7 @@ >>> * stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void close() throws IOException { >>> if (closed) { >>> @@ -321,7 +321,7 @@ >>> * mark and reset methods. >>> * @see java.io.InputStream#mark(int) >>> * @see java.io.InputStream#reset() >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public boolean markSupported() { >>> return false; >>> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java >>> b/src/share/classes/javax/crypto/CipherOutputStream.java >>> --- a/src/share/classes/javax/crypto/CipherOutputStream.java >>> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java >>> @@ -114,7 +114,7 @@ >>> * >>> * @param b the byte. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(int b) throws IOException { >>> ibuffer[0] = (byte) b; >>> @@ -138,7 +138,7 @@ >>> * @exception NullPointerException if b is null. >>> * @exception IOException if an I/O error occurs. >>> * @see javax.crypto.CipherOutputStream#write(byte[], int, >>> int) >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(byte b[]) throws IOException { >>> write(b, 0, b.length); >>> @@ -152,7 +152,7 @@ >>> * @param off the start offset in the data. >>> * @param len the number of bytes to write. >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void write(byte b[], int off, int len) throws IOException { >>> obuffer = cipher.update(b, off, len); >>> @@ -174,7 +174,7 @@ >>> * the cipher's block size, no bytes will be written out. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void flush() throws IOException { >>> if (obuffer != null) { >>> @@ -198,7 +198,7 @@ >>> * stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> - * @since JCE1.2 >>> + * @since 1.4, JCE1.2 >>> */ >>> public void close() throws IOException { >>> if (closed) { >>> diff --git a/src/share/classes/javax/naming/InitialContext.java >>> b/src/share/classes/javax/naming/InitialContext.java >>> --- a/src/share/classes/javax/naming/InitialContext.java >>> +++ b/src/share/classes/javax/naming/InitialContext.java >>> @@ -125,7 +125,7 @@ >>> * @see Context >>> * @see NamingManager#setInitialContextFactoryBuilder >>> * NamingManager.setInitialContextFactoryBuilder >>> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 >>> + * @since 1.3, JNDI 1.1 >>> */ >>> >>> public class InitialContext implements Context { >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Tue Jun 24 14:03:17 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Jun 2014 16:03:17 +0200 Subject: ThreadLocalRandom clinit troubles In-Reply-To: References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> Message-ID: <53A98525.9080908@gmail.com> Hi Martin, On 06/22/2014 07:12 PM, Martin Buchholz wrote: > We know that loading the networking machinery is problematic. On Linux we > would be content to hard-code a read from /dev/urandom, which is safer and > strictly more random than the existing network hardware determination, but > y'all will reject that as too system-dependent (insufficient machinery!). > Hmmmm .... maybe not .... as long as we code up a good fallback ... > > I learned that SecureRandom by default on Unix uses /dev/random for "seed > bytes" and /dev/urandom for nextBytes. > > Here's my proposal, that in the default case on Unix doesn't load any > machinery, and as a fallback loads the SecureRandom machinery instead of > the network machinery, while maintaining the ultra-secure behavior of the > java.util.secureRandomSeed system property: > > > private static long initialSeed() { > byte[] seedBytes = initialSeedBytes(); > long s = (long)(seedBytes[0]) & 0xffL; > for (int i = 1; i < seedBytes.length; ++i) > s = (s << 8) | ((long)(seedBytes[i]) & 0xffL); > return s ^ mix64(System.currentTimeMillis()) ^ > mix64(System.nanoTime()); > } > > private static byte[] initialSeedBytes() { > String pp = java.security.AccessController.doPrivileged( > new sun.security.action.GetPropertyAction( > "java.util.secureRandomSeed")); > boolean secureRandomSeed = (pp != null && > pp.equalsIgnoreCase("true")); > if (secureRandomSeed) > return java.security.SecureRandom.getSeed(8); > final byte[] seedBytes = new byte[8]; > File seedSource = new File("/dev/urandom"); > if (seedSource.exists()) { > try (FileInputStream stream = new FileInputStream(seedSource)) { > if (stream.read(seedBytes) == 8) > return seedBytes; > } catch (IOException ignore) { } > } > new java.security.SecureRandom().nextBytes(seedBytes); > return seedBytes; > } So on platforms lacking "/dev/urandom" special file (Windows only?), the fall-back would be to use SecureRandom.nextBytes() whatever default SecureRandom PRNG is configured to be on such platform. This might be a user-supplied SecureRandom PRNG. The user might want it's own default SecureRandom but not use it for TLR's seed computation (unless requested by "java.util.secureRandomSeed" system property). I would rather use SecureRandom.generateSeed() instance method instead of SecureRandom.nextBytes(). Why? Because every SecureRandom instance has to initialize it's seed 1st before getBytes() can provide the next random bytes from the PRNG. Since we only need the 1st 8 bytes from the SecureRandom instance to initialize TLR's seeder, we might as well directly call the SecureRandom.generateSeed() method. That's one reason. The other is the peculiar initialization of default SecureRandom algorithm on Windows (see below)... Even if user does not provide it's own default SecureRandom PRNG, there are basically two algorithms that are used by default on OpenJDK: On Solaris/Linux/Mac/AIX: the "NativePRNG" algorithm from "SUN" provider (implemented by sun.security.provider.NativePRNG) which uses /dev/random for getBytes() and /dev/urandom (or whatever is configured with "java.security.egd" or "securerandom.source" system properties) for generateSeed(), and On Windows: the "SHA1PRNG" algorithm from "SUN" provider (implemented by sun.security.provider.SecureRandom) which uses SHA1 message digest for generating random numbers with seed computed by gathering system entropy... The most problematic one is the default on Windows platform (the platform that does not have the "/dev/urandom" special file and would be used as a fall-back by your proposal) - sun.security.provider.SecureRandom. This one seeds itself by constructing an instance of itself with the result returned from SeedGenerator.getSystemEntropy() method. This method, among other things, uses networking code to gather system entropy: ... md.update (InetAddress.getLocalHost().toString().getBytes()); ... This is problematic since it not only initializes NameService providers but also uses them to resolve local host name. This can block for several seconds on unusual configurations and was the main motivation to replace similar code in TLR with code that uses NetworkInterface.getHardwareAddress() instead. Using SecureRandom.generateSeed() instead of SecureRandom.getBytes() does not invoke SeedGenerator.getSystemEntropy(), but uses just SeedGenerator.generateSeed(), which by default on Windows uses ThreadedSeedGenerator.getSeedBytes()... I showed how we could suppress NameService providers initialization while still using NetworkInterface.getHardwareAddress() for TLR's seeder initialization. If that's not enough and we would like to get-away without using networking code at all, then I propose the following: private static byte[] initialSeedBytes() { String secureRandomSeed = java.security.AccessController.doPrivileged( new sun.security.action.GetPropertyAction( "java.util.secureRandomSeed", "")) .toLowerCase(Locale.ROOT); String osName = java.security.AccessController.doPrivileged( new sun.security.action.GetPropertyAction( "os.name")) .toLowerCase(Locale.ROOT); if (!secureRandomSeed.equals("true") && !secureRandomSeed.equals("blocking")) { secureRandomSeed = "nonblocking"; // default } SecureRandom srnd = null; if (secureRandomSeed.equals("nonblocking")) { // the default try { if (osName.startsWith("windows")) { // native implementation using MSCAPI implemented by // sun.security.mscapi.PRNG srnd = SecureRandom.getInstance("Windows-PRNG", "SunMSCAPI"); } else { // Solaris/Linux/Mac/AIX // a non-blocking native implementation using /dev/urandom for both // generateSeed() and nextBytes() implemented by // sun.security.provider.NativePRNG$NonBlocking srnd = SecureRandom.getInstance("NativePRNGNonBlocking", "SUN"); } } catch (NoSuchProviderException | NoSuchAlgorithmException ignore) {} } else if (secureRandomSeed.equals("blocking")) { try { if (osName.startsWith("windows")) { // native implementation using MSCAPI implemented by // sun.security.mscapi.PRNG srnd = SecureRandom.getInstance("Windows-PRNG", "SunMSCAPI"); } else { // Solaris/Linux/Mac/AIX // a blocking native implementation using /dev/random for both // generateSeed() and nextBytes() implemented by // sun.security.provider.NativePRNG$Blocking srnd = SecureRandom.getInstance("NativePRNGBlocking", "SUN"); } } catch (NoSuchProviderException | NoSuchAlgorithmException ignore) {} } else { assert secureRandomSeed.equals("true"); } if (srnd == null) { // fall back to default SecureRandom algorithm / provider srnd = new SecureRandom(); } return srnd.generateSeed(8); } By default (or when "java.util.secureRandomSeed" is set to "nonblocking" or unrecognized value) this would use /dev/urandom on UNIX-es and MSCAPI on Windows. More entropy for TLR's initial seeder could be provided on UNIX-es by risking some blocking with "java.util.secureRandomSeed" set to "blocking". This would still be independend of user's choice of default SecureRandom provider. The backward-compatible ("java.util.secureRandomSeed" set to "true") or fall-back would be to use default SecureRandom algorithm / provider. Regards, Peter > > > > On Sat, Jun 21, 2014 at 9:05 PM, Martin Buchholz > wrote: > >> While looking at NativePRNG, I filed >> >> https://bugs.openjdk.java.net/browse/JDK-8047769 >> >> SecureRandom should be more frugal with file descriptors >> >> If I run this java program on Linux >> >> public class SecureRandoms { >> public static void main(String[] args) throws Throwable { >> new java.security.SecureRandom(); >> } >> } >> >> it creates 6 file descriptors for /dev/random and /dev/urandom, as shown >> by: >> >> strace -q -ff -e open java SecureRandoms |& grep /dev/ >> [pid 20769] open("/dev/random", O_RDONLY) = 5 >> [pid 20769] open("/dev/urandom", O_RDONLY) = 6 >> [pid 20769] open("/dev/random", O_RDONLY) = 7 >> [pid 20769] open("/dev/random", O_RDONLY) = 8 >> [pid 20769] open("/dev/urandom", O_RDONLY) = 9 >> [pid 20769] open("/dev/urandom", O_RDONLY) = 10 >> >> Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java >> it looks like 2 file descriptors are created for every variant of >> NativePRNG, whether or not they are ever used. Which is wasteful. In fact, >> you only ever need at most two file descriptors, one for /dev/random and >> one for /dev/urandom. >> >> Further, it would be nice if the file descriptors were closed when idle >> and lazily re-created. Especially /dev/random should typically be used at >> startup and never thereafter. >> >> >> On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman >> wrote: >> >>> On 20/06/2014 15:02, Peter Levart wrote: >>> >>>> And, as Martin pointed out, it seems to be used for tests that exercise >>>> particular responses from NameService API to test the behaviour of JDK >>>> classes. It would be a shame for those tests to go away. >>>> >>> We've been talking about removing it for many years because it has been >>> so troublesome. If we really need to having something for testing then I >>> don't think it needs to be general purpose, we can get right of the lookup >>> at least. >>> >>> -Alan. >>> >> From peter.levart at gmail.com Tue Jun 24 21:35:37 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Jun 2014 23:35:37 +0200 Subject: ThreadLocalRandom clinit troubles In-Reply-To: References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> Message-ID: <53A9EF29.7030208@gmail.com> On 06/24/2014 06:01 PM, Martin Buchholz wrote: > > > > On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart > wrote: > > > I would rather use SecureRandom.generateSeed() instance method > instead of SecureRandom.nextBytes(). Why? Because every > SecureRandom instance has to initialize it's seed 1st before > getBytes() can provide the next random bytes from the PRNG. Since > we only need the 1st 8 bytes from the SecureRandom instance to > initialize TLR's seeder, we might as well directly call the > SecureRandom.generateSeed() method. > > > If I strace this program on Linux using strace -ff -q java SecureRandoms: > > public class SecureRandoms { > public static void main(String[] args) throws Throwable { > byte[] bytes = new byte[8]; > new java.security.SecureRandom().nextBytes(bytes); > } > } > > I see a read from /dev/urandom, but not from /dev/random, so I > conclude your intuitive understanding of how the seeding works must be > wrong. It makes sense that NativePRNG doesn't need to do any special > seeding of its own, since it reuses the operating system's. You're right. I checked again. The NativePRNG is actually using /dev/urandom (by default unless java.security.egd or securerandom.source is defined). It's mixing the /dev/urandom stream with the stream obtained from SHA1 generator which is seeded by 20 bytes from /dev/urandom too. So by default yes, plain NativePRNG (the default on UNIX-es) is using /dev/urandom for nextBytes(), but this can be changed by defining java.security.egd or securerandom.source system property. I still think that for configuration-independent PRNG seed on UNIX-es it's better to invoke generateSeed() on NativePRNG$NonBlocking, which hard-codes /dev/urandom and doesn't mix it with SHA1 stream. On Windows, there's a different story, since the default SecureRandom algorithm is SHA1, seeded by SeedGenerator.getSystemEntropy() and SeedGenerator.generateSeed(). The former call includes invoking networking code and resolving local host name. Which we would like to avoid. So I think we need a nicer story on windows then just: new SecureRandom().nextBytes(). I propose requesting explicit algorithm / provider on each particular platform that we know does best what we want, rather than using default which can still be used as a fall-back. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jun 25 08:48:56 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 25 Jun 2014 16:48:56 +0800 Subject: RFR 8048073: Cannot read ccache entry with a realm-less service name Message-ID: <53974442-173C-46D5-9773-C450ABE35D18@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8048073/webrev.00/ Running native krb5 could generate a ccache file like this Valid starting Expires Service principal 06/25/14 14:05:06 06/26/14 00:05:06 krbtgt/K1 at K1 06/25/14 14:12:35 06/26/14 00:05:06 HTTP/localhost@ 06/25/14 14:12:35 06/26/14 00:05:06 HTTP/localhost at K1 Please note the 2nd ticket has a service principal with no realm. I guess it's a result of kerberos referral. Since OpenJDK does not support referral (yet), the PricipalName always has a realm and reading such a ccache throws out an exception. After this fix such entries are ignored and Java's klist would show [1] Service Principal: krbtgt/K1 at K1 Valid starting: Jun 25, 2014 14:05:06 Expires: Jun 26, 2014 00:05:06 [2] Service Principal: HTTP/localhost at K1 Valid starting: Jun 25, 2014 14:12:35 Expires: Jun 26, 2014 00:05:06 Thanks Max From xuelei.fan at oracle.com Wed Jun 25 09:05:46 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 25 Jun 2014 17:05:46 +0800 Subject: RFR 8048073: Cannot read ccache entry with a realm-less service name In-Reply-To: <53974442-173C-46D5-9773-C450ABE35D18@oracle.com> References: <53974442-173C-46D5-9773-C450ABE35D18@oracle.com> Message-ID: <53AA90EA.5080808@oracle.com> On 6/25/2014 4:48 PM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8048073/webrev.00/ > Looks fine to me. It would be nice to add more comment about why you want to ignore the principal if (cpname == null || spname == null) Xuelei > Running native krb5 could generate a ccache file like this > > Valid starting Expires Service principal > 06/25/14 14:05:06 06/26/14 00:05:06 krbtgt/K1 at K1 > 06/25/14 14:12:35 06/26/14 00:05:06 HTTP/localhost@ > 06/25/14 14:12:35 06/26/14 00:05:06 HTTP/localhost at K1 > > Please note the 2nd ticket has a service principal with no realm. I guess it's a result of kerberos referral. Since OpenJDK does not support referral (yet), the PricipalName always has a realm and reading such a ccache throws out an exception. After this fix such entries are ignored and Java's klist would show > > [1] Service Principal: krbtgt/K1 at K1 > Valid starting: Jun 25, 2014 14:05:06 > Expires: Jun 26, 2014 00:05:06 > [2] Service Principal: HTTP/localhost at K1 > Valid starting: Jun 25, 2014 14:12:35 > Expires: Jun 26, 2014 00:05:06 > > Thanks > Max > From weijun.wang at oracle.com Wed Jun 25 10:42:12 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 25 Jun 2014 18:42:12 +0800 Subject: RFR 8048073: Cannot read ccache entry with a realm-less service name In-Reply-To: <53AA90EA.5080808@oracle.com> References: <53974442-173C-46D5-9773-C450ABE35D18@oracle.com> <53AA90EA.5080808@oracle.com> Message-ID: <8F408F9E-B95F-43BD-826D-DB4E88644870@oracle.com> On Jun 25, 2014, at 17:05, Xuelei Fan wrote: > On 6/25/2014 4:48 PM, Wang Weijun wrote: >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8048073/webrev.00/ >> > Looks fine to me. It would be nice to add more comment about why you > want to ignore the principal > if (cpname == null || spname == null) OK. Thanks Max > > Xuelei > >> Running native krb5 could generate a ccache file like this >> >> Valid starting Expires Service principal >> 06/25/14 14:05:06 06/26/14 00:05:06 krbtgt/K1 at K1 >> 06/25/14 14:12:35 06/26/14 00:05:06 HTTP/localhost@ >> 06/25/14 14:12:35 06/26/14 00:05:06 HTTP/localhost at K1 >> >> Please note the 2nd ticket has a service principal with no realm. I guess it's a result of kerberos referral. Since OpenJDK does not support referral (yet), the PricipalName always has a realm and reading such a ccache throws out an exception. After this fix such entries are ignored and Java's klist would show >> >> [1] Service Principal: krbtgt/K1 at K1 >> Valid starting: Jun 25, 2014 14:05:06 >> Expires: Jun 26, 2014 00:05:06 >> [2] Service Principal: HTTP/localhost at K1 >> Valid starting: Jun 25, 2014 14:12:35 >> Expires: Jun 26, 2014 00:05:06 >> >> Thanks >> Max >> > From ivan.gerasimov at oracle.com Thu Jun 26 14:56:26 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 26 Jun 2014 18:56:26 +0400 Subject: RFR [8048080] (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX Message-ID: <53AC349A.2080102@oracle.com> Hello! This bug is very similar to JDK-7195480, in the sense it is due to the structure misalignment under MacOSX. I didn't fix it together with JDK-7195480 because I hadn't had a testcase in hands at that time to verify the change. Now, I've got a testcase from SQE and it confirms the change is good. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8048080 WEBREV: http://cr.openjdk.java.net/~igerasim/8048080/0/webrev/ Sincerely yours, Ivan From valerie.peng at oracle.com Thu Jun 26 18:12:41 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 26 Jun 2014 11:12:41 -0700 Subject: RFR [8048080] (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX In-Reply-To: <53AC349A.2080102@oracle.com> References: <53AC349A.2080102@oracle.com> Message-ID: <53AC6299.6040501@oracle.com> Looks good. Thanks, Valerie On 6/26/2014 7:56 AM, Ivan Gerasimov wrote: > Hello! > > This bug is very similar to JDK-7195480, in the sense it is due to the > structure misalignment under MacOSX. > I didn't fix it together with JDK-7195480 because I hadn't had a > testcase in hands at that time to verify the change. > Now, I've got a testcase from SQE and it confirms the change is good. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8048080 > WEBREV: http://cr.openjdk.java.net/~igerasim/8048080/0/webrev/ > > Sincerely yours, > Ivan From rajan.halade at oracle.com Thu Jun 26 21:02:59 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 26 Jun 2014 14:02:59 -0700 Subject: [JDK 9] RFR: 8041781: Need new regression tests for PBE keys In-Reply-To: <53A21480.40808@oracle.com> References: <53A21480.40808@oracle.com> Message-ID: <53AC8A83.1040501@oracle.com> Ping...can someone help review this please. Thanks, Rajan On 6/18/14, 3:36 PM, Rajan Halade wrote: > May I request you to review these 3 new tests to be added for PBE > keys. New tests are added to address following: > > - seal/unseal works correctly with PBE algorithms > - key wrapper works correctly with PBEKey > - SecretKeyFactory.translateKey() method works > > JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8041781 > Webrev: http://cr.openjdk.java.net/~rhalade/8041781/webrev.00/ > > Thanks, > Rajan From valerie.peng at oracle.com Thu Jun 26 21:33:01 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 26 Jun 2014 14:33:01 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53A4B614.90900@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> Message-ID: <53AC918D.6070308@oracle.com> Updated the webrev in place (still at webrev.01), now that Mandy has putback'ed her fix for the ClassLoader.loadLibrary issue. Thanks, Valerie On 6/20/2014 3:30 PM, Valerie Peng wrote: > > Webrev is updated at: > http://cr.openjdk.java.net/~valeriep/8043406/webrev.01 > Sure, I will file a bug after Mandy's confirmation. > Thanks, > Valerie > > On 6/20/2014 8:46 AM, Sean Mullan wrote: >> 36 // Needed by Runtime.loadLibrary(String) call >> 37 permission java.io.FilePermission "<>", "read"; >> >> It seems like this is due to a bug in Runtime.loadLibrary, since you >> have already granted the provider the permission to load the library. >> I think possibly the call to ClassLoader.loadLibrary should be inside >> a doPrivileged. The workaround is ok for now, but can you file a >> separate bug for this? >> >> --Sean >> >> On 06/18/2014 06:51 PM, Valerie Peng wrote: >>> Sean, >>> >>> Not sure if you can get to reviewing this before your vacation. >>> If not, I will find someone else to help... >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8043406/webrev.00/ >>> >>> Thanks, >>> Valerie From valerie.peng at oracle.com Thu Jun 26 21:51:22 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 26 Jun 2014 14:51:22 -0700 Subject: RFR 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics In-Reply-To: <53A4B69B.6030001@oracle.com> References: <537548EE.5050909@oracle.com> <53A20A47.4010602@oracle.com> <53A26ED8.70908@oracle.com> <53A4B69B.6030001@oracle.com> Message-ID: <53AC95DA.8000507@oracle.com> Xuelei and Tony, Please find the updated webrev at http://cr.openjdk.java.net/~valeriep/8027575/webrev.01/ I enhanced existing regression test and modified the fix slightly regarding to when to copy out the input for the same-src/dest-buffer case, i.e. do the encryption/decryption operation in place if the output offset is sufficiently apart from the input range, i.e. [(inOfs - 2 blocks)....(inOfs + inLen)] Thanks, Valerie On 6/20/2014 3:32 PM, Valerie Peng wrote: > > Hmm, maybe. I will add one. > Thanks for the review. > Valerie > > On 6/18/2014 10:02 PM, Anthony Scarpino wrote: >> The code change looks fine. Do you think this is worth a regression >> test? Since the in-place operation wasn't caught it sound like there >> might be no in-place tests >> >> Tony >> >> On 06/18/2014 02:53 PM, Valerie Peng wrote: >>> >>> Tony or Vinnie, either of you have time to review? >>> Thanks, >>> Valerie >>> >>> On 5/15/2014 4:08 PM, Valerie (Yu-Ching) Peng wrote: >>>> >>>> Can someone help reviewing this SunJCE provider fix? Essentially, >>>> CipherCore class is updated to minimize memory allocation and data >>>> copying. The fix has been verified against the wls_webapp_atomics >>>> benchmark. >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8027575/webrev.00/ >>>> >>>> Thanks, >>>> Valerie >> From peter.levart at gmail.com Wed Jun 25 17:41:57 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 25 Jun 2014 19:41:57 +0200 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53A9EF29.7030208@gmail.com> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> Message-ID: <53AB09E5.9070303@gmail.com> To sum-up: We have a problem with TLR initialization since by default it uses networking code to compute initial "seeder" value which can execute user code in at least two situations: - when "sun.net.spi.nameservice.provider" system property is defined to use custom NameService provider - when custom SecurityManager is in effect while TLR is being initialized - also, when "java.util.secureRandomSeed" is defined, at least on Windows this means that default SecureRandom algorithm will be using networking code too to gather system entropy We could work-around these problems by delaying initialization of NameService provider(s), by-passing SecurityManager when obtaining MAC address from NetworkInterface and extending the semantics of "java.util.secureRandomSeed" property to specify explicit SecureRandom algorithm and provider to use when obtaining SecureRandom instance, like in the following patch: http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR.initialSeed/webrev.01/ But on the other hand this seems too many knobs to worry about. Ideally one would like to always use OS provided native seed source, but SecureRandom (with all the security providers infrastructure) seems too heavy-weight to be used in classes like ThreadLocalRandom or SplittableRandom by default since they can be initialized very early in the start-up sequence. I made an experiment with class-loading. Recent JDK9 build loads 381 classes when running the following empty program on Linux: public class test0 { public static void main(String[] args) { } } ...ThreadLocalRandom is not among them. But in special configurations (like when using java agents) or in the future, it could be. The following program: public class test { public static void main(String[] args) { java.util.concurrent.ThreadLocalRandom.current(); } } ...loads 403 classes. That's 22 more than an empty program. The following classes are loaded in addition: + java.util.Random + java.util.concurrent.ThreadLocalRandom + java.net.NetworkInterface + java.net.NetworkInterface$1 + java.net.InterfaceAddress + java.net.InetAddress + sun.security.action.GetBooleanAction + java.net.InetAddress$1 + java.net.InetAddress$InetAddressHolder + java.net.InetAddress$Cache + java.net.InetAddress$Cache$Type + java.net.InetAddressImplFactory + java.net.InetAddressImpl + java.net.Inet6AddressImpl + sun.net.spi.nameservice.NameService + java.net.InetAddress$2 + java.net.Inet4Address + java.net.Inet6Address + java.net.Inet6Address$Inet6AddressHolder + java.net.DefaultInterface + java.net.NetworkInterface$2 + sun.nio.ch.Interruptible If I run the same program but set the "java.util.secureRandomSeed=true", it loads 435 classes. Besides 381 classes loaded by an empty program, the following 54 classes are loaded in addition: + java.util.Random + java.util.concurrent.ThreadLocalRandom + java.security.SecureRandom + sun.security.jca.Providers + java.lang.InheritableThreadLocal + sun.security.jca.ProviderList + sun.security.jca.ProviderConfig + java.security.Provider + sun.security.jca.ProviderList$3 + sun.security.jca.ProviderList$1 + java.security.Provider$ServiceKey + java.security.Provider$EngineDescription + sun.misc.FloatingDecimal + sun.misc.FloatingDecimal$BinaryToASCIIConverter + sun.misc.FloatingDecimal$ExceptionalBinaryToASCIIBuffer + sun.misc.FloatingDecimal$BinaryToASCIIBuffer + sun.misc.FloatingDecimal$1 + sun.misc.FloatingDecimal$ASCIIToBinaryConverter + sun.misc.FloatingDecimal$PreparedASCIIToBinaryBuffer + sun.misc.FDBigInteger + sun.security.jca.ProviderList$2 + java.security.Security + java.security.Security$1 + java.util.Properties$LineReader + java.util.AbstractList$Itr + sun.security.jca.ProviderConfig$2 + sun.security.provider.Sun + sun.security.provider.SunEntries + sun.security.provider.SunEntries$1 + java.security.SecureRandomSpi + sun.security.provider.NativePRNG + sun.security.provider.NativePRNG$Variant + sun.security.provider.NativePRNG$1 + sun.security.provider.NativePRNG$2 + java.net.URI + java.net.URI$Parser + sun.security.provider.NativePRNG$RandomIO + sun.security.provider.NativePRNG$Blocking + sun.security.provider.NativePRNG$NonBlocking + java.util.LinkedHashMap$LinkedEntrySet + java.util.LinkedHashMap$LinkedHashIterator + java.util.LinkedHashMap$LinkedEntryIterator + java.security.Provider$Service + java.security.Provider$UString + java.util.LinkedHashSet + java.util.LinkedHashMap$LinkedValues + java.util.LinkedHashMap$LinkedValueIterator + java.util.Collections$UnmodifiableSet + java.util.Collections$UnmodifiableCollection$1 + java.util.LinkedHashMap$LinkedKeySet + java.util.LinkedHashMap$LinkedKeyIterator + sun.security.jca.GetInstance + sun.security.jca.GetInstance$Instance + sun.nio.ch.Interruptible This seems too heavy-weight even if the initialization issue on Windows where default SecureRandom algorithm is using networking code to gather system entropy is worked-around by requesting explicit "Windows-PRNG" SecureRandom algorithm from "SunMSCAPI" provider. Peeking around in the sun.security.provider package, I found there already is a minimal internal infrastructure for obtaining random seed. It's encapsulated in package-private abstract class sun.security.provider.SeedGenerator with 4 implementations. It turns out that, besides Java-only fall-back implementation called ThreadedSeedGenerator and generic URLSeedGenerator, there are also two implementations of NativeSeedGenerator (one for UNIX-es which is just an extension of URLSeedGenerator and the other for Windows which uses MS CryptoAPI). I made a few tweaks that allow this sub-infrastructure to be used directly in ThreadLocalRandom and SplittableRandom: http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/ The changes are as follows: - modified SeedGenerator to be a public class (was package-private as are still all it's subclasses) - made its only public static method package-private (was public for no reason) - made its only abstract method public (was package-private) - made SeedGenerator implement AutoCloseable with empty close() method (overriden in URLSeedGenerator to close the underlying stream) - added public static factory method to return a new instance of NativeSeedGenerator (using /dev/urandom on UNIX-es, MSCAPI on Windows) and protected it with a runtime check so that it can only be used internally With these changes and modified TLR, running the test program (see above) loads only the following 15 additional classes besides those that are loaded by an empty program on Linux (and I assume the number is the same on Windows): + java.util.Random + java.util.concurrent.ThreadLocalRandom + sun.security.provider.SeedGenerator + sun.security.provider.SunEntries + sun.security.provider.SunEntries$1 + java.security.Security + java.security.Security$1 + java.util.Properties$LineReader + sun.security.provider.SeedGenerator$URLSeedGenerator + sun.security.provider.NativeSeedGenerator + sun.security.provider.SeedGenerator$1 + sun.security.provider.SeedGenerator$URLSeedGenerator$1 + java.net.URI + java.net.URI$Parser + sun.nio.ch.Interruptible So what do you think is the best direction to go further with this? Patching networking or exposing NativeSeedGenerator to internal JDK code? Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From dingding303 at gmail.com Thu Jun 26 04:02:24 2014 From: dingding303 at gmail.com (Xiaomin Ding) Date: Thu, 26 Jun 2014 12:02:24 +0800 Subject: A Bug in AccessControlContext.equals() and hashCode()? Message-ID: >On 6/16/2014 10:40 PM, David M. Lloyd wrote: >On 06/16/2014 09:19 AM, Frank Ding wrote: >> Hi Jeff, >> Thanks for your reply. One further question is that you confirmed >> that two AccessControlContext objects considered equal via method >> equals() should return same results for >> AccessControlContext.checkPermission() but test shows that 2 >> AccessControlContext objects are equal regardless of isLimited, >> limitedContext, parent, permissions, or privilegedContext. Does it make >> sense and apply to Java 8 AccessControlContext with JEP140? > >Is it not true that a limited privileged context simply adds a >protection domain that restricts permissions to the limited set? This >seems to be the "obvious" implementation of the feature. > >If so, then equals() should have taken it into account as a matter of >course. >-- >- DML Hi Jeff, Could you pls let us know your insight? Regards, Frank From dl at cs.oswego.edu Thu Jun 26 23:10:22 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 26 Jun 2014 19:10:22 -0400 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53AB09E5.9070303@gmail.com> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> Message-ID: <53ACA85E.2030407@cs.oswego.edu> Peter: Thanks very much for attacking the shocking impact/complexity of getting a few seed bits. On 06/25/2014 01:41 PM, Peter Levart wrote: > > Peeking around in the sun.security.provider package, I found there already is a > minimal internal infrastructure for obtaining random seed. It's encapsulated in > package-private abstract class sun.security.provider.SeedGenerator with 4 > implementations. It turns out that, besides Java-only fall-back implementation > called ThreadedSeedGenerator and generic URLSeedGenerator, there are also two > implementations of NativeSeedGenerator (one for UNIX-es which is just an > extension of URLSeedGenerator and the other for Windows which uses MS > CryptoAPI). I made a few tweaks that allow this sub-infrastructure to be used > directly in ThreadLocalRandom and SplittableRandom: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/ > This seems to be the best idea yet, assuming that people are OK with the changes to sun.security.provider.SeedGenerator and NativeSeedGenerator.java -Doug From bradford.wetmore at oracle.com Thu Jun 26 23:35:03 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 26 Jun 2014 16:35:03 -0700 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53ACA85E.2030407@cs.oswego.edu> References: <53A29DC5.1030605@oracle.com> <53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com> <53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com> <53A44C3A.6000607@oracle.com> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> <53ACA85E.2030407@cs.oswego.edu> Message-ID: <53ACAE27.3050903@oracle.com> On 6/26/2014 4:10 PM, Doug Lea wrote: > This seems to be the best idea yet, assuming that people are OK > with the changes to sun.security.provider.SeedGenerator and > NativeSeedGenerator.java I've been meaning to review this thread, but have been chasing several urgent escalations. Brad From Xuelei.Fan at Oracle.COM Fri Jun 27 04:21:24 2014 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Fri, 27 Jun 2014 12:21:24 +0800 Subject: RFR 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics In-Reply-To: <53AC95DA.8000507@oracle.com> References: <537548EE.5050909@oracle.com> <53A20A47.4010602@oracle.com> <53A26ED8.70908@oracle.com> <53A4B69B.6030001@oracle.com> <53AC95DA.8000507@oracle.com> Message-ID: <53ACF144.6010909@Oracle.COM> Looks fine to me. On 6/27/2014 5:51 AM, Valerie Peng wrote: > Xuelei and Tony, > > Please find the updated webrev at > http://cr.openjdk.java.net/~valeriep/8027575/webrev.01/ > > I enhanced existing regression test and modified the fix slightly > regarding to when to copy out the input for the same-src/dest-buffer > case, i.e. do the encryption/decryption operation in place if the output > offset is sufficiently apart from the input range, i.e. [(inOfs - 2 > blocks)....(inOfs + inLen)] > It would be nice if you add the above as a comment in CipherCore.java. Thanks, Xuelei > Thanks, > Valerie > > On 6/20/2014 3:32 PM, Valerie Peng wrote: >> >> Hmm, maybe. I will add one. >> Thanks for the review. >> Valerie >> >> On 6/18/2014 10:02 PM, Anthony Scarpino wrote: >>> The code change looks fine. Do you think this is worth a regression >>> test? Since the in-place operation wasn't caught it sound like there >>> might be no in-place tests >>> >>> Tony >>> >>> On 06/18/2014 02:53 PM, Valerie Peng wrote: >>>> >>>> Tony or Vinnie, either of you have time to review? >>>> Thanks, >>>> Valerie >>>> >>>> On 5/15/2014 4:08 PM, Valerie (Yu-Ching) Peng wrote: >>>>> >>>>> Can someone help reviewing this SunJCE provider fix? Essentially, >>>>> CipherCore class is updated to minimize memory allocation and data >>>>> copying. The fix has been verified against the wls_webapp_atomics >>>>> benchmark. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8027575/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie >>> From Xuelei.Fan at Oracle.COM Fri Jun 27 05:19:36 2014 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Fri, 27 Jun 2014 13:19:36 +0800 Subject: [JDK 9] RFR: 8041781: Need new regression tests for PBE keys In-Reply-To: <53AC8A83.1040501@oracle.com> References: <53A21480.40808@oracle.com> <53AC8A83.1040501@oracle.com> Message-ID: <53ACFEE8.20408@Oracle.COM> Looks fine to me. Would you like also add tests for PBEMAC, e.g., PBEWithHmacSHA1? Thanks, Xuelei On 6/27/2014 5:02 AM, Rajan Halade wrote: > Ping...can someone help review this please. > > Thanks, > Rajan > On 6/18/14, 3:36 PM, Rajan Halade wrote: >> May I request you to review these 3 new tests to be added for PBE >> keys. New tests are added to address following: >> >> - seal/unseal works correctly with PBE algorithms >> - key wrapper works correctly with PBEKey >> - SecretKeyFactory.translateKey() method works >> >> JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8041781 >> Webrev: http://cr.openjdk.java.net/~rhalade/8041781/webrev.00/ >> >> Thanks, >> Rajan > From jamil.j.nimeh at oracle.com Sat Jun 28 23:59:58 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 28 Jun 2014 16:59:58 -0700 Subject: RFR: 8015081 Message-ID: <53AF56FE.1000304@oracle.com> Hello all, This follow-on webrev addresses the following issues: * Adds braces to if/else constructs * Fixes imports in Serial.java and Generic.java tests to explicitly import javax.security.auth.Subject rather than javax.security.auth.*. The overridden Subject.java solution in the test directory appears to cause compilation issues, but specifying the Subject class on the import line fixes things, and the tests don't need all of javax.security.auth. * Added the hashCode method to the SecureSet inner class. http://cr.openjdk.java.net/~ascarpino/8015081/webrev.08 Thanks, --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sun Jun 29 04:03:28 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 29 Jun 2014 12:03:28 +0800 Subject: RFR: 8015081 In-Reply-To: <53AF56FE.1000304@oracle.com> References: <53AF56FE.1000304@oracle.com> Message-ID: <53AF9010.1000402@oracle.com> Looks fine to me. Thanks, Xuelei On 6/29/2014 7:59 AM, Jamil Nimeh wrote: > Hello all, > > This follow-on webrev addresses the following issues: > > * Adds braces to if/else constructs > * Fixes imports in Serial.java and Generic.java tests to explicitly > import javax.security.auth.Subject rather than > javax.security.auth.*. The overridden Subject.java solution in the > test directory appears to cause compilation issues, but specifying > the Subject class on the import line fixes things, and the tests > don't need all of javax.security.auth. > * Added the hashCode method to the SecureSet inner class. > > http://cr.openjdk.java.net/~ascarpino/8015081/webrev.08 > > Thanks, > --Jamil > From firmeromanesti at gmail.com Fri Jun 27 17:51:42 2014 From: firmeromanesti at gmail.com (firme_romanesti) Date: Fri, 27 Jun 2014 20:51:42 +0300 Subject: Buna ziua Message-ID: <20140627175142272.743624C635A16F59@Calin-PC> CERERE_ACCEPTARE_COMUNICARI_COMERCIALE: Cu_accordul_dumneavoastra_as dori sa va intreb_daca va intereseaza un catalog de firme in format electronic (tabele excel) cu 59.000 firme cu date complete de identificare, din tara, clasificate in 418 domenii de activitate pentru revigorarea afacerii dvs.-170 RON? Puteti primi mai multe informatii prin email daca sunteti interesati Daca acest mesaj a ajuns din greseala la dvs. si nu prezinta interes va rog dati un reply cu subiectul :"NU". Multumim pentru intelegere. O zi buna. Va doresc o vara frumoasa !