From weijun.wang at oracle.com Tue Jul 1 01:07:14 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 1 Jul 2014 09:07:14 +0800 Subject: RFR 8048511: Uninitialised memory in jdk/src/share/native/sun/security/jgss/wrapper/GSSLibStub.c Message-ID: <789DBD29-CE91-4AE5-8637-5559AE607DA5@oracle.com> Hi Valerie Please review a fix at http://cr.openjdk.java.net/~weijun/8048511/webrev.00/ A static code analysis tool is not happy to see the minor variable not initialized (if none of the ifs in lines 652-658 returns true) and used in the checkStatus() function. Although we know in that case major is 0 and checkStatus() won't touch minor at all, it's better to initialize minor to 0. Noreg-trivial. Thanks Max From valerie.peng at oracle.com Tue Jul 1 16:22:44 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 01 Jul 2014 09:22:44 -0700 Subject: RFR 8048511: Uninitialised memory in jdk/src/share/native/sun/security/jgss/wrapper/GSSLibStub.c In-Reply-To: <789DBD29-CE91-4AE5-8637-5559AE607DA5@oracle.com> References: <789DBD29-CE91-4AE5-8637-5559AE607DA5@oracle.com> Message-ID: <53B2E054.9030801@oracle.com> Changes look fine. Thanks, Valerie On 6/30/2014 6:07 PM, Wang Weijun wrote: > Hi Valerie > > Please review a fix at > > http://cr.openjdk.java.net/~weijun/8048511/webrev.00/ > > A static code analysis tool is not happy to see the minor variable not initialized (if none of the ifs in lines 652-658 returns true) and used in the checkStatus() function. Although we know in that case major is 0 and checkStatus() won't touch minor at all, it's better to initialize minor to 0. > > Noreg-trivial. > > Thanks > Max > From jeffrey.nisewanger at oracle.com Tue Jul 1 19:42:45 2014 From: jeffrey.nisewanger at oracle.com (Jeff Nisewanger) Date: Tue, 01 Jul 2014 12:42:45 -0700 Subject: A Bug in AccessControlContext.equals() and hashCode()? In-Reply-To: References: Message-ID: <53B30F35.8010501@oracle.com> On 6/25/2014 9:02 PM, Xiaomin Ding wrote: >> 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? JDK 8 introduced, via JEP 140, some new variants of the doPrivileged() method. The older doPrivileged() methods simply stop the access control algorithm during a security check so that earlier method's ProtectionDomains on the call stack (or inherited from the parent thread etc.) are not considered and will not cause a security check to be denied. The new "limited" variants from JEP 140 take one or more Permission instances as parameters that describe which specific permission checks should stop the stack walk. Other security checks that do not match the new Permission parameters will cause the stack walk to continue as if the doPrivileged() method had not been used. This allows code to use doPrivileged() to assert a limited subset of its own permissions without asserting all of them. As Frank noted, an AccessControlContext instance may have some additional internal fields initialized when it is created within the scope of a limited version of the doPrivileged() method. These fields are checked in JDK 8 as part of the equals() and checkPermission() implementations. Read the full class-level documentation carefully at the top of the javadoc page for java.security.AccessController. It describes the call stack walking algorithm used during a security check and how that works with the new JDK 8 limited doPrivileged() methods that were added by JEP 140. Here are some javadoc links: http://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html http://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html#getContext-- http://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html#doPrivileged-java.security.PrivilegedAction-java.security.AccessControlContext-java.security.Permission...- For additional background on the new JDK 8 feature that allows limiting the access provided by the use of doPrivileged() please see the following technote subsection: http://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivileged.html#asserting_a_subset_of_privileges And this is the original feature request: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7083329 Two AccessControlContext instances can be created or obtained under differing circumstances and still be considered equal() if they would always check the same internal ProtectionDomains during a call to checkPermission(). AccessControlContexts created within the influence of one of the new JEP 140 methods add some complexity. For instance, if you call AccessController.getContext() when there is a JDK 8 "limited" version of the doPrivileged() method on the thread's call stack it will return an AccessControlContext that conceptually captures and encapsulates the ProtectionDomains of the methods on the call stack leading back to the doPrivileged() call and it will also include the limiting permission parameters of that doPrivileged() call and the earlier call stack elements above the doPrivileged() call. This allows a later direct call to the AccessControlContext's checkPermission() method on any thread to behave the same as a call to AccessController.checkPermission() on the original thread. You might think that this "fancy" AccessControlContext containing the limited doPrivileged() state could not be equal to a "simple" AccessControlContext captured by AccessController.getContext() on a thread without any doPrivileged() method on the call stack or with a non-limited doPrivileged() method on the call stack. However, this may not be true. If the ProtectionDomains on the call stack leading back to the doPrivileged() method are a superset of the ProtectionDomains that are reachable beyond the limited doPrivileged() then those later ProtectionDomains are redundant and the conceptually "fancy" instance will have actually been created with the same internal state as the "simple" instance. From weijun.wang at oracle.com Wed Jul 2 03:46:19 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Jul 2014 11:46:19 +0800 Subject: RFR 8047765: Generate blacklist.certs in build Message-ID: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8047765/webrev.00/ where the generation of blacklisted.certs is moved from developer-manual to build-auto. I copied the mechanisms from GENDATA_HTML32DTD. One thing I am not sure about is that if I update the tool a little, all tools are rebuilt and all gendata files are regenerated. Is this expected? Thanks Max an From david.holmes at oracle.com Wed Jul 2 04:48:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Jul 2014 14:48:09 +1000 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> Message-ID: <53B38F09.8020402@oracle.com> Hi Max, On 2/07/2014 1:46 PM, Wang Weijun wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8047765/webrev.00/ > > where the generation of blacklisted.certs is moved from developer-manual to build-auto. I copied the mechanisms from GENDATA_HTML32DTD. Seems like a reasonable copy of the mechanism. I took a cursory look over the rest of the change, but this isn't my area. src/share/lib/security/blacklisted.certs.pem Typo: + # The line above must be the frist --- src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java Typos: 37 * System.out. The input must starts 54 throw new Exception("The first line must starts starts -> start 73 // Output sorted for eye pleasure. ?? "eye pleasure" --- Cheers, David > One thing I am not sure about is that if I update the tool a little, all tools are rebuilt and all gendata files are regenerated. Is this expected? > > Thanks > Max > an > From weijun.wang at oracle.com Wed Jul 2 05:02:24 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Jul 2014 13:02:24 +0800 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <53B38F09.8020402@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> <53B38F09.8020402@oracle.com> Message-ID: <39EBA356-B833-4EAB-9F50-EBA8C924F54E@oracle.com> On Jul 2, 2014, at 12:48, David Holmes wrote: > > 73 // Output sorted for eye pleasure. > > ?? "eye pleasure" Well, it's easy for a human to locate one from a sorted output. Or maybe it's because the old one is sorted and I don't want the new one looks ugly. --Max From weijun.wang at oracle.com Wed Jul 2 06:12:26 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Jul 2014 14:12:26 +0800 Subject: RFR 8042053: Broken links to jarsigner and keytool docs in java.security package summary Message-ID: <43C3805D-0EBD-447C-8F08-EA1A10EE1489@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8042053/webrev.00/ The Unix-style doc for security tools are in unix/ since JDK 8. Thanks Max From Alan.Bateman at oracle.com Wed Jul 2 07:02:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Jul 2014 08:02:38 +0100 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> Message-ID: <53B3AE8E.3000308@oracle.com> On 02/07/2014 04:46, Wang Weijun wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8047765/webrev.00/ > > where the generation of blacklisted.certs is moved from developer-manual to build-auto. I copied the mechanisms from GENDATA_HTML32DTD. > > One thing I am not sure about is that if I update the tool a little, all tools are rebuilt and all gendata files are regenerated. Is this expected? > Should blacklisted.certs.pem also move into the make tree? I think there has been an effort to put "data files" that are used for generating something in the build into the make tree. Someone from the build will probably should comment on this to make sure that we are consistent. On touch the tool then does this happen for other tools too? I assume it does, in which case you could submit a build bug to improve this. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jul 2 07:29:46 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Jul 2014 15:29:46 +0800 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <53B3AE8E.3000308@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> <53B3AE8E.3000308@oracle.com> Message-ID: <4CCAF299-FFF6-4C3D-87B6-395BCBDE72A3@oracle.com> On Jul 2, 2014, at 15:02, Alan Bateman wrote: > On touch the tool then does this happen for other tools too? I assume it does, in which case you could submit a build bug to improve this. Yes, it does. https://bugs.openjdk.java.net/browse/JDK-8049024 filed. --Max From xuelei.fan at oracle.com Wed Jul 2 08:59:10 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 02 Jul 2014 16:59:10 +0800 Subject: RFR 8042053: Broken links to jarsigner and keytool docs in java.security package summary In-Reply-To: <43C3805D-0EBD-447C-8F08-EA1A10EE1489@oracle.com> References: <43C3805D-0EBD-447C-8F08-EA1A10EE1489@oracle.com> Message-ID: <53B3C9DE.8010209@oracle.com> Looks fine to me. Xuelei On 7/2/2014 2:12 PM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8042053/webrev.00/ > > The Unix-style doc for security tools are in unix/ since JDK 8. > > Thanks > Max > From sean.mullan at oracle.com Wed Jul 2 12:50:35 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 02 Jul 2014 08:50:35 -0400 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <39EBA356-B833-4EAB-9F50-EBA8C924F54E@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> <53B38F09.8020402@oracle.com> <39EBA356-B833-4EAB-9F50-EBA8C924F54E@oracle.com> Message-ID: <53B4001B.4070608@oracle.com> On 07/02/2014 01:02 AM, Wang Weijun wrote: > > On Jul 2, 2014, at 12:48, David Holmes wrote: > >> >> 73 // Output sorted for eye pleasure. >> >> ?? "eye pleasure" > > Well, it's easy for a human to locate one from a sorted output. Or maybe it's because the old one is sorted and I don't want the new one looks ugly. I think David's comment was in reference to the term "eye pleasure" and not to the benefits of sorting the list. Why not just change this to something like: // Output sorted to make it easier to find entries --Sean From weijun.wang at oracle.com Wed Jul 2 13:09:02 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Jul 2014 21:09:02 +0800 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <53B4001B.4070608@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> <53B38F09.8020402@oracle.com> <39EBA356-B833-4EAB-9F50-EBA8C924F54E@oracle.com> <53B4001B.4070608@oracle.com> Message-ID: <55D8310A-7406-43B2-9CE0-9B8D09F40C5D@oracle.com> On Jul 2, 2014, at 20:50, Sean Mullan wrote: > On 07/02/2014 01:02 AM, Wang Weijun wrote: >> >> On Jul 2, 2014, at 12:48, David Holmes wrote: >> >>> >>> 73 // Output sorted for eye pleasure. >>> >>> ?? "eye pleasure" >> >> Well, it's easy for a human to locate one from a sorted output. Or maybe it's because the old one is sorted and I don't want the new one looks ugly. > > > I think David's comment was in reference to the term "eye pleasure" and not to the benefits of sorting the list. Why not just change this to something like: > > // Output sorted to make it easier to find entries Yes, I understand that. Will use your version of comment. --Max > > --Sean From weijun.wang at oracle.com Fri Jul 4 02:30:33 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 4 Jul 2014 10:30:33 +0800 Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL Message-ID: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8044085/webrev.00 With this change, all existing (and future) InquireType values for ExtendedGSSContext.inquireSecContext() are available to the SASL GSSAPI mechanism as negotiated properties. Code change is in GssKrb5Base.java. Clarification in spec of getNegotiatedProperty() in SaslClient and SaslServer. New lines in an existing test for sanity check. Thanks Max From weijun.wang at oracle.com Fri Jul 4 06:12:25 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 4 Jul 2014 14:12:25 +0800 Subject: RFR 8043071: Expose session key and KRB_CRED through extended GSS-API Message-ID: <62344483-E9E6-4FA9-B3AA-F7099DC48192@oracle.com> Hi All Please review the change at http://cr.openjdk.java.net/~weijun/8043071/webrev.00/ Two new inquire type KRB5_GET_SESSION_KEY_EX and KRB5_GET_KRB_CRED are added to get the session key (in a new format) and the KRB_CRED message. Two new classes are created as the types of their return values. Spec for InquireType values are moved into the InquireType class itself. For the existing KerberosKey class, the "A call to any of its other methods after this will cause an IllegalStateException to be thrown" in the spec of destroy() is not precise since we know isDestroyed() and toString/hashCode/equals() do not throw it. The sentence is removed and a @throws clause is added to those methods that do throw the exception. The new KerberosSessionKey and KerberosCredMessage have the same style. Since the data class KeyImpl already throws IllegalStateException when it's destroyed, KerberosKey and KerberosSessionKey do not check again. If you think this makes the code difficult to read, I can add them back. Thanks Max From weijun.wang at oracle.com Fri Jul 4 06:33:26 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 4 Jul 2014 14:33:26 +0800 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <53B3AE8E.3000308@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> <53B3AE8E.3000308@oracle.com> Message-ID: <61413CE6-0650-4E70-BBE4-D99DD7594935@oracle.com> On Jul 2, 2014, at 15:02, Alan Bateman wrote: > Should blacklisted.certs.pem also move into the make tree? I think there has been an effort to put "data files" that are used for generating something in the build into the make tree. Someone from the build will probably should comment on this to make sure that we are consistent. Correct, and there is a jdk/make/data directory and data for other tools are already there. Webrev updated at http://cr.openjdk.java.net/~weijun/8047765/webrev.01/. Thanks Max From Alan.Bateman at oracle.com Fri Jul 4 07:17:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jul 2014 08:17:39 +0100 Subject: RFR 8047765: Generate blacklist.certs in build In-Reply-To: <61413CE6-0650-4E70-BBE4-D99DD7594935@oracle.com> References: <8C568836-9FDF-485A-95CD-A65D51D7AF8F@oracle.com> <53B3AE8E.3000308@oracle.com> <61413CE6-0650-4E70-BBE4-D99DD7594935@oracle.com> Message-ID: <53B65513.1010602@oracle.com> On 04/07/2014 07:33, Wang Weijun wrote: > : > > Correct, and there is a jdk/make/data directory and data for other tools are already there. > > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8047765/webrev.01/. > Thanks for moving it, the updated webrev looks good to me. -Alan. From ivan.gerasimov at oracle.com Sun Jul 6 17:35:11 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 06 Jul 2014 21:35:11 +0400 Subject: RFR: [8049250]: (smartcardio) Need a flag to inverse the Card.disconnect(reset) argument Message-ID: <53B988CF.60706@oracle.com> Hello! With the fix for JDK-7047033, the way Card.disconnect(boolean reset) handles its argument was inverted. To provide compatibility, it is suggested to introduce an option, which a user can use to revert to the old behavior. This fix is proposed for jdk8u only. In jdk8u the option will be false by default, so the reset argument will not be inverted. CCC request has been filed. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8049250 WEBREV: http://cr.openjdk.java.net/~igerasim/8049250/0/webrev/ Sincerely yours, Ivan From erik.gahlin at oracle.com Sun Jul 6 19:34:49 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sun, 06 Jul 2014 21:34:49 +0200 Subject: RFR(S): 8047368: Remove oracle.jrockit.jfr from open package.access list Message-ID: <53B9A4D9.3000105@oracle.com> Hi, Could I have a review of a small fix that removes references to jfr from the package.access list. Bug: https://bugs.openjdk.java.net/browse/JDK-8047368 Webrev: http://cr.openjdk.java.net/~egahlin/8047368/ Thanks Erik From sean.mullan at oracle.com Mon Jul 7 12:20:28 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Jul 2014 08:20:28 -0400 Subject: RFR(S): 8047368: Remove oracle.jrockit.jfr from open package.access list In-Reply-To: <53B9A4D9.3000105@oracle.com> References: <53B9A4D9.3000105@oracle.com> Message-ID: <53BA908C.1040305@oracle.com> Looks good. --Sean On 07/06/2014 03:34 PM, Erik Gahlin wrote: > Hi, > > Could I have a review of a small fix that removes references to jfr from > the package.access list. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8047368 > > Webrev: > http://cr.openjdk.java.net/~egahlin/8047368/ > > Thanks > Erik > From sean.mullan at oracle.com Mon Jul 7 18:00:32 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Jul 2014 14:00:32 -0400 Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL In-Reply-To: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> References: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> Message-ID: <53BAE040.3010307@oracle.com> Looks good, just one comment in GssKrb5Base - I would change getNegotiatedProperty to call the superclass method first, and then if that returns null, check for the gss inquiretype properties. This way you don't check for IllegalStateExc twice, and it seems cleaner to me. Also, please add a release notes label so that this is documented in the release notes, and open a separate docs bug to add a section to the SASL Reference Guide to more fully describe these new properties and how to use them. Thanks, Sean On 07/03/2014 10:30 PM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8044085/webrev.00 > > With this change, all existing (and future) InquireType values for ExtendedGSSContext.inquireSecContext() are available to the SASL GSSAPI mechanism as negotiated properties. > > Code change is in GssKrb5Base.java. Clarification in spec of getNegotiatedProperty() in SaslClient and SaslServer. New lines in an existing test for sanity check. > > Thanks > Max > From kai.zheng at intel.com Fri Jul 4 02:38:53 2014 From: kai.zheng at intel.com (Zheng, Kai) Date: Fri, 4 Jul 2014 02:38:53 +0000 Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL In-Reply-To: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> References: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FA1DE@SHSMSX103.ccr.corp.intel.com> Thanks Max a lot for working on this as such support is highly desired by Hadoop. Regards, Kai -----Original Message----- From: Wang Weijun [mailto:weijun.wang at oracle.com] Sent: Friday, July 04, 2014 10:31 AM To: OpenJDK Dev list Cc: Zheng, Kai Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8044085/webrev.00 With this change, all existing (and future) InquireType values for ExtendedGSSContext.inquireSecContext() are available to the SASL GSSAPI mechanism as negotiated properties. Code change is in GssKrb5Base.java. Clarification in spec of getNegotiatedProperty() in SaslClient and SaslServer. New lines in an existing test for sanity check. Thanks Max From robbiexgibson at yahoo.com Fri Jul 4 08:30:08 2014 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Fri, 4 Jul 2014 01:30:08 -0700 Subject: JI-9013191 Message-ID: <1404462608.7517.YahooMailNeo@web121304.mail.ne1.yahoo.com> Hi, I'm the reporter of JI-9013191 and I just wanted to follow up with some more information, since I can't see or comment on the bug in the OpenJDK JIRA instance.?Hope this is the right place. I'm having problems with JAR files signed and timestamped with JDK9 - they fail validation under JDK7u60.? It looks like this is due to the fact that JDK9 timestamps by default using SHA-256 - but in the JDK 7u tree, AlgorithmId.java is missing a backport of changeset JDK-7180907 which means that SignatureFileVerifier#verifyTimestamp fails since it is looking for an algorithm with the non-standard name SHA256 (without a hyphen). By the way, the bug report talks about Web Start, but the minimal reproducable case is much easier and doesn't involve Web Start: - create a jar with one file in it - sign and timestamp with JDK9 using?default settings - verify with JDK7 -> verification failure "jar is unsigned. (signatures missing or not parsable)" Running the verification with -J-Djava.security.debug=jar gives jar: processEntry: processing block jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256 MessageDigest not available jar: done with meta! jar: nothing to verify! Hope that helps, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Mon Jul 7 19:11:11 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 07 Jul 2014 23:11:11 +0400 Subject: JI-9013191 In-Reply-To: <1404462608.7517.YahooMailNeo@web121304.mail.ne1.yahoo.com> References: <1404462608.7517.YahooMailNeo@web121304.mail.ne1.yahoo.com> Message-ID: <53BAF0CF.1080309@oracle.com> Hi Robert! I copied your update to the report and moved it into JDK project. You should be able to access it now: https://bugs.openjdk.java.net/browse/JDK-8049480 Sincerely yours, Ivan On 04.07.2014 12:30, Robert Gibson wrote: > Hi, > I'm the reporter of JI-9013191 and I just wanted to follow up with > some more information, since I can't see or comment on the bug in the > OpenJDK JIRA instance. Hope this is the right place. > I'm having problems with JAR files signed and timestamped with JDK9 - > they fail validation under JDK7u60. It looks like this is due to the > fact that JDK9 timestamps by default using SHA-256 - but in the JDK 7u > tree, AlgorithmId.java is missing a backport of changeset JDK-7180907 > which means that SignatureFileVerifier#verifyTimestamp fails since it > is looking for an algorithm with the non-standard name SHA256 (without > a hyphen). > By the way, the bug report talks about Web Start, but the minimal > reproducable case is much easier and doesn't involve Web Start: > - create a jar with one file in it > - sign and timestamp with JDK9 using default settings > - verify with JDK7 -> verification failure "jar is unsigned. > (signatures missing or not parsable)" > Running the verification with -J-Djava.security.debug=jar gives > jar: processEntry: processing block > jar: processEntry caught: java.security.NoSuchAlgorithmException: > SHA256 MessageDigest not available > jar: done with meta! > jar: nothing to verify! > Hope that helps, > Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Jul 7 21:14:47 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 07 Jul 2014 14:14:47 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53AC918D.6070308@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> <53AC918D.6070308@oracle.com> Message-ID: <53BB0DC7.6090106@oracle.com> Updated the webrev to include the updates of test policy files. Also changed the ProviderConfig class to ignore provider instantiation failures, so that we don't need to include the entries for crypto providers in the test policy files when the tests themselves do not use/depend on functionality from crypto providers. http://cr.openjdk.java.net/~valeriep/8043406/webrev.02/ Thanks, Valerie On 6/26/2014 2:33 PM, Valerie Peng wrote: > > 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 weijun.wang at oracle.com Tue Jul 8 02:12:01 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 8 Jul 2014 10:12:01 +0800 Subject: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred Message-ID: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> Please review the code change at http://cr.openjdk.java.net/~weijun/8048194/webrev.00 The original code goes on accepting the input mechToken even if it's of an unsupported mech. It also mistakenly interprets the input token as a mech token instead of a NegTokenTarg at the 2nd step. Thanks Max From weijun.wang at oracle.com Tue Jul 8 02:25:51 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 8 Jul 2014 10:25:51 +0800 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges, as possible In-Reply-To: <53BB0DC7.6090106@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> <53AC918D.6070308@oracle.com> <53BB0DC7.6090106@oracle.com> Message-ID: Hi Valerie I didn't read your previous webrevs, but why is "permission java.util.PropertyPermission "*", "read";" needed by every provider? I go to sun/ec, sun/pkcs11, com/sun/crypto and find no special System.getProperty() calls there. Thanks Max On Jul 8, 2014, at 5:14, Valerie Peng wrote: > > Updated the webrev to include the updates of test policy files. > Also changed the ProviderConfig class to ignore provider instantiation failures, so that we don't need to include the entries for crypto providers in the test policy files when the tests themselves do not use/depend on functionality from crypto providers. > > http://cr.openjdk.java.net/~valeriep/8043406/webrev.02/ > > Thanks, > Valerie From 1983-01-06 at gmx.net Tue Jul 8 09:20:19 2014 From: 1983-01-06 at gmx.net (Michael-O) Date: Tue, 8 Jul 2014 11:20:19 +0200 Subject: RFR 8014870: Faster KDC availability check in Kerberos Message-ID: Hi Max, are you going to backport this to Java 7? We are suffering from this on a regular basis because several KDCs are faulty returned by DNS SRVs. 30 s is not acceptable. Moreover, why is the property krb5.kdc.bad.policy not documented publically? Thanks, Michael From weijun.wang at oracle.com Tue Jul 8 09:27:56 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 8 Jul 2014 17:27:56 +0800 Subject: RFR 8014870: Faster KDC availability check in Kerberos In-Reply-To: References: Message-ID: <747330C5-A8C3-4D19-9924-B426A8601466@oracle.com> On Jul 8, 2014, at 17:20, Michael-O <1983-01-06 at gmx.net> wrote: > Hi Max, > > are you going to backport this to Java 7? I would be glad to do that. But now I still cannot find anyone code reviewing it for JDK 9. > We are suffering from this on a regular basis because several KDCs are faulty returned by DNS SRVs. 30 s is not acceptable. Moreover, why is the property krb5.kdc.bad.policy not documented publicly? Sorry, we didn't have a good place to document krb5-related things. The Java SE document always focuses on GSS-API. I think it was mentioned in release notes of JDK 7. We have http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-api-mechanism.html now and hopefully we can put some useful information there. Thanks Max > > Thanks, > > Michael From xuelei.fan at oracle.com Tue Jul 8 12:40:39 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 08 Jul 2014 20:40:39 +0800 Subject: RFR 8014870: Faster KDC availability check in Kerberos In-Reply-To: <53BA086A.5040004@oracle.com> References: <17D2CB8C-001B-4929-8BD8-956ADF1E97DE@oracle.com> <53BA086A.5040004@oracle.com> Message-ID: <53BBE6C7.60507@oracle.com> Missed the security-dev list. On 7/7/2014 10:39 AM, Xuelei Fan wrote: > I have not read the fix. I was just wondering that this fix save the > wait time, but increase the networking traffics, and increase the > workload of KDC servers. I think the KDC timeout should be corner cases > for TCP, and it is tolerable for UDP connections. I'm not confident > that this is a cost-effective update if we considering the overall > system of Kerberos. > > Xuelei > > On 6/24/2014 4:17 PM, Wang Weijun wrote: >> 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 sean.mullan at oracle.com Tue Jul 8 13:15:34 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Jul 2014 09:15:34 -0400 Subject: RFR: JDK-8049244: XML Signature performance issue caused by unbuffered signature data Message-ID: <53BBEEF6.2010100@oracle.com> Please review my fix for JDK-8049244: http://cr.openjdk.java.net/~mullan/webrevs/8049244/webrev.00/ This is a direct port of the corresponding fix from Apache Santuario. No regression test since this is a performance related fix. However, the customer that reported this to the Apache Santuario project has already tested the patch and confirmed that it fixes the issue. Thanks, Sean From xuelei.fan at oracle.com Tue Jul 8 14:03:15 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 08 Jul 2014 22:03:15 +0800 Subject: RFR: JDK-8049244: XML Signature performance issue caused by unbuffered signature data In-Reply-To: <53BBEEF6.2010100@oracle.com> References: <53BBEEF6.2010100@oracle.com> Message-ID: <53BBFA23.4030306@oracle.com> Looks fine to me. The old code looks a little bit hard to understand to me. Xuelei On 7/8/2014 9:15 PM, Sean Mullan wrote: > Please review my fix for JDK-8049244: > > http://cr.openjdk.java.net/~mullan/webrevs/8049244/webrev.00/ > > This is a direct port of the corresponding fix from Apache Santuario. No > regression test since this is a performance related fix. However, the > customer that reported this to the Apache Santuario project has already > tested the patch and confirmed that it fixes the issue. > > Thanks, > Sean > From weijun.wang at oracle.com Tue Jul 8 14:22:08 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 8 Jul 2014 22:22:08 +0800 Subject: RFR 8014870: Faster KDC availability check in Kerberos In-Reply-To: <53BBE6C7.60507@oracle.com> References: <17D2CB8C-001B-4929-8BD8-956ADF1E97DE@oracle.com> <53BA086A.5040004@oracle.com> <53BBE6C7.60507@oracle.com> Message-ID: If the first UDP response can be back in a second then there is no extra workload. This should be the most common case since Kerberos is usually used in an enterprise environment with a high network speed. In most cases, the re-sent of a request is due to failed KDCs or even false settings which would wait forever. You are right that it's not necessary to retry TCP. I will apply the max_retries parameter to UDP only. Thanks Max On Jul 8, 2014, at 20:40, Xuelei Fan wrote: > Missed the security-dev list. > > On 7/7/2014 10:39 AM, Xuelei Fan wrote: >> I have not read the fix. I was just wondering that this fix save the >> wait time, but increase the networking traffics, and increase the >> workload of KDC servers. I think the KDC timeout should be corner cases >> for TCP, and it is tolerable for UDP connections. I'm not confident >> that this is a cost-effective update if we considering the overall >> system of Kerberos. >> >> Xuelei >> >> On 6/24/2014 4:17 PM, Wang Weijun wrote: >>> Hi All >>> >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8014870/webrev.00/ >>> From weijun.wang at oracle.com Tue Jul 8 14:37:03 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 8 Jul 2014 22:37:03 +0800 Subject: RFR 8049480: Current versions of Java can't verify jars signed and timestamped with Java 9 Message-ID: Please review the jdk7u-only code change at http://cr.openjdk.java.net/~weijun/8049480/webrev.00/ The reason is that the jdk7u version [1] of fix for JDK-8049480 is just a hack and not as powerful as its jdk8 sibling [2] and now I'll have to apply the jdk7u jar signature "hack" to timestamp signature again. I did a find usage on Algorithm.getName() and other cases are not impacted by the name difference. Thanks Max [1] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/c399756623cb [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5dc3f32c0d26 From michael.x.mcmahon at oracle.com Tue Jul 8 14:58:23 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 08 Jul 2014 15:58:23 +0100 Subject: RFR 7150092: NTLM authentication fail if user specified a different realm In-Reply-To: References: <4C46F4A8-4CCB-4075-B594-FA9B51C2F692@oracle.com> Message-ID: <53BC070F.6050909@oracle.com> Max, These changes look fine. Just a couple of minor comments: L130 in Client.java appears to be superfluous now. The comment at L186 in Server.java might probably should be removed or else expanded upon. Thanks Michael On 23/06/14 09:09, Wang Weijun wrote: > 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 xuelei.fan at oracle.com Tue Jul 8 15:15:29 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 08 Jul 2014 23:15:29 +0800 Subject: RFR 8049480: Current versions of Java can't verify jars signed and timestamped with Java 9 In-Reply-To: References: Message-ID: <53BC0B11.1040409@oracle.com> Looks fine to me. It would be nice to extend AlgorithmId.getStandardDigestName() to AlgorithmId.getStandardName() in the future. Xuelei On 7/8/2014 10:37 PM, Wang Weijun wrote: > Please review the jdk7u-only code change at > > http://cr.openjdk.java.net/~weijun/8049480/webrev.00/ > > The reason is that the jdk7u version [1] of fix for JDK-8049480 is just a hack and not as powerful as its jdk8 sibling [2] and now I'll have to apply the jdk7u jar signature "hack" to timestamp signature again. > > I did a find usage on Algorithm.getName() and other cases are not impacted by the name difference. > > Thanks > Max > > [1] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/c399756623cb > [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5dc3f32c0d26 > From sean.mullan at oracle.com Tue Jul 8 16:45:48 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Jul 2014 12:45:48 -0400 Subject: RFR 8049480: Current versions of Java can't verify jars signed and timestamped with Java 9 In-Reply-To: References: Message-ID: <53BC203C.3060107@oracle.com> On 07/08/2014 10:37 AM, Wang Weijun wrote: > Please review the jdk7u-only code change at > > http://cr.openjdk.java.net/~weijun/8049480/webrev.00/ > > The reason is that the jdk7u version [1] of fix for JDK-8049480 is just a hack and not as powerful as its jdk8 sibling [2] and now I'll have to apply the jdk7u jar signature "hack" to timestamp signature again. > > I did a find usage on Algorithm.getName() and other cases are not impacted by the name difference. In the test, you should close the InputStream before finishing. Also, it would be nice to change OAEPParameters to call AlgorithmId.getStandardDigestName and remove the duplicate method. Looks fine otherwise. --Sean > > Thanks > Max > > [1] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/c399756623cb > [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5dc3f32c0d26 > From sean.coffey at oracle.com Tue Jul 8 17:22:12 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 08 Jul 2014 18:22:12 +0100 Subject: RFR: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert Message-ID: <53BC28C4.7010202@oracle.com> Looking to backport this fix to the JDK 7u code line. The code was refactored in JDK 8 but the change is still easily applied. No issues with JPRT test run. bug ID: https://bugs.openjdk.java.net/browse/JDK-8021804 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8021804.7u/webrev/ JDK 8 changeset : http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/eafce9a617ee regards, Sean. From sean.mullan at oracle.com Tue Jul 8 17:33:30 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Jul 2014 13:33:30 -0400 Subject: RFR: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert In-Reply-To: <53BC28C4.7010202@oracle.com> References: <53BC28C4.7010202@oracle.com> Message-ID: <53BC2B6A.2020102@oracle.com> Looks good to me. --Sean On 07/08/2014 01:22 PM, Se?n Coffey wrote: > Looking to backport this fix to the JDK 7u code line. The code was > refactored in JDK 8 but the change is still easily applied. > No issues with JPRT test run. > > bug ID: https://bugs.openjdk.java.net/browse/JDK-8021804 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8021804.7u/webrev/ > JDK 8 changeset : > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/eafce9a617ee > > regards, > Sean. From valerie.peng at oracle.com Tue Jul 8 18:26:09 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 08 Jul 2014 11:26:09 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> <53AC918D.6070308@oracle.com> <53BB0DC7.6090106@oracle.com> Message-ID: <53BC37C1.3070508@oracle.com> When looking through the code and running regression tests as well as some of my own sample programs, SunPKCS11 needs permission to access "sun.security.pkcs11.allowSingleThreadedModules" property. As for other providers, they seem fine without the PropertyPermission. But the required permissions depend on the code path at runtime, so it's hard to tell 100%. Since default permission set contains a bunch of PropertyPermission, it seems reasonable to grant a "*" PropertyPermission to crypto providers by default (in case future enhancements/fixes contains code which needs them). Besides, other jars under extension directory (e.g. zipfs.jar, cldrdata.jar) do so too. Regards, Valerie On 7/7/2014 7:25 PM, Wang Weijun wrote: > Hi Valerie > > I didn't read your previous webrevs, but why is "permission java.util.PropertyPermission "*", "read";" needed by every provider? I go to sun/ec, sun/pkcs11, com/sun/crypto and find no special System.getProperty() calls there. > > Thanks > Max > > > On Jul 8, 2014, at 5:14, Valerie Peng wrote: > >> Updated the webrev to include the updates of test policy files. >> Also changed the ProviderConfig class to ignore provider instantiation failures, so that we don't need to include the entries for crypto providers in the test policy files when the tests themselves do not use/depend on functionality from crypto providers. >> >> http://cr.openjdk.java.net/~valeriep/8043406/webrev.02/ >> >> Thanks, >> Valerie From sean.mullan at oracle.com Tue Jul 8 19:21:22 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Jul 2014 15:21:22 -0400 Subject: RFR 8043071: Expose session key and KRB_CRED through extended GSS-API In-Reply-To: <62344483-E9E6-4FA9-B3AA-F7099DC48192@oracle.com> References: <62344483-E9E6-4FA9-B3AA-F7099DC48192@oracle.com> Message-ID: <53BC44B2.4020406@oracle.com> Hi Max, Here are my comments: * KerberosKey 37: Did you mean to use @link instead of @see? - several methods are now defined to throw IllegalStateExc, but you (perhaps accidentally) removed the code that does that (ex: getKeyType). * KerberosTicket 352-3: put braces around the if (destroyed) statement; same comment applies in rest of code. * Krb5Context 1446-9: can myName or peerName be null? * Context 451: I think you should also print the exception * KerberosCredMessage 52-4: these fields should be private - is there a reason why you didn't override hashCode/equals? * KerberosSessionKey - methods don't need to be final since class is - some of the methods don't check if it is destroyed (ex: getKeyType) - I think it would actually be better to name this class EncryptionKey since that is what it is and that way we would be able to reuse this type in the future if necessary for other structures or APIs that reference this type (EncryptionKey) --Sean On 07/04/2014 02:12 AM, Wang Weijun wrote: > Hi All > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8043071/webrev.00/ > > Two new inquire type KRB5_GET_SESSION_KEY_EX and KRB5_GET_KRB_CRED are added to get the session key (in a new format) and the KRB_CRED message. Two new classes are created as the types of their return values. > > Spec for InquireType values are moved into the InquireType class itself. > > For the existing KerberosKey class, the "A call to any of its other methods after this will cause an IllegalStateException to be thrown" in the spec of destroy() is not precise since we know isDestroyed() and toString/hashCode/equals() do not throw it. The sentence is removed and a @throws clause is added to those methods that do throw the exception. The new KerberosSessionKey and KerberosCredMessage have the same style. > > Since the data class KeyImpl already throws IllegalStateException when it's destroyed, KerberosKey and KerberosSessionKey do not check again. If you think this makes the code difficult to read, I can add them back. > > Thanks > Max > From sean.mullan at oracle.com Tue Jul 8 21:19:37 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Jul 2014 17:19:37 -0400 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53BB0DC7.6090106@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> <53AC918D.6070308@oracle.com> <53BB0DC7.6090106@oracle.com> Message-ID: <53BC6069.4020608@oracle.com> Looks good, although do you know why you were able to remove the grant AllPermission from so many of the test policy files without granting additional specific permissions? --Sean On 07/07/2014 05:14 PM, Valerie Peng wrote: > > Updated the webrev to include the updates of test policy files. > Also changed the ProviderConfig class to ignore provider instantiation > failures, so that we don't need to include the entries for crypto > providers in the test policy files when the tests themselves do not > use/depend on functionality from crypto providers. > > http://cr.openjdk.java.net/~valeriep/8043406/webrev.02/ > > Thanks, > Valerie > > On 6/26/2014 2:33 PM, Valerie Peng wrote: >> >> 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 Tue Jul 8 21:33:13 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 08 Jul 2014 14:33:13 -0700 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53BC6069.4020608@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> <53AC918D.6070308@oracle.com> <53BB0DC7.6090106@oracle.com> <53BC6069.4020608@oracle.com> Message-ID: <53BC6399.60404@oracle.com> I modified the ProviderConfig class to skip providers when the corresponding provider class failed during initiation time (e.g. lacking certain permission). Thus, for tests which do not need/use crypto providers, their test policy don't have to contain the entries for crypto providers. Thanks, Valerie On 7/8/2014 2:19 PM, Sean Mullan wrote: > Looks good, although do you know why you were able to remove the grant > AllPermission from so many of the test policy files without granting > additional specific permissions? > > --Sean > > On 07/07/2014 05:14 PM, Valerie Peng wrote: >> >> Updated the webrev to include the updates of test policy files. >> Also changed the ProviderConfig class to ignore provider instantiation >> failures, so that we don't need to include the entries for crypto >> providers in the test policy files when the tests themselves do not >> use/depend on functionality from crypto providers. >> >> http://cr.openjdk.java.net/~valeriep/8043406/webrev.02/ >> >> Thanks, >> Valerie >> >> On 6/26/2014 2:33 PM, Valerie Peng wrote: >>> >>> 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 sean.mullan at oracle.com Wed Jul 9 01:27:38 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Jul 2014 21:27:38 -0400 Subject: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible In-Reply-To: <53BC6399.60404@oracle.com> References: <53A21802.7040209@oracle.com> <53A45767.1090602@oracle.com> <53A4B614.90900@oracle.com> <53AC918D.6070308@oracle.com> <53BB0DC7.6090106@oracle.com> <53BC6069.4020608@oracle.com> <53BC6399.60404@oracle.com> Message-ID: <53BC9A8A.9050508@oracle.com> On 7/8/14, 5:33 PM, Valerie Peng wrote: > > I modified the ProviderConfig class to skip providers when the > corresponding provider class failed during initiation time (e.g. lacking > certain permission). Thus, for tests which do not need/use crypto > providers, their test policy don't have to contain the entries for > crypto providers. Ok, thanks for the explanation, that sounds good to me. --Sean > > Thanks, > Valerie > > On 7/8/2014 2:19 PM, Sean Mullan wrote: >> Looks good, although do you know why you were able to remove the grant >> AllPermission from so many of the test policy files without granting >> additional specific permissions? >> >> --Sean >> >> On 07/07/2014 05:14 PM, Valerie Peng wrote: >>> >>> Updated the webrev to include the updates of test policy files. >>> Also changed the ProviderConfig class to ignore provider instantiation >>> failures, so that we don't need to include the entries for crypto >>> providers in the test policy files when the tests themselves do not >>> use/depend on functionality from crypto providers. >>> >>> http://cr.openjdk.java.net/~valeriep/8043406/webrev.02/ >>> >>> Thanks, >>> Valerie >>> >>> On 6/26/2014 2:33 PM, Valerie Peng wrote: >>>> >>>> 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 weijun.wang at oracle.com Wed Jul 9 04:31:12 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 9 Jul 2014 12:31:12 +0800 Subject: RFR 8049480: Current versions of Java can't verify jars signed and timestamped with Java 9 In-Reply-To: <53BC203C.3060107@oracle.com> References: <53BC203C.3060107@oracle.com> Message-ID: <4FDD1F4B-3FB1-4BF4-AABE-2789777C070D@oracle.com> Webrev updated at phttp://cr.openjdk.java.net/~weijun/8049480/webrev.01/. Thanks Max On Jul 9, 2014, at 0:45, Sean Mullan wrote: > On 07/08/2014 10:37 AM, Wang Weijun wrote: >> Please review the jdk7u-only code change at >> >> http://cr.openjdk.java.net/~weijun/8049480/webrev.00/ >> >> The reason is that the jdk7u version [1] of fix for JDK-8049480 is just a hack and not as powerful as its jdk8 sibling [2] and now I'll have to apply the jdk7u jar signature "hack" to timestamp signature again. >> >> I did a find usage on Algorithm.getName() and other cases are not impacted by the name difference. > > In the test, you should close the InputStream before finishing. Also, it would be nice to change OAEPParameters to call AlgorithmId.getStandardDigestName and remove the duplicate method. Looks fine otherwise. > > --Sean > >> >> Thanks >> Max >> >> [1] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/c399756623cb >> [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5dc3f32c0d26 >> From weijun.wang at oracle.com Wed Jul 9 04:37:46 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 9 Jul 2014 12:37:46 +0800 Subject: RFR 8049480: Current versions of Java can't verify jars signed and timestamped with Java 9 In-Reply-To: <53BC0B11.1040409@oracle.com> References: <53BC0B11.1040409@oracle.com> Message-ID: <8A3D3E4A-CCE1-4D52-AED6-BCE419B1BD58@oracle.com> On Jul 8, 2014, at 23:15, Xuelei Fan wrote: > Looks fine to me. > > It would be nice to extend AlgorithmId.getStandardDigestName() to > AlgorithmId.getStandardName() in the future. The JDK8 version of fix for 7180907 already had AlgorithmId.getName() returning the standard one. --Max > > Xuelei > > On 7/8/2014 10:37 PM, Wang Weijun wrote: >> Please review the jdk7u-only code change at >> >> http://cr.openjdk.java.net/~weijun/8049480/webrev.00/ >> >> The reason is that the jdk7u version [1] of fix for JDK-7180907 is just a hack and not as powerful as its jdk8 sibling [2] and now I'll have to apply the jdk7u jar signature "hack" to timestamp signature again. >> >> I did a find usage on Algorithm.getName() and other cases are not impacted by the name difference. >> >> Thanks >> Max >> >> [1] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/c399756623cb >> [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5dc3f32c0d26 >> > From weijun.wang at oracle.com Wed Jul 9 08:31:54 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 9 Jul 2014 16:31:54 +0800 Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL In-Reply-To: <53BAE040.3010307@oracle.com> References: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> <53BAE040.3010307@oracle.com> Message-ID: <063546F3-53D1-4783-803C-AA71F0AB9ADE@oracle.com> On Jul 8, 2014, at 2:00, Sean Mullan wrote: > Looks good, just one comment in GssKrb5Base - I would change getNegotiatedProperty to call the superclass method first, and then if that returns null, check for the gss inquiretype properties. This way you don't check for IllegalStateExc twice, and it seems cleaner to me. My understanding is that if getNegotiatedProperty() methods of both parent class and child class return non-null, then the value from the child class should shadow the one from the parent. > > Also, please add a release notes label so that this is documented in the release notes, and open a separate docs bug to add a section to the SASL Reference Guide to more fully describe these new properties and how to use them. Sure. Thanks Max >> http://cr.openjdk.java.net/~weijun/8044085/webrev.00 >> From weijun.wang at oracle.com Wed Jul 9 09:29:55 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 9 Jul 2014 17:29:55 +0800 Subject: RFR 8043071: Expose session key and KRB_CRED through extended GSS-API In-Reply-To: <53BC44B2.4020406@oracle.com> References: <62344483-E9E6-4FA9-B3AA-F7099DC48192@oracle.com> <53BC44B2.4020406@oracle.com> Message-ID: <0E051012-E0F7-42A4-A847-67209C908C7F@oracle.com> On Jul 9, 2014, at 3:21, Sean Mullan wrote: > Hi Max, > > Here are my comments: > > * KerberosKey > > 37: Did you mean to use @link instead of @see? Yes. > > - several methods are now defined to throw IllegalStateExc, but you (perhaps accidentally) removed the code that does that (ex: getKeyType). That's because KeyImpl.getKeyType() already throws it. I mentioned it in that last paragraph of my previous mail. If you think it makes the code more difficult to read, I'll add them back. > > * KerberosTicket > > 352-3: put braces around the if (destroyed) statement; same comment applies in rest of code. There are quite some single line block without braces in this file (see init()). My habit was if I don't touch the part I will not change it. Some people believe whenever a file is touched it's better to update all appearances of such codes. If you think this is good I'll update all of them. > > * Krb5Context > > 1446-9: can myName or peerName be null? No. They won't be null after a context is established. There exists something called Anonymous Kerberos (we don't support it) but in this case there is no KRB_CRED to send. > > * Context > > 451: I think you should also print the exception OK. > > * KerberosCredMessage > > 52-4: these fields should be private Absolutely correct. > > - is there a reason why you didn't override hashCode/equals? I don't think it's likely for someone to put several KerberosCredMessage into a set (which is where I think hashCode/equals is useful). Maybe it's a good habit to always verride hashCode/equals for these "data" classes? > > * KerberosSessionKey > > - methods don't need to be final since class is OK. > - some of the methods don't check if it is destroyed (ex: getKeyType) See above (KerberosKey). > > - I think it would actually be better to name this class EncryptionKey since that is what it is and that way we would be able to reuse this type in the future if necessary for other structures or APIs that reference this type (EncryptionKey) This makes sense. I'll withdraw CCC and resubmit it. Thanks Max > > --Sean > > On 07/04/2014 02:12 AM, Wang Weijun wrote: >> Hi All >> >> Please review the change at >> >> http://cr.openjdk.java.net/~weijun/8043071/webrev.00/ >> >> Two new inquire type KRB5_GET_SESSION_KEY_EX and KRB5_GET_KRB_CRED are added to get the session key (in a new format) and the KRB_CRED message. Two new classes are created as the types of their return values. >> >> Spec for InquireType values are moved into the InquireType class itself. >> >> For the existing KerberosKey class, the "A call to any of its other methods after this will cause an IllegalStateException to be thrown" in the spec of destroy() is not precise since we know isDestroyed() and toString/hashCode/equals() do not throw it. The sentence is removed and a @throws clause is added to those methods that do throw the exception. The new KerberosSessionKey and KerberosCredMessage have the same style. >> >> Since the data class KeyImpl already throws IllegalStateException when it's destroyed, KerberosKey and KerberosSessionKey do not check again. If you think this makes the code difficult to read, I can add them back. >> >> Thanks >> Max >> From sean.mullan at oracle.com Wed Jul 9 12:00:20 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 09 Jul 2014 08:00:20 -0400 Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL In-Reply-To: <063546F3-53D1-4783-803C-AA71F0AB9ADE@oracle.com> References: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> <53BAE040.3010307@oracle.com> <063546F3-53D1-4783-803C-AA71F0AB9ADE@oracle.com> Message-ID: <53BD2ED4.6050107@oracle.com> On 07/09/2014 04:31 AM, Wang Weijun wrote: > > On Jul 8, 2014, at 2:00, Sean Mullan wrote: > >> Looks good, just one comment in GssKrb5Base - I would change >> getNegotiatedProperty to call the superclass method first, and then >> if that returns null, check for the gss inquiretype properties. >> This way you don't check for IllegalStateExc twice, and it seems >> cleaner to me. > > My understanding is that if getNegotiatedProperty() methods of both > parent class and child class return non-null, then the value from the > child class should shadow the one from the parent. That behavior is unspecified as far as I can see. In any case, if you choose that behavior, you could still call the superclass first and then override if necessary. --Sean > >> >> Also, please add a release notes label so that this is documented >> in the release notes, and open a separate docs bug to add a section >> to the SASL Reference Guide to more fully describe these new >> properties and how to use them. > > Sure. > > Thanks Max > >>> http://cr.openjdk.java.net/~weijun/8044085/webrev.00 >>> > From weijun.wang at oracle.com Wed Jul 9 14:02:00 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 9 Jul 2014 22:02:00 +0800 Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL In-Reply-To: <53BD2ED4.6050107@oracle.com> References: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> <53BAE040.3010307@oracle.com> <063546F3-53D1-4783-803C-AA71F0AB9ADE@oracle.com> <53BD2ED4.6050107@oracle.com> Message-ID: On Jul 9, 2014, at 20:00, Sean Mullan wrote: >>> Looks good, just one comment in GssKrb5Base - I would change >>> getNegotiatedProperty to call the superclass method first, and then >>> if that returns null, check for the gss inquiretype properties. >>> This way you don't check for IllegalStateExc twice, and it seems >>> cleaner to me. >> >> My understanding is that if getNegotiatedProperty() methods of both >> parent class and child class return non-null, then the value from the >> child class should shadow the one from the parent. > > That behavior is unspecified as far as I can see. In any case, if you choose that behavior, you could still call the superclass first and then override if necessary. It is unspecified because the SASL API has not assigned any default value for getNegotiatedProperty() in SaslClient and SaslServer classes, and it's our implementation that defines AbstractSaslImpl and GssKrb5Base, and both have getNegotiatedProperty(). I choose child class shadowing the parent not only because it looks natural but also the other subclasses of AbstractSaslImpl (DigestMD5Base) does the same. Now, if I call the super class method first, it means if the name is really defined in both classes, codes in both sides will be executed and it's a negative performance impact. If we call child class first, "if (!completed)" is checked twice but its impact is much lighter. --Max From sean.mullan at oracle.com Wed Jul 9 19:59:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 09 Jul 2014 15:59:18 -0400 Subject: RFR 8043071: Expose session key and KRB_CRED through extended GSS-API In-Reply-To: <0E051012-E0F7-42A4-A847-67209C908C7F@oracle.com> References: <62344483-E9E6-4FA9-B3AA-F7099DC48192@oracle.com> <53BC44B2.4020406@oracle.com> <0E051012-E0F7-42A4-A847-67209C908C7F@oracle.com> Message-ID: <53BD9F16.3090704@oracle.com> On 07/09/2014 05:29 AM, Wang Weijun wrote: > > On Jul 9, 2014, at 3:21, Sean Mullan wrote: > >> - several methods are now defined to throw IllegalStateExc, but you >> (perhaps accidentally) removed the code that does that (ex: >> getKeyType). > > That's because KeyImpl.getKeyType() already throws it. I mentioned it > in that last paragraph of my previous mail. If you think it makes the > code more difficult to read, I'll add them back. No, you don't have to add them back, but if you could add a comment to each method indicating that the check for IllegalStateExc is in the KeyImpl method, it would help. >> * KerberosTicket >> >> 352-3: put braces around the if (destroyed) statement; same comment >> applies in rest of code. > > There are quite some single line block without braces in this file > (see init()). My habit was if I don't touch the part I will not > change it. Some people believe whenever a file is touched it's better > to update all appearances of such codes. If you think this is good > I'll update all of them. Missing braces can more easily lead to inadvertant security bugs. Because the destroyed block is security related, I think you should at least fix those, but if you want to fix all of them to be consistent, that is fine too. >> * KerberosCredMessage >> >> - is there a reason why you didn't override hashCode/equals? > > I don't think it's likely for someone to put several > KerberosCredMessage into a set (which is where I think > hashCode/equals is useful). Maybe it's a good habit to always verride > hashCode/equals for these "data" classes? If you think there is a chance it could be useful, I think it is better to do it now than later. In particular, it should be very easy to implement, so I would probably do it. >> - I think it would actually be better to name this class >> EncryptionKey since that is what it is and that way we would be >> able to reuse this type in the future if necessary for other >> structures or APIs that reference this type (EncryptionKey) > > This makes sense. I'll withdraw CCC and resubmit it. Great. Thanks, Sean From sean.mullan at oracle.com Wed Jul 9 20:46:46 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 09 Jul 2014 16:46:46 -0400 Subject: RFR 8049480: Current versions of Java can't verify jars signed and timestamped with Java 9 In-Reply-To: <4FDD1F4B-3FB1-4BF4-AABE-2789777C070D@oracle.com> References: <53BC203C.3060107@oracle.com> <4FDD1F4B-3FB1-4BF4-AABE-2789777C070D@oracle.com> Message-ID: <53BDAA36.10409@oracle.com> On 07/09/2014 12:31 AM, Wang Weijun wrote: > Webrev updated at http://cr.openjdk.java.net/~weijun/8049480/webrev.01/. Looks good to me. --Sean From sean.mullan at oracle.com Wed Jul 9 21:52:23 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 09 Jul 2014 17:52:23 -0400 Subject: RFR 8044085: Access ExtendedGSSContext.inquireSecContext() result through SASL In-Reply-To: References: <665CA3B7-2321-4A3B-86ED-4D9423926FCB@oracle.com> <53BAE040.3010307@oracle.com> <063546F3-53D1-4783-803C-AA71F0AB9ADE@oracle.com> <53BD2ED4.6050107@oracle.com> Message-ID: <53BDB997.8090005@oracle.com> On 07/09/2014 10:02 AM, Wang Weijun wrote: > > On Jul 9, 2014, at 20:00, Sean Mullan wrote: > >>>> Looks good, just one comment in GssKrb5Base - I would change >>>> getNegotiatedProperty to call the superclass method first, and then >>>> if that returns null, check for the gss inquiretype properties. >>>> This way you don't check for IllegalStateExc twice, and it seems >>>> cleaner to me. >>> >>> My understanding is that if getNegotiatedProperty() methods of both >>> parent class and child class return non-null, then the value from the >>> child class should shadow the one from the parent. >> >> That behavior is unspecified as far as I can see. In any case, if you choose that behavior, you could still call the superclass first and then override if necessary. > > It is unspecified because the SASL API has not assigned any default value for getNegotiatedProperty() in SaslClient and SaslServer classes, and it's our implementation that defines AbstractSaslImpl and GssKrb5Base, and both have getNegotiatedProperty(). I choose child class shadowing the parent not only because it looks natural but also the other subclasses of AbstractSaslImpl (DigestMD5Base) does the same. > > Now, if I call the super class method first, it means if the name is really defined in both classes, codes in both sides will be executed and it's a negative performance impact. If we call child class first, "if (!completed)" is checked twice but its impact is much lighter. This seems kind of odd though in that an abstract superclass might have properties with the same name when these are specific to the GSS/KRB5 subclass. Anyway, this was mostly a minor comment, whatever you decide here is ok. --Sean From weijun.wang at oracle.com Thu Jul 10 05:59:48 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 10 Jul 2014 13:59:48 +0800 Subject: RFR 8043071: Expose session key and KRB_CRED through extended GSS-API In-Reply-To: <53BD9F16.3090704@oracle.com> References: <62344483-E9E6-4FA9-B3AA-F7099DC48192@oracle.com> <53BC44B2.4020406@oracle.com> <0E051012-E0F7-42A4-A847-67209C908C7F@oracle.com> <53BD9F16.3090704@oracle.com> Message-ID: <03ED7B0D-5503-4A72-A5D2-71A8F47702B2@oracle.com> Updated webrev at http://cr.openjdk.java.net/~weijun/8043071/webrev.01/ All your suggestions accepted, plus - New test on new classes added into KerberosHashEqualsTest.java - A duplicate test/sun/security/krb5/auto/KerberosHashEqualsTest.java removed - I don't know why KerberosKey allows a null principal, but anyway update its toString() to avoid NPE - KerberosTicket.toString() now returns "Destroyed KerberosTicket" instead of throwing an ISE, to be consistent with other classes Thanks Max From weijun.wang at oracle.com Thu Jul 10 08:36:51 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 10 Jul 2014 16:36:51 +0800 Subject: RFR 8049834: Two security tools tests do not run with only JRE Message-ID: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8049834/webrev.00/ These 2 tests do not run with only JRE because they are testing on jarsigner. The weaksize.sh is simply moved to jarsigner, and default_options.sh broken into 2 parts with the jarsigner part going to jarsigner. After this change, I can safely run jtreg -compilejdk:../build/macosx-x86_64-normal-server-fastdebug/images/j2sdk-image/ -jdk:../build/macosx-x86_64-normal-server-fastdebug/images/j2re-image/ test/sun/security/tools/keytool/default_options.sh Thanks Max From weijun.wang at oracle.com Fri Jul 11 00:41:56 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 11 Jul 2014 08:41:56 +0800 Subject: RFR 8049936: Update the CheckBlacklistedCerts.java test to find new location of blacklisted.certs.pem Message-ID: <69C52BCE-60CA-4B53-811D-3B00C51CD384@oracle.com> Please review the code change at http://cr.openjdk.java.net/~weijun/8049936/webrev.00/ blacklisted.certs.pem was moved from src/ to make/ in JDK-8047765. The test should also be updated. Thanks Max From xuelei.fan at oracle.com Fri Jul 11 01:10:51 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Jul 2014 09:10:51 +0800 Subject: RFR 8049936: Update the CheckBlacklistedCerts.java test to find new location of blacklisted.certs.pem In-Reply-To: <69C52BCE-60CA-4B53-811D-3B00C51CD384@oracle.com> References: <69C52BCE-60CA-4B53-811D-3B00C51CD384@oracle.com> Message-ID: <53BF399B.9020303@oracle.com> Looks fine to me. Xuelei On 7/11/2014 8:41 AM, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8049936/webrev.00/ > > blacklisted.certs.pem was moved from src/ to make/ in JDK-8047765. The test should also be updated. > > Thanks > Max > From peter.firmstone at zeus.net.au Fri Jul 11 03:00:18 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 11 Jul 2014 13:00:18 +1000 Subject: Concurrent Policy provider Message-ID: <53BF5342.2030801@zeus.net.au> Would there be interest in using a Policy provider and SecurityManager designed for concurrency in Java 9? Some of the issues experienced and solutions are mentioned below. http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/security/ Regards, Peter. -------- Original Message -------- Subject: Concurrency-interest Digest, Vol 113, Issue 45 Date: Mon, 30 Jun 2014 12:00:01 -0400 From: concurrency-interest-request at cs.oswego.edu Reply-To: concurrency-interest at cs.oswego.edu To: concurrency-interest at cs.oswego.edu Send Concurrency-interest mailing list submissions to concurrency-interest at cs.oswego.edu To subscribe or unsubscribe via the World Wide Web, visit http://cs.oswego.edu/mailman/listinfo/concurrency-interest or, via email, send a message with subject or body 'help' to concurrency-interest-request at cs.oswego.edu You can reach the person managing the list at concurrency-interest-owner at cs.oswego.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of Concurrency-interest digest..." Today's Topics: 1. Re: ThreadLocalRandom clinit troubles (Peter Firmstone) 2. Re: ThreadLocalRandom clinit troubles (Alan Bateman) ---------------------------------------------------------------------- Message: 1 Date: Mon, 30 Jun 2014 20:02:30 +1000 From: Peter Firmstone To: Peter Levart Cc: concurrency-interest at cs.oswego.edu Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles Message-ID:<53B135B6.1030105 at zeus.net.au> Content-Type: text/plain; charset=UTF-8; format=flowed Hi Peter, There are a number of bottlenecks throughout the security infrastructure, we have reimplemented it as follows to avoid them and have also addressed some long standing issues: SecurityManager - cache previously checked AccessControlContext's (using a cache structure based on Cliff Click's non blocking hash map and Doug Lee's concurrent skip list set), to avoid repeately calling the policy provider (for example, you have numerous tasks in an ExecutorService and each has an identical AccessControlContext and all tasks cause a SocketPermission check). Policy provider - replaced the built in Java policy provider. The built in Java Policy provider will hold a lock while making DNS calls, bringing all permission checks to a grinding halt. It will also hold locks while accessing the file system. To avoid making DNS calls we've implemented our own policy provider, originated from Apache Harmony, but modified to use non blocking immutability. It creates PermissionCollection's on demand, they're not shared among threads and are ordered in the most favourable order for a fast result. It also supports undocumented Java file policy provider functionality. Because Permission objects are immutable but lazily initialized, we call getActions() to ensure their state is completely initialized prior to publication. The policy provider uses a strictly RFC 3986 compliant immutable URI class, it performs bit shift operations on ASCII strings during normalisation and is used by the policy provider to avoid making DNS calls when checking CodeBase policy file permissions. As a result, the cost of the security infrastructure is less than 1% of CPU load during stress tests. This is part of the Apache River project, JERI (Jini Extensible Remote Invocation) performs remote method invocations as tasks running in a system threadpool, each task executes concurrently on any exported service. SecureClassLoader uses CodeSource's as keys in a Map, CodeSource uses URL in equals() and hashCode(), so we also have a RFC3986 compliant URLClassLoader to avoid making unnecessary DNS calls in SecureClassLoader. Rather than rely on an external untrusted DNS to determine the identity of CodeSource's, we use RFC 3986 compliant normalisation, without making DNS calls. URL's still make DNS calls when retrieving a URL. The difference is, two different host names that previously resolved to an identical IP address will no longer be equal, but now we can use dynamic dns addresses and fail over replication for domain names that use a range of IP addresses to answer for one domain address. Standard Java SecureClassLoader behaviour can be had by setting a system property This also reduces or avoids calls to the built in java NameServiceProvider. If this code was in the JVM libraries, we wouldn't need it in our project. This code is freely available. Regards, Peter. On 29/06/2014 7:29 PM, Peter Levart wrote: > > On 06/29/2014 03:53 AM, Peter Firmstone wrote: >> >> It does look like a good solution. >> >> You might wonder why we still need a custom SecurityManager? >> >> Concurrency. >> >> The ageing java security infrastructure is a huge bottleneck for >> multithreaded code. >> >> Regards, >> >> Peter. >> > > Hi Peter, > > If you could identify the most critical bottleneck(s) of default > SecurityManager, there might be a way to fix them... > > Regards, Peter > >> >> >> >> >> >> >> >> > Message: 1 >> > Date: Thu, 26 Jun 2014 19:10:22 -0400 >> > From: Doug Lea
> >> > To: Peter Levart> > >> > Cc: core-libs-dev> >, OpenJDK >> > > >, concurrency-interest >> > > > >> > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles >> > Message-ID:<53ACA85E.2030407 at cs.oswego.edu >> > >> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> > >> > >> > 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 >> >> >> >> _______________________________________________ >> Concurrency-interest mailing list >> Concurrency-interest at cs.oswego.edu >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest > ------------------------------ Message: 2 Date: Mon, 30 Jun 2014 13:53:38 +0100 From: Alan Bateman To: Peter Firmstone Cc: concurrency-interest at cs.oswego.edu Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles Message-ID:<53B15DD2.8020200 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 30/06/2014 11:02, Peter Firmstone wrote: > Hi Peter, > > There are a number of bottlenecks throughout the security > infrastructure, we have reimplemented it as follows to avoid them and > have also addressed some long standing issues: > > > If this code was in the JVM libraries, we wouldn't need it in our > project. > Have you considered bring some of these patches to OpenJDK? On RFC 3986 (you mentioned this a number of times) then there were previous attempts bring URI up to this, unfortunately had to be backed out due to compatibility issues and other breakage. It's definitely something that needs to be looked at again. -Alan ------------------------------ _______________________________________________ Concurrency-interest mailing list Concurrency-interest at cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest End of Concurrency-interest Digest, Vol 113, Issue 45 ***************************************************** From david.lloyd at redhat.com Fri Jul 11 03:20:33 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 10 Jul 2014 22:20:33 -0500 Subject: Concurrent Policy provider In-Reply-To: <53BF5342.2030801@zeus.net.au> References: <53BF5342.2030801@zeus.net.au> Message-ID: <53BF5801.2050102@redhat.com> Maybe you already know this, but this past April, Sean Mullan (from Oracle) posted a "JEP Review Request" [1] for a blanket initiative to improve security manager performance. This kind of thing sounds like exactly the sort of thing that would fit in under that initiative, IMO. [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-April/010432.html On 07/10/2014 10:00 PM, Peter Firmstone wrote: > Would there be interest in using a Policy provider and SecurityManager > designed for concurrency in Java 9? > > Some of the issues experienced and solutions are mentioned below. > > http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/security/ > > > Regards, > > Peter. > > -------- Original Message -------- > Subject: Concurrency-interest Digest, Vol 113, Issue 45 > Date: Mon, 30 Jun 2014 12:00:01 -0400 > From: concurrency-interest-request at cs.oswego.edu > Reply-To: concurrency-interest at cs.oswego.edu > To: concurrency-interest at cs.oswego.edu > > > > Send Concurrency-interest mailing list submissions to > concurrency-interest at cs.oswego.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > or, via email, send a message with subject or body 'help' to > concurrency-interest-request at cs.oswego.edu > > You can reach the person managing the list at > concurrency-interest-owner at cs.oswego.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Concurrency-interest digest..." > > > Today's Topics: > > 1. Re: ThreadLocalRandom clinit troubles (Peter Firmstone) > 2. Re: ThreadLocalRandom clinit troubles (Alan Bateman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Jun 2014 20:02:30 +1000 > From: Peter Firmstone > To: Peter Levart > Cc: concurrency-interest at cs.oswego.edu > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles > Message-ID:<53B135B6.1030105 at zeus.net.au> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi Peter, > > There are a number of bottlenecks throughout the security > infrastructure, we have reimplemented it as follows to avoid them and > have also addressed some long standing issues: > > SecurityManager - cache previously checked AccessControlContext's > (using a cache structure based on Cliff Click's non blocking hash map > and Doug Lee's concurrent skip list set), to avoid repeately calling the > policy provider (for example, you have numerous tasks in an > ExecutorService and each has an identical AccessControlContext and all > tasks cause a SocketPermission check). > > Policy provider - replaced the built in Java policy provider. The built > in Java Policy provider will hold a lock while making DNS calls, > bringing all permission checks to a grinding halt. It will also hold > locks while accessing the file system. > > To avoid making DNS calls we've implemented our own policy provider, > originated from Apache Harmony, but modified to use non blocking > immutability. It creates PermissionCollection's on demand, they're not > shared among threads and are ordered in the most favourable order for a > fast result. It also supports undocumented Java file policy provider > functionality. Because Permission objects are immutable but lazily > initialized, we call getActions() to ensure their state is completely > initialized prior to publication. > > The policy provider uses a strictly RFC 3986 compliant immutable URI > class, it performs bit shift operations on ASCII strings during > normalisation and is used by the policy provider to avoid making DNS > calls when checking CodeBase policy file permissions. > > As a result, the cost of the security infrastructure is less than 1% of > CPU load during stress tests. > > This is part of the Apache River project, JERI (Jini Extensible Remote > Invocation) performs remote method invocations as tasks running in a > system threadpool, each task executes concurrently on any exported service. > > SecureClassLoader uses CodeSource's as keys in a Map, CodeSource uses > URL in equals() and hashCode(), so we also have a RFC3986 compliant > URLClassLoader to avoid making unnecessary DNS calls in SecureClassLoader. > > Rather than rely on an external untrusted DNS to determine the identity > of CodeSource's, we use RFC 3986 compliant normalisation, without making > DNS calls. URL's still make DNS calls when retrieving a URL. The > difference is, two different host names that previously resolved to an > identical IP address will no longer be equal, but now we can use dynamic > dns addresses and fail over replication for domain names that use a > range of IP addresses to answer for one domain address. Standard Java > SecureClassLoader behaviour can be had by setting a system property > > This also reduces or avoids calls to the built in java NameServiceProvider. > > If this code was in the JVM libraries, we wouldn't need it in our project. > > This code is freely available. > > Regards, > > Peter. > > On 29/06/2014 7:29 PM, Peter Levart wrote: >> >> On 06/29/2014 03:53 AM, Peter Firmstone wrote: >>> >>> It does look like a good solution. >>> >>> You might wonder why we still need a custom SecurityManager? >>> >>> Concurrency. >>> >>> The ageing java security infrastructure is a huge bottleneck for >>> multithreaded code. >>> >>> Regards, >>> >>> Peter. >>> >> >> Hi Peter, >> >> If you could identify the most critical bottleneck(s) of default >> SecurityManager, there might be a way to fix them... >> >> Regards, Peter >> >>> >>> >>> >>> >>> >>> >>> >>> > Message: 1 >>> > Date: Thu, 26 Jun 2014 19:10:22 -0400 >>> > From: Doug Lea
> >>> > To: Peter Levart>> > >>> > Cc: core-libs-dev>> >, OpenJDK >>> > >> >, concurrency-interest >>> > >> > >>> > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit >>> troubles >>> > Message-ID:<53ACA85E.2030407 at cs.oswego.edu >>> > >>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> > >>> > >>> > 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 >>> >>> >>> >>> _______________________________________________ >>> Concurrency-interest mailing list >>> Concurrency-interest at cs.oswego.edu >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Jun 2014 13:53:38 +0100 > From: Alan Bateman > To: Peter Firmstone > Cc: concurrency-interest at cs.oswego.edu > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles > Message-ID:<53B15DD2.8020200 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 30/06/2014 11:02, Peter Firmstone wrote: >> Hi Peter, >> >> There are a number of bottlenecks throughout the security >> infrastructure, we have reimplemented it as follows to avoid them and >> have also addressed some long standing issues: >> >> >> If this code was in the JVM libraries, we wouldn't need it in our >> project. >> > Have you considered bring some of these patches to OpenJDK? > > On RFC 3986 (you mentioned this a number of times) then there were > previous attempts bring URI up to this, unfortunately had to be backed > out due to compatibility issues and other breakage. It's definitely > something that needs to be looked at again. > > -Alan > > > > ------------------------------ > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > End of Concurrency-interest Digest, Vol 113, Issue 45 > ***************************************************** > -- - DML From peter.firmstone at zeus.net.au Fri Jul 11 04:48:53 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 11 Jul 2014 14:48:53 +1000 Subject: JEP Improve Security Manager Performance Message-ID: <53BF6CB5.6010504@zeus.net.au> Sean, Would a SecurityManager and Policy provider combination that has no perceptable impact on performance and is highly scalable qualify? It's a drop in fully compatible replacement. Regards, Peter. -------- Original Message -------- Subject: Re: Concurrent Policy provider Date: Thu, 10 Jul 2014 22:20:33 -0500 From: David M. Lloyd To: security-dev at openjdk.java.net Maybe you already know this, but this past April, Sean Mullan (from Oracle) posted a "JEP Review Request" [1] for a blanket initiative to improve security manager performance. This kind of thing sounds like exactly the sort of thing that would fit in under that initiative, IMO. [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-April/010432.html On 07/10/2014 10:00 PM, Peter Firmstone wrote: > Would there be interest in using a Policy provider and SecurityManager > designed for concurrency in Java 9? > > Some of the issues experienced and solutions are mentioned below. > > http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/security/ > > > Regards, > > Peter. > > -------- Original Message -------- > Subject: Concurrency-interest Digest, Vol 113, Issue 45 > Date: Mon, 30 Jun 2014 12:00:01 -0400 > From: concurrency-interest-request at cs.oswego.edu > Reply-To: concurrency-interest at cs.oswego.edu > To: concurrency-interest at cs.oswego.edu > > > > Send Concurrency-interest mailing list submissions to > concurrency-interest at cs.oswego.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > or, via email, send a message with subject or body 'help' to > concurrency-interest-request at cs.oswego.edu > > You can reach the person managing the list at > concurrency-interest-owner at cs.oswego.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Concurrency-interest digest..." > > > Today's Topics: > > 1. Re: ThreadLocalRandom clinit troubles (Peter Firmstone) > 2. Re: ThreadLocalRandom clinit troubles (Alan Bateman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Jun 2014 20:02:30 +1000 > From: Peter Firmstone > To: Peter Levart > Cc: concurrency-interest at cs.oswego.edu > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles > Message-ID:<53B135B6.1030105 at zeus.net.au> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi Peter, > > There are a number of bottlenecks throughout the security > infrastructure, we have reimplemented it as follows to avoid them and > have also addressed some long standing issues: > > SecurityManager - cache previously checked AccessControlContext's > (using a cache structure based on Cliff Click's non blocking hash map > and Doug Lee's concurrent skip list set), to avoid repeately calling the > policy provider (for example, you have numerous tasks in an > ExecutorService and each has an identical AccessControlContext and all > tasks cause a SocketPermission check). > > Policy provider - replaced the built in Java policy provider. The built > in Java Policy provider will hold a lock while making DNS calls, > bringing all permission checks to a grinding halt. It will also hold > locks while accessing the file system. > > To avoid making DNS calls we've implemented our own policy provider, > originated from Apache Harmony, but modified to use non blocking > immutability. It creates PermissionCollection's on demand, they're not > shared among threads and are ordered in the most favourable order for a > fast result. It also supports undocumented Java file policy provider > functionality. Because Permission objects are immutable but lazily > initialized, we call getActions() to ensure their state is completely > initialized prior to publication. > > The policy provider uses a strictly RFC 3986 compliant immutable URI > class, it performs bit shift operations on ASCII strings during > normalisation and is used by the policy provider to avoid making DNS > calls when checking CodeBase policy file permissions. > > As a result, the cost of the security infrastructure is less than 1% of > CPU load during stress tests. > > This is part of the Apache River project, JERI (Jini Extensible Remote > Invocation) performs remote method invocations as tasks running in a > system threadpool, each task executes concurrently on any exported service. > > SecureClassLoader uses CodeSource's as keys in a Map, CodeSource uses > URL in equals() and hashCode(), so we also have a RFC3986 compliant > URLClassLoader to avoid making unnecessary DNS calls in SecureClassLoader. > > Rather than rely on an external untrusted DNS to determine the identity > of CodeSource's, we use RFC 3986 compliant normalisation, without making > DNS calls. URL's still make DNS calls when retrieving a URL. The > difference is, two different host names that previously resolved to an > identical IP address will no longer be equal, but now we can use dynamic > dns addresses and fail over replication for domain names that use a > range of IP addresses to answer for one domain address. Standard Java > SecureClassLoader behaviour can be had by setting a system property > > This also reduces or avoids calls to the built in java NameServiceProvider. > > If this code was in the JVM libraries, we wouldn't need it in our project. > > This code is freely available. > > Regards, > > Peter. > > On 29/06/2014 7:29 PM, Peter Levart wrote: >> >> On 06/29/2014 03:53 AM, Peter Firmstone wrote: >>> >>> It does look like a good solution. >>> >>> You might wonder why we still need a custom SecurityManager? >>> >>> Concurrency. >>> >>> The ageing java security infrastructure is a huge bottleneck for >>> multithreaded code. >>> >>> Regards, >>> >>> Peter. >>> >> >> Hi Peter, >> >> If you could identify the most critical bottleneck(s) of default >> SecurityManager, there might be a way to fix them... >> >> Regards, Peter >> >>> >>> >>> >>> >>> >>> >>> >>> > Message: 1 >>> > Date: Thu, 26 Jun 2014 19:10:22 -0400 >>> > From: Doug Lea
> >>> > To: Peter Levart>> > >>> > Cc: core-libs-dev>> >, OpenJDK >>> > >> >, concurrency-interest >>> > >> > >>> > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit >>> troubles >>> > Message-ID:<53ACA85E.2030407 at cs.oswego.edu >>> > >>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> > >>> > >>> > 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 >>> >>> >>> >>> _______________________________________________ >>> Concurrency-interest mailing list >>> Concurrency-interest at cs.oswego.edu >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Jun 2014 13:53:38 +0100 > From: Alan Bateman > To: Peter Firmstone > Cc: concurrency-interest at cs.oswego.edu > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles > Message-ID:<53B15DD2.8020200 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 30/06/2014 11:02, Peter Firmstone wrote: >> Hi Peter, >> >> There are a number of bottlenecks throughout the security >> infrastructure, we have reimplemented it as follows to avoid them and >> have also addressed some long standing issues: >> >> >> If this code was in the JVM libraries, we wouldn't need it in our >> project. >> > Have you considered bring some of these patches to OpenJDK? > > On RFC 3986 (you mentioned this a number of times) then there were > previous attempts bring URI up to this, unfortunately had to be backed > out due to compatibility issues and other breakage. It's definitely > something that needs to be looked at again. > > -Alan > > > > ------------------------------ > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > End of Concurrency-interest Digest, Vol 113, Issue 45 > ***************************************************** > -- - DML From ivan.gerasimov at oracle.com Fri Jul 11 11:09:50 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Jul 2014 15:09:50 +0400 Subject: RFR: [8049250]: (smartcardio) Need a flag to inverse the Card.disconnect(reset) argument In-Reply-To: <53B988CF.60706@oracle.com> References: <53B988CF.60706@oracle.com> Message-ID: <53BFC5FE.5010704@oracle.com> I updated the webrev - changed the option name to match one in ccc. http://cr.openjdk.java.net/~igerasim/8049250/1/webrev/ Would you please review/approve the fix, pending the ccc approval? Sincerely yours, Ivan On 06.07.2014 21:35, Ivan Gerasimov wrote: > Hello! > > With the fix for JDK-7047033, the way Card.disconnect(boolean reset) > handles its argument was inverted. > To provide compatibility, it is suggested to introduce an option, > which a user can use to revert to the old behavior. > > This fix is proposed for jdk8u only. > > In jdk8u the option will be false by default, so the reset argument > will not be inverted. > > CCC request has been filed. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8049250 > WEBREV: http://cr.openjdk.java.net/~igerasim/8049250/0/webrev/ > > Sincerely yours, > Ivan > > From ivan.gerasimov at oracle.com Fri Jul 11 13:23:59 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Jul 2014 17:23:59 +0400 Subject: RFR: [8049250]: (smartcardio) Need a flag to inverse the Card.disconnect(reset) argument In-Reply-To: <53BFC5FE.5010704@oracle.com> References: <53B988CF.60706@oracle.com> <53BFC5FE.5010704@oracle.com> Message-ID: <53BFE56F.9090005@oracle.com> And another request for integrating the fix into 7u. This one is needed quite urgently, so if you could review the fix until the end of the week, it would really be appreciated! The only difference from the 8u fix is the default value of "true". http://cr.openjdk.java.net/~igerasim/8049250/2/webrev/ Sincerely yours, Ivan On 11.07.2014 15:09, Ivan Gerasimov wrote: > I updated the webrev - changed the option name to match one in ccc. > http://cr.openjdk.java.net/~igerasim/8049250/1/webrev/ > > Would you please review/approve the fix, pending the ccc approval? > > Sincerely yours, > Ivan > > > On 06.07.2014 21:35, Ivan Gerasimov wrote: >> Hello! >> >> With the fix for JDK-7047033, the way Card.disconnect(boolean reset) >> handles its argument was inverted. >> To provide compatibility, it is suggested to introduce an option, >> which a user can use to revert to the old behavior. >> >> This fix is proposed for jdk8u only. >> >> In jdk8u the option will be false by default, so the reset argument >> will not be inverted. >> >> CCC request has been filed. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8049250 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8049250/0/webrev/ >> >> Sincerely yours, >> Ivan >> >> > > > From valerie.peng at oracle.com Fri Jul 11 18:10:00 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 11 Jul 2014 11:10:00 -0700 Subject: RFR: [8049250]: (smartcardio) Need a flag to inverse the Card.disconnect(reset) argument In-Reply-To: <53BFE56F.9090005@oracle.com> References: <53B988CF.60706@oracle.com> <53BFC5FE.5010704@oracle.com> <53BFE56F.9090005@oracle.com> Message-ID: <53C02878.8000504@oracle.com> Looks fine. Thanks, Valerie On 7/11/2014 6:23 AM, Ivan Gerasimov wrote: > And another request for integrating the fix into 7u. > This one is needed quite urgently, so if you could review the fix > until the end of the week, it would really be appreciated! > > The only difference from the 8u fix is the default value of "true". > > http://cr.openjdk.java.net/~igerasim/8049250/2/webrev/ > > Sincerely yours, > Ivan > > On 11.07.2014 15:09, Ivan Gerasimov wrote: >> I updated the webrev - changed the option name to match one in ccc. >> http://cr.openjdk.java.net/~igerasim/8049250/1/webrev/ >> >> Would you please review/approve the fix, pending the ccc approval? >> >> Sincerely yours, >> Ivan >> >> >> On 06.07.2014 21:35, Ivan Gerasimov wrote: >>> Hello! >>> >>> With the fix for JDK-7047033, the way Card.disconnect(boolean reset) >>> handles its argument was inverted. >>> To provide compatibility, it is suggested to introduce an option, >>> which a user can use to revert to the old behavior. >>> >>> This fix is proposed for jdk8u only. >>> >>> In jdk8u the option will be false by default, so the reset argument >>> will not be inverted. >>> >>> CCC request has been filed. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8049250 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8049250/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >> >> >> > From valerie.peng at oracle.com Fri Jul 11 18:10:17 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 11 Jul 2014 11:10:17 -0700 Subject: RFR: [8049250]: (smartcardio) Need a flag to inverse the Card.disconnect(reset) argument In-Reply-To: <53BFC5FE.5010704@oracle.com> References: <53B988CF.60706@oracle.com> <53BFC5FE.5010704@oracle.com> Message-ID: <53C02889.40800@oracle.com> Looks fine. Thanks, Valerie On 7/11/2014 4:09 AM, Ivan Gerasimov wrote: > I updated the webrev - changed the option name to match one in ccc. > http://cr.openjdk.java.net/~igerasim/8049250/1/webrev/ > > Would you please review/approve the fix, pending the ccc approval? > > Sincerely yours, > Ivan > > > On 06.07.2014 21:35, Ivan Gerasimov wrote: >> Hello! >> >> With the fix for JDK-7047033, the way Card.disconnect(boolean reset) >> handles its argument was inverted. >> To provide compatibility, it is suggested to introduce an option, >> which a user can use to revert to the old behavior. >> >> This fix is proposed for jdk8u only. >> >> In jdk8u the option will be false by default, so the reset argument >> will not be inverted. >> >> CCC request has been filed. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8049250 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8049250/0/webrev/ >> >> Sincerely yours, >> Ivan >> >> > From otaviopolianasantana at gmail.com Fri Jul 11 01:36:03 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Thu, 10 Jul 2014 22:36:03 -0300 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes Message-ID: https://bugs.openjdk.java.net/browse/JDK-8049892 http://cr.openjdk.java.net/~prr/8049892/ -- Cheers!. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Fri Jul 11 06:41:14 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 11 Jul 2014 08:41:14 +0200 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: References: Message-ID: Hi Ot?vio, changes to the classes in the package "jdk.internal.org.objectweb.asm" should be done directly in the ASM library. Please exclude following classes from the patch: src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java And please exclude following classes from the patch too: src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java This classes will be fixed by the patch for the issue 5043030. Otherwise it looks good. Best regards, Andrej Golovnin On Fri, Jul 11, 2014 at 3:36 AM, Ot?vio Gon?alves de Santana < otaviopolianasantana at gmail.com> wrote: > https://bugs.openjdk.java.net/browse/JDK-8049892 > http://cr.openjdk.java.net/~prr/8049892/ > > -- > Cheers!. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: *http://about.me/otaviojava * > 55 (11) 98255-3513 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Jul 11 23:33:37 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Jul 2014 16:33:37 -0700 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: Thanks to Peter for digging into the secure seed generator classes and coming up with a patch. Openjdk security folks, please review. I confess to getting lost whenever I try to orient myself in the twisty maze of seed generator implementation files. Anyways, it seems important to have prngs like ThreadLocalRandom be able to get a few bits of seed entropy without loading hundreds of classes and without occupying any file descriptors permanently. Perhaps at Google we will go back to writing some simple non-portable startup code to read /dev/urandom until openjdk security team comes up with a more principled solution (but one that doesn't drag in too much machinery). -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Sun Jul 13 11:07:12 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sun, 13 Jul 2014 12:07:12 +0100 Subject: [9] request for review 8050118: Windows policy file missing semicolon Message-ID: <441A0F25-0A77-4630-8A0F-985D5B521504@oracle.com> Please review this minor correction to the default java policy file on Windows: Bug: https://bugs.openjdk.java.net/browse/JDK-8050118 Webrev: http://cr.openjdk.java.net/~vinnie/8050118/webrev.00/ Thanks. From chris.hegarty at oracle.com Sun Jul 13 12:47:24 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 13 Jul 2014 13:47:24 +0100 Subject: [9] request for review 8050118: Windows policy file missing semicolon In-Reply-To: <441A0F25-0A77-4630-8A0F-985D5B521504@oracle.com> References: <441A0F25-0A77-4630-8A0F-985D5B521504@oracle.com> Message-ID: Looks good to me Vinnie. -Chris > On 13 Jul 2014, at 12:07, Vincent Ryan wrote: > > Please review this minor correction to the default java policy file on Windows: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050118 > Webrev: http://cr.openjdk.java.net/~vinnie/8050118/webrev.00/ > > Thanks. From vincent.x.ryan at oracle.com Sun Jul 13 14:24:09 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sun, 13 Jul 2014 15:24:09 +0100 Subject: [9] request for review 8050118: Windows policy file missing semicolon In-Reply-To: References: <441A0F25-0A77-4630-8A0F-985D5B521504@oracle.com> Message-ID: <0342CA12-AC57-4E1A-86CF-8D3B08C0F526@oracle.com> Thanks Chris. On 13 Jul 2014, at 13:47, Chris Hegarty wrote: > Looks good to me Vinnie. > > -Chris > >> On 13 Jul 2014, at 12:07, Vincent Ryan wrote: >> >> Please review this minor correction to the default java policy file on Windows: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8050118 >> Webrev: http://cr.openjdk.java.net/~vinnie/8050118/webrev.00/ >> >> Thanks. From sean.mullan at oracle.com Mon Jul 14 14:44:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Jul 2014 10:44:18 -0400 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> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> Message-ID: <53C3ECC2.8040202@oracle.com> I don't see a pointer to the webrev/patch -- did you forget to include it? --Sean On 07/11/2014 07:33 PM, Martin Buchholz wrote: > Thanks to Peter for digging into the secure seed generator classes and > coming up with a patch. Openjdk security folks, please review. I confess > to getting lost whenever I try to orient myself in the twisty maze of seed > generator implementation files. > > Anyways, it seems important to have prngs like ThreadLocalRandom be able to > get a few bits of seed entropy without loading hundreds of classes and > without occupying any file descriptors permanently. Perhaps at Google we > will go back to writing some simple non-portable startup code to read > /dev/urandom until openjdk security team comes up with a more principled > solution (but one that doesn't drag in too much machinery). > From ivan.gerasimov at oracle.com Mon Jul 14 15:08:47 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Jul 2014 19:08:47 +0400 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX Message-ID: <53C3F27F.8080208@oracle.com> Hello! It was reported that trying to use DIRECT as the preferred protocol results in the CardException to get thrown under MacOSX. It turn out to be a problem of pcscd-lite implementation of the API: From the source code [1] it can be seen that the SCardConnect() function expects its argument dwPreferredProtocol to be non-zero. Windows driver normally accepts zeros [2]. Could you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8046343 WEBREV: http://cr.openjdk.java.net/~igerasim/8046343/0/webrev/ Sincerely yours, Ivan [1] http://pcsc-lite.sourcearchive.com/documentation/1.2.9-beta9-1/winscard__clnt_8c-source.html [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379473(v=vs.85).aspx From peter.levart at gmail.com Mon Jul 14 16:59:03 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jul 2014 18:59:03 +0200 Subject: ThreadLocalRandom clinit troubles In-Reply-To: <53C3ECC2.8040202@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> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> <53C3ECC2.8040202@oracle.com> Message-ID: <53C40C57.2000606@gmail.com> Hi Sean, Alex Here's a sum-up post: http://mail.openjdk.java.net/pipermail/security-dev/2014-June/010700.html Regards, Peter On 07/14/2014 04:44 PM, Sean Mullan wrote: > I don't see a pointer to the webrev/patch -- did you forget to include > it? > > --Sean > > On 07/11/2014 07:33 PM, Martin Buchholz wrote: >> Thanks to Peter for digging into the secure seed generator classes and >> coming up with a patch. Openjdk security folks, please review. I >> confess >> to getting lost whenever I try to orient myself in the twisty maze of >> seed >> generator implementation files. >> >> Anyways, it seems important to have prngs like ThreadLocalRandom be >> able to >> get a few bits of seed entropy without loading hundreds of classes and >> without occupying any file descriptors permanently. Perhaps at >> Google we >> will go back to writing some simple non-portable startup code to read >> /dev/urandom until openjdk security team comes up with a more principled >> solution (but one that doesn't drag in too much machinery). >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Mon Jul 14 17:24:12 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 14 Jul 2014 18:24:12 +0100 Subject: 8043200,8050158 :RC4 preference re-ordering. Message-ID: <53C4123C.4060106@oracle.com> Looking to backport this change to jdk7u-dev. Best security practice would be to lower the preference ordering of RC4 ciphersuites. This is work that's already in progress for JDK 8u and JDK 9. For JDK 7u, I'd also like to introduce a compatibility flag which will reverse this change in case legacy applications run into issues with the preference re-ordering. It won't be available in 8u & 9. CCC approval has been granted. http://cr.openjdk.java.net/~coffeys/webrev.rc4.7u.v2/webrev/ regards, Sean. From oleksandr.otenko at oracle.com Mon Jul 14 15:18:40 2014 From: oleksandr.otenko at oracle.com (Oleksandr Otenko) Date: Mon, 14 Jul 2014 16:18:40 +0100 Subject: [concurrency-interest] 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> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> Message-ID: <53C3F4D0.5090407@oracle.com> Can someone summarize what happened? SecureRandom used to get entropy from /dev/random, which is configurable through a policy file to /dev/urandom. Has this changed? Alex On 12/07/2014 00:33, Martin Buchholz wrote: > Thanks to Peter for digging into the secure seed generator classes and > coming up with a patch. Openjdk security folks, please review. I > confess to getting lost whenever I try to orient myself in the twisty > maze of seed generator implementation files. > > Anyways, it seems important to have prngs like ThreadLocalRandom be > able to get a few bits of seed entropy without loading hundreds of > classes and without occupying any file descriptors permanently. > Perhaps at Google we will go back to writing some simple non-portable > startup code to read /dev/urandom until openjdk security team comes up > with a more principled solution (but one that doesn't drag in too much > machinery). > > > _______________________________________________ > 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 fengzm at sg.ibm.com Mon Jul 14 20:04:45 2014 From: fengzm at sg.ibm.com (Zhemin Feng) Date: Tue, 15 Jul 2014 04:04:45 +0800 Subject: AUTO: Zhemin Feng is out of the office (returning 22/07/2014) Message-ID: I am out of the office until 22/07/2014. I will take leave from 14th, July, and will be back on 22nd, July. Please contact Tianyu Tang/Singapore/IBM or Ke Pi/Singapore/IBM for Java Security L3 work. Best regards, Feng Zhemin Note: This is an automated response to your message "security-dev Digest, Vol 85, Issue 11" sent on 07/15/2014 2:05:37. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Mon Jul 14 20:54:46 2014 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 14 Jul 2014 22:54:46 +0200 Subject: [concurrency-interest] ThreadLocalRandom clinit troubles In-Reply-To: <53C3F4D0.5090407@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> <53A98525.9080908@gmail.com> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> <53C3F4D0.5090407@oracle.com> Message-ID: SecureRandom is unfortunatelly pretty complex. It is interpreting the seed url in some way (the configuration you mentioned behave very special since Java 6) , it is mixing seed and continues data and it reorders the implementations used. JEP 123 intended to clear things, but getInstanceStrong() (which nobody uses?!) did not improve things IMHO. Bernd PS: I think the webrev changed since then, but the mail from Brad describes the problem well: http://mail.openjdk.java.net/pipermail/security-dev/2013-January/006288.html Am 14.07.2014 21:05 schrieb "Oleksandr Otenko" : > Can someone summarize what happened? > > SecureRandom used to get entropy from /dev/random, which is configurable > through a policy file to /dev/urandom. Has this changed? > > Alex > > On 12/07/2014 00:33, Martin Buchholz wrote: > > Thanks to Peter for digging into the secure seed generator classes and > coming up with a patch. Openjdk security folks, please review. I confess > to getting lost whenever I try to orient myself in the twisty maze of seed > generator implementation files. > > Anyways, it seems important to have prngs like ThreadLocalRandom be able > to get a few bits of seed entropy without loading hundreds of classes and > without occupying any file descriptors permanently. Perhaps at Google we > will go back to writing some simple non-portable startup code to read > /dev/urandom until openjdk security team comes up with a more principled > solution (but one that doesn't drag in too much machinery). > > > _______________________________________________ > Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jul 15 13:59:14 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Jul 2014 21:59:14 +0800 Subject: 8043200,8050158 :RC4 preference re-ordering. In-Reply-To: <53C4123C.4060106@oracle.com> References: <53C4123C.4060106@oracle.com> Message-ID: <53C533B2.2030502@oracle.com> Looks fine to me. Thanks, Xuelei On 7/15/2014 1:24 AM, Se?n Coffey wrote: > Looking to backport this change to jdk7u-dev. Best security practice > would be to lower the preference ordering of RC4 ciphersuites. This is > work that's already in progress for JDK 8u and JDK 9. > > For JDK 7u, I'd also like to introduce a compatibility flag which will > reverse this change in case legacy applications run into issues with the > preference re-ordering. It won't be available in 8u & 9. CCC approval > has been granted. > > http://cr.openjdk.java.net/~coffeys/webrev.rc4.7u.v2/webrev/ > > regards, > Sean. From sean.mullan at oracle.com Tue Jul 15 15:27:57 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jul 2014 11:27:57 -0400 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C3F27F.8080208@oracle.com> References: <53C3F27F.8080208@oracle.com> Message-ID: <53C5487D.7030302@oracle.com> I would also get Valerie's review before you push this since she is more familiar with this area, but I have a couple of comments: 1. Please add an appropriate noreg label to the bug. 2. The code on lines 65-69 introduces an undesirable dependency on sun.security.action for the JDK 9 modularization work. Please replace this with a nested PrivilegedAction subclass, or a lambda expression instead: AccessController.doPrivileged((PrivilegedAction) () -> System.getProperty("os.name")); (plus you will need to write some additional code to convert that to a boolean.) --Sean On 07/14/2014 11:08 AM, Ivan Gerasimov wrote: > Hello! > > It was reported that trying to use DIRECT as the preferred protocol > results in the CardException to get thrown under MacOSX. > It turn out to be a problem of pcscd-lite implementation of the API: > From the source code [1] it can be seen that the SCardConnect() > function expects its argument dwPreferredProtocol to be non-zero. > Windows driver normally accepts zeros [2]. > > Could you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8046343 > WEBREV: http://cr.openjdk.java.net/~igerasim/8046343/0/webrev/ > > Sincerely yours, > Ivan > > [1] > http://pcsc-lite.sourcearchive.com/documentation/1.2.9-beta9-1/winscard__clnt_8c-source.html > > [2] > http://msdn.microsoft.com/en-us/library/windows/desktop/aa379473(v=vs.85).aspx > > From sean.mullan at oracle.com Tue Jul 15 20:59:55 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jul 2014 16:59:55 -0400 Subject: RFR: JDK-4867890 : Clarify the return value/exception for java.security.SignedObject.verify Message-ID: <53C5964B.5040308@oracle.com> Please review this simple fix to clarify the SignatureException thrown by SignedObject.verify: http://cr.openjdk.java.net/~mullan/webrevs/4867890/webrev.00/ Thanks, Sean From weijun.wang at oracle.com Wed Jul 16 01:16:08 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Jul 2014 09:16:08 +0800 Subject: RFR: JDK-4867890 : Clarify the return value/exception for java.security.SignedObject.verify In-Reply-To: <53C5964B.5040308@oracle.com> References: <53C5964B.5040308@oracle.com> Message-ID: <594F040B-3543-44B7-B5D9-124DBCE921C2@oracle.com> Code change looks fine. I guess this belongs to the category of minor clarification that does not need a CCC? --Max On Jul 16, 2014, at 4:59, Sean Mullan wrote: > Please review this simple fix to clarify the SignatureException thrown by SignedObject.verify: > > http://cr.openjdk.java.net/~mullan/webrevs/4867890/webrev.00/ > > Thanks, > Sean From weijun.wang at oracle.com Wed Jul 16 01:19:36 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Jul 2014 09:19:36 +0800 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C5487D.7030302@oracle.com> References: <53C3F27F.8080208@oracle.com> <53C5487D.7030302@oracle.com> Message-ID: <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> There is no permission needed to get the "os.name" property. The global jre/lib/security/java.policy file also granted all codes to get that. --Max On Jul 15, 2014, at 23:27, Sean Mullan wrote: > 2. The code on lines 65-69 introduces an undesirable dependency on sun.security.action for the JDK 9 modularization work. Please replace this with a nested PrivilegedAction subclass, or a lambda expression instead: > > AccessController.doPrivileged((PrivilegedAction) () -> System.getProperty("os.name")); From mandy.chung at oracle.com Wed Jul 16 02:44:45 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Jul 2014 19:44:45 -0700 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> References: <53C3F27F.8080208@oracle.com> <53C5487D.7030302@oracle.com> <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> Message-ID: <53C5E71D.2030102@oracle.com> But someone could modify the default permissions and take out the PropertyPermission for "os.name", right? Mandy On 7/15/2014 6:19 PM, Wang Weijun wrote: > There is no permission needed to get the "os.name" property. The global jre/lib/security/java.policy file also granted all codes to get that. > > --Max > > On Jul 15, 2014, at 23:27, Sean Mullan wrote: > >> 2. The code on lines 65-69 introduces an undesirable dependency on sun.security.action for the JDK 9 modularization work. Please replace this with a nested PrivilegedAction subclass, or a lambda expression instead: >> >> AccessController.doPrivileged((PrivilegedAction) () -> System.getProperty("os.name")); From weijun.wang at oracle.com Wed Jul 16 08:41:50 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Jul 2014 16:41:50 +0800 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> Message-ID: Hi Xuelei A *primitive* version of webrev available at http://cr.openjdk.java.net/~weijun/8038089/webrev.00 Please confirm this is the way you like it. ExternalCipherSuite is the service interface and Krb5CipherSuite implements it. It's a modification of the old Krb5Proxy but I've moved as many as Kerberos-related codes to the implementation side so it has less methods now. Most likely we will define this new interface in a public package. I didn't touch any core SSL classes except for ClientHandshaker and ServerHandShaker. If you think there are other places too closely connected with kerberos, please let me know. Ideally, those case K_KRB5: case K_KRB5_EXPORT: Krb5Helper.doXXX(...): should be something like default: getExternalHelper(keyExchange).doXXX(...) but I guess we won't do that unless we know there will be a second implementation. Thanks Max From sean.mullan at oracle.com Wed Jul 16 11:56:27 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 16 Jul 2014 07:56:27 -0400 Subject: RFR: JDK-4867890 : Clarify the return value/exception for java.security.SignedObject.verify In-Reply-To: <594F040B-3543-44B7-B5D9-124DBCE921C2@oracle.com> References: <53C5964B.5040308@oracle.com> <594F040B-3543-44B7-B5D9-124DBCE921C2@oracle.com> Message-ID: <53C6686B.6020204@oracle.com> On 07/15/2014 09:16 PM, Wang Weijun wrote: > Code change looks fine. I guess this belongs to the category of minor clarification that does not need a CCC? Yes. That is also my opinion. --Sean > > --Max > > On Jul 16, 2014, at 4:59, Sean Mullan wrote: > >> Please review this simple fix to clarify the SignatureException thrown by SignedObject.verify: >> >> http://cr.openjdk.java.net/~mullan/webrevs/4867890/webrev.00/ >> >> Thanks, >> Sean > From sean.mullan at oracle.com Wed Jul 16 12:18:12 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 16 Jul 2014 08:18:12 -0400 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C5E71D.2030102@oracle.com> References: <53C3F27F.8080208@oracle.com> <53C5487D.7030302@oracle.com> <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> <53C5E71D.2030102@oracle.com> Message-ID: <53C66D84.6050808@oracle.com> On 07/15/2014 10:44 PM, Mandy Chung wrote: > But someone could modify the default permissions and take out the > PropertyPermission for "os.name", right? True. I think it would be better to wrap it in a doPriv in that case. --Sean > > Mandy > > On 7/15/2014 6:19 PM, Wang Weijun wrote: >> There is no permission needed to get the "os.name" property. The >> global jre/lib/security/java.policy file also granted all codes to get >> that. >> >> --Max >> >> On Jul 15, 2014, at 23:27, Sean Mullan wrote: >> >>> 2. The code on lines 65-69 introduces an undesirable dependency on >>> sun.security.action for the JDK 9 modularization work. Please replace >>> this with a nested PrivilegedAction subclass, or a lambda expression >>> instead: >>> >>> AccessController.doPrivileged((PrivilegedAction) () -> >>> System.getProperty("os.name")); > From peter.firmstone at zeus.net.au Wed Jul 16 12:56:46 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 16 Jul 2014 22:56:46 +1000 Subject: Policy Provider and Extensible RMI Performance. Message-ID: <53C6768E.5000504@zeus.net.au> Who said security and RMI had to be performance dogs? Anyone ever notice it's native code that uses all the CPU? 100% CPU Utilisation 0% monitor Peak live threads 99 Test run time 2 minutes. 4891 Remote Object Invocations, includes remote code downloading and class loading (thread confined). Hot Spots - Method Self time [%] Self time Self time (CPU) java.net.SocketInputStream.socketRead0[native]() 37.509655 434975.725 ms 434975.725 ms java.net.DualStackPlainSocketImpl.accept0[native]() 25.825586 299482.984 ms 299482.984 ms java.net.TwoStacksPlainDatagramSocketImpl.socketNativeSetOption[native]() 15.138092 175546.873 ms 175546.873 ms sun.management.ThreadImpl.dumpThreads0[native]() 9.167401 106308.549 ms 106308.549 ms java.net.TwoStacksPlainDatagramSocketImpl.peekData[native]() 7.8661814 91219.129 ms 91219.129 ms java.net.SocketOutputStream.socketWrite0[native]() 1.8873161 21886.01 ms 21886.01 ms Impact of Security (thread confined PermissionCollection's created on demand in optimum order, discarded in CPU cache): java.security.AccessController.doPrivileged[native]() 0.2687941 3117.035 ms 3117.035 ms java.security.AccessController.getStackAccessControlContext[native]() 0.14554662 1687.812 ms 1687.812 ms java.security.AccessControlContext.checkPermission() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext.setCCL() 0 0.0 ms 0.0 ms org.apache.river.api.security.CombinerSecurityManager$DelegateProtectionDomain.implies() 0 0.0 ms 0.0 ms org.apache.river.api.net.RFC3986URLClassLoader.findClassImpl() 0 0.0 ms 0.0 ms com.sun.proxy.$Proxy5.prepareAndCommit() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider.getCurrentSubPolicy() 0 0.0 ms 0.0 ms java.io.ObjectOutputStream.writeProxyDesc() 0 0.0 ms 0.0 ms java.lang.Class.forName() 0 0.0 ms 0.0 ms java.security.ProtectionDomain.implies() 0 0.0 ms 0.0 ms sun.reflect.GeneratedMethodAccessor25.invoke() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider.implies() 0 0.0 ms 0.0 ms com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext.access$500() 0 0.0 ms 0.0 ms org.apache.river.api.net.RFC3986URLClassLoader.findClass() 0 0.0 ms 0.0 ms net.jini.loader.pref.PreferredClassLoader.loadClass() 0 0.0 ms 0.0 ms java.security.AccessController.getContext() 0 0.0 ms 0.0 ms java.security.AccessController.doPrivileged() 0 0.0 ms 0.0 ms Thread confined classloading (1 Thread per child ClassLoader). java.lang.Class.forName0[native]() 0.030607257 354.933 ms 354.933 ms ant -f C:\\Users\\peter\\Documents\\NetBeansProjects\\peterConcurrentPolicy qa.run-tests qa.run-tests: qa.james-brown: Deleting directory C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\soul Created dir: C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\soul Creating C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\soul\soul.201407162226006985 qa.run-tests: ----------------------------------------- CONFIGURATION FILE: C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\src\com\sun\jini\test\resources\qaHarness.prop ----------------------------------------- SETTING UP THE TEST LIST: Adding test: com/sun/jini/test/impl/mahalo/RandomStressTest.td ----------------------------------------- GENERAL HARNESS CONFIGURATION INFORMATION: Date started: Wed Jul 16 22:26:08 EST 2014 Installation directory of the JSK: com.sun.jini.jsk.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy Installation directory of the harness: com.sun.jini.qa.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa Categories being tested: categories=No Categories ----------------------------------------- ENVIRONMENT PROPERTIES: JVM information: Java HotSpot(TM) Client VM, 25.0-b70, 32 bit VM mode Oracle Corporation OS information: Windows 7, 6.1, x86 ----------------------------------------- STARTING TO RUN THE TESTS Running com/sun/jini/test/impl/mahalo/RandomStressTest.td Time is Wed Jul 16 22:26:08 EST 2014 Starting test in separate process with command: 'C:\Program Files\Java\jdk1.8.0\jre\bin\java' -Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/qa/harness/policy/defaulttest.policy '-Djava.rmi.server.codebase=http://medusa:9082/qa1-share-dl.jar http://medusa:9082/qa1-mahalo-dl.jar' -cp C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jiniharness.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jinitests.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\jsk-platform.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\jsk-lib.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\high-scale-lib.jar;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib\custard-apple-1.0.3.jar -ea -esa '-Djava.ext.dirs=C:\Program Files\Java\jdk1.8.0\jre\lib\ext;C:\windows\Sun\Java\lib\ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib-ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib-ext' -Dcom.sun.jini.jsk.port=9080 -Dcom.sun.jini.qa.port=9081 -Dcom.sun.jini.jsk.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy -Dcom.sun.jini.qa.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa -Dcom.sun.jini.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jiniharness.jar -Dcom.sun.jini.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\jinitests.jar -Dcom.sun.jini.qa.harness.runjiniserver=true -Dcom.sun.jini.qa.harness.runkitserver=true -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/qa/harness/trust/dynamic-policy.properties -Dcom.sun.jini.qa.harness.testhosts= -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\src\com\sun\jini\test\resources\qa1.logging -Djava.rmi.server.useCodebaseOnly=false -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true -Dcom.sun.jini.test.home=C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa -Dcom.sun.jini.test.port=9082 -Dcom.sun.jini.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/qa/src/com/sun/jini/test/resources/jinitest.policy '-Djava.ext.dirs=C:\Program Files\Java\jdk1.8.0\jre\lib\ext;C:\windows\Sun\Java\lib\ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib-ext;C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib-ext' com.sun.jini.qa.harness.MasterTest com/sun/jini/test/impl/mahalo/RandomStressTest.td TIME: 10:26:09 PM MasterTest.doTest INFO: ============================== CALLING CONSTRUCT() ============================== Jul 16, 2014 10:26:09 PM com.sun.jini.tool.ClassServer run INFO: ClassServer started [[C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\], port 9081] MasterTest.doTest INFO: =============================== CALLING RUN() =============================== RandomStressTest.run INFO: RandomStressTest: To repeat the test, note down the seed RandomStressTest.run INFO: RandomStressTest: seed = 1405513570013 RandomStressTest.run INFO: TEST NOT FINISHED UNTIL I SAY DONE Jul 16, 2014 10:26:10 PM com.sun.jini.tool.ClassServer run INFO: ClassServer started [[C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\lib\], port 9082] Jul 16, 2014 10:26:10 PM com.sun.jini.tool.ClassServer run INFO: ClassServer started [[C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\lib-dl\], port 9080] NonActGrp-out: Profiler Agent: Waiting for connection on port 5140 (Protocol version: 13) NonActGrp-out: Profiler Agent: Established connection with the tool NonActGrp-out: Profiler Agent: Local accelerated session NonActGrp-out: java.lang.ClassNotFoundException: java/util/LinkedHashMap$KeyIterator NonActGrp-out: at java.lang.Class.forName0(Native Method) NonActGrp-out: at java.lang.Class.forName(Class.java:259) NonActGrp-out: at org.netbeans.lib.profiler.server.ProfilerInterface$InitiateProfilingThread.initiateInstrumentation(ProfilerInterface.java:138) NonActGrp-out: at org.netbeans.lib.profiler.server.ProfilerInterface$InitiateProfilingThread.run(ProfilerInterface.java:100) TIME: 10:27:36 PM RandomStressTest.run INFO: Wait about 15 sec. TIME: 10:27:51 PM RandomStressTest.run INFO: TEST DONE MasterTest.doTest INFO: ============================ CALLING TEARDOWN() ============================= NonActGrp-out: Profiler Agent: Connection with agent closed NonActGrp-out: Profiler Agent: Connection with agent closed NonActGrp-out: Profiler Agent: JNI OnLoad Initializing... NonActGrp-out: Profiler Agent: JNI OnLoad Initialized successfully NonActGrp-out: Profiler Agent: 250 classes cached. Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9081] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9081] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9082] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9082] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9080] Jul 16, 2014 10:27:58 PM com.sun.jini.tool.ClassServer terminate INFO: ClassServer terminated [port 9080] TIME: 10:28:03 PM Test process was destroyed and returned code 0 com/sun/jini/test/impl/mahalo/RandomStressTest.td Test Passed: OK ----------------------------------------- SUMMARY ================================= com/sun/jini/test/impl/mahalo/RandomStressTest.td Test Passed: OK ----------------------------------------- # of tests started = 1 # of tests completed = 1 # of tests passed = 1 # of tests failed = 0 ----------------------------------------- Date finished: Wed Jul 16 22:28:08 EST 2014 Time elapsed: 119 seconds qa.collect-result: BUILD SUCCESSFUL (total time: 2 minutes 1 second) -------------- next part -------------- A non-text attachment was scrubbed... Name: RandomStressTest.csv Type: application/vnd.ms-excel Size: 39444 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RandomStressTest-profiler.csv Type: application/vnd.ms-excel Size: 11119 bytes Desc: not available URL: From vincent.x.ryan at oracle.com Wed Jul 16 13:22:20 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 16 Jul 2014 14:22:20 +0100 Subject: [9] RFR: 8036612 [parfait] JNI exception pending in jdk/src/windows/native/sun/security/mscapi/security.cpp Message-ID: <568FAF78-A531-4969-AD07-7D4870296B3D@oracle.com> Please review this fix to the native code component of the SunMSCAPI provider. It now checks whether a Java exception (thrown from JNI) is already pending, before continuing. Bug: https://bugs.openjdk.java.net/browse/JDK-8036612 Webrev: http://cr.openjdk.java.net/~vinnie/8036612/webrev.00/ Thanks. From ivan.gerasimov at oracle.com Wed Jul 16 18:46:46 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 16 Jul 2014 22:46:46 +0400 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C66D84.6050808@oracle.com> References: <53C3F27F.8080208@oracle.com> <53C5487D.7030302@oracle.com> <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> <53C5E71D.2030102@oracle.com> <53C66D84.6050808@oracle.com> Message-ID: <53C6C896.3050406@oracle.com> Thanks everyone for the input! I've updated the webrev as suggested: http://cr.openjdk.java.net/~igerasim/8046343/1/webrev/ I have also added a simple manual test, which should help SQE make sure the bug is gone. Sincerely yours, Ivan On 16.07.2014 16:18, Sean Mullan wrote: > On 07/15/2014 10:44 PM, Mandy Chung wrote: >> But someone could modify the default permissions and take out the >> PropertyPermission for "os.name", right? > > True. I think it would be better to wrap it in a doPriv in that case. > > --Sean > >> >> Mandy >> >> On 7/15/2014 6:19 PM, Wang Weijun wrote: >>> There is no permission needed to get the "os.name" property. The >>> global jre/lib/security/java.policy file also granted all codes to get >>> that. >>> >>> --Max >>> >>> On Jul 15, 2014, at 23:27, Sean Mullan wrote: >>> >>>> 2. The code on lines 65-69 introduces an undesirable dependency on >>>> sun.security.action for the JDK 9 modularization work. Please replace >>>> this with a nested PrivilegedAction subclass, or a lambda expression >>>> instead: >>>> >>>> AccessController.doPrivileged((PrivilegedAction) () -> >>>> System.getProperty("os.name")); >> > > From ivan.gerasimov at oracle.com Wed Jul 16 21:00:06 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 17 Jul 2014 01:00:06 +0400 Subject: RFR [8050893] (smartcardio) Invert reset argument in tests in sun/security/smartcardio Message-ID: <53C6E7D6.8000108@oracle.com> Hello! With the fix for JDK-7047033, the meaning of the argument for the Card.disconnect(boolean reset) function was inverted. As a result, all its uses in the tests have to be updated. Would you please review the simple fix for that? I also took a chance to organize the imports. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8050893 WEBREV: http://cr.openjdk.java.net/~igerasim/8050893/0/webrev/ Sincerely yours, Ivan From valerie.peng at oracle.com Wed Jul 16 22:08:26 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 16 Jul 2014 15:08:26 -0700 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C6C896.3050406@oracle.com> References: <53C3F27F.8080208@oracle.com> <53C5487D.7030302@oracle.com> <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> <53C5E71D.2030102@oracle.com> <53C66D84.6050808@oracle.com> <53C6C896.3050406@oracle.com> Message-ID: <53C6F7DA.3090100@oracle.com> Looks fine to me. Thanks, Valerie On 7/16/2014 11:46 AM, Ivan Gerasimov wrote: > Thanks everyone for the input! > > I've updated the webrev as suggested: > http://cr.openjdk.java.net/~igerasim/8046343/1/webrev/ > > I have also added a simple manual test, which should help SQE make > sure the bug is gone. > > Sincerely yours, > Ivan > > On 16.07.2014 16:18, Sean Mullan wrote: >> On 07/15/2014 10:44 PM, Mandy Chung wrote: >>> But someone could modify the default permissions and take out the >>> PropertyPermission for "os.name", right? >> >> True. I think it would be better to wrap it in a doPriv in that case. >> >> --Sean >> >>> >>> Mandy >>> >>> On 7/15/2014 6:19 PM, Wang Weijun wrote: >>>> There is no permission needed to get the "os.name" property. The >>>> global jre/lib/security/java.policy file also granted all codes to get >>>> that. >>>> >>>> --Max >>>> >>>> On Jul 15, 2014, at 23:27, Sean Mullan wrote: >>>> >>>>> 2. The code on lines 65-69 introduces an undesirable dependency on >>>>> sun.security.action for the JDK 9 modularization work. Please replace >>>>> this with a nested PrivilegedAction subclass, or a lambda expression >>>>> instead: >>>>> >>>>> AccessController.doPrivileged((PrivilegedAction) () -> >>>>> System.getProperty("os.name")); >>> >> >> > From valerie.peng at oracle.com Wed Jul 16 22:12:02 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 16 Jul 2014 15:12:02 -0700 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C3F27F.8080208@oracle.com> References: <53C3F27F.8080208@oracle.com> Message-ID: <53C6F8B2.8010501@oracle.com> Looks good. Thanks, Valerie On 7/14/2014 8:08 AM, Ivan Gerasimov wrote: > Hello! > > It was reported that trying to use DIRECT as the preferred protocol > results in the CardException to get thrown under MacOSX. > It turn out to be a problem of pcscd-lite implementation of the API: > From the source code [1] it can be seen that the SCardConnect() > function expects its argument dwPreferredProtocol to be non-zero. > Windows driver normally accepts zeros [2]. > > Could you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8046343 > WEBREV: http://cr.openjdk.java.net/~igerasim/8046343/0/webrev/ > > Sincerely yours, > Ivan > > [1] > http://pcsc-lite.sourcearchive.com/documentation/1.2.9-beta9-1/winscard__clnt_8c-source.html > [2] > http://msdn.microsoft.com/en-us/library/windows/desktop/aa379473(v=vs.85).aspx > From xuelei.fan at oracle.com Thu Jul 17 04:35:37 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Jul 2014 12:35:37 +0800 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> Message-ID: <53C75299.3060007@oracle.com> On 7/16/2014 4:41 PM, Wang Weijun wrote: > Hi Xuelei > > A *primitive* version of webrev available at > > http://cr.openjdk.java.net/~weijun/8038089/webrev.00 > > Please confirm this is the way you like it. > I have not read too much about the details of the update. But looks like it is in the right way. > ExternalCipherSuite is the service interface and Krb5CipherSuite implements it. It's a modification of the old Krb5Proxy but I've moved as many as Kerberos-related codes to the implementation side so it has less methods now. > > Most likely we will define this new interface in a public package. > If krb5 is the only external implementation of TLS cipher suites, I think, we may want to try the best not to define public interface if possible. Thanks, Xuelei > I didn't touch any core SSL classes except for ClientHandshaker and ServerHandShaker. If you think there are other places too closely connected with kerberos, please let me know. > > Ideally, those > > case K_KRB5: case K_KRB5_EXPORT: > Krb5Helper.doXXX(...): > > should be something like > > default: > getExternalHelper(keyExchange).doXXX(...) > > but I guess we won't do that unless we know there will be a second implementation. > > Thanks > Max > > > > > > From weijun.wang at oracle.com Thu Jul 17 06:09:54 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 17 Jul 2014 14:09:54 +0800 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <53C75299.3060007@oracle.com> References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> <53C75299.3060007@oracle.com> Message-ID: <116007FD-D54C-40E3-93DD-924629D24490@oracle.com> Where is the beast place to define this ServiceLoader interface? If not public, how do I "export" it so that java.security.jgss knows it? Thanks Max On Jul 17, 2014, at 12:35, Xuelei Fan wrote: >> ExternalCipherSuite is the service interface and Krb5CipherSuite implements it. It's a modification of the old Krb5Proxy but I've moved as many as Kerberos-related codes to the implementation side so it has less methods now. >> >> Most likely we will define this new interface in a public package. >> > If krb5 is the only external implementation of TLS cipher suites, I > think, we may want to try the best not to define public interface if > possible. From sean.mullan at oracle.com Thu Jul 17 14:43:24 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 Jul 2014 10:43:24 -0400 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C6F7DA.3090100@oracle.com> References: <53C3F27F.8080208@oracle.com> <53C5487D.7030302@oracle.com> <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> <53C5E71D.2030102@oracle.com> <53C66D84.6050808@oracle.com> <53C6C896.3050406@oracle.com> <53C6F7DA.3090100@oracle.com> Message-ID: <53C7E10C.5000308@oracle.com> Looks fine to me too. --Sean On 07/16/2014 06:08 PM, Valerie Peng wrote: > > Looks fine to me. > Thanks, > Valerie > > On 7/16/2014 11:46 AM, Ivan Gerasimov wrote: >> Thanks everyone for the input! >> >> I've updated the webrev as suggested: >> http://cr.openjdk.java.net/~igerasim/8046343/1/webrev/ >> >> I have also added a simple manual test, which should help SQE make >> sure the bug is gone. >> >> Sincerely yours, >> Ivan >> >> On 16.07.2014 16:18, Sean Mullan wrote: >>> On 07/15/2014 10:44 PM, Mandy Chung wrote: >>>> But someone could modify the default permissions and take out the >>>> PropertyPermission for "os.name", right? >>> >>> True. I think it would be better to wrap it in a doPriv in that case. >>> >>> --Sean >>> >>>> >>>> Mandy >>>> >>>> On 7/15/2014 6:19 PM, Wang Weijun wrote: >>>>> There is no permission needed to get the "os.name" property. The >>>>> global jre/lib/security/java.policy file also granted all codes to get >>>>> that. >>>>> >>>>> --Max >>>>> >>>>> On Jul 15, 2014, at 23:27, Sean Mullan wrote: >>>>> >>>>>> 2. The code on lines 65-69 introduces an undesirable dependency on >>>>>> sun.security.action for the JDK 9 modularization work. Please replace >>>>>> this with a nested PrivilegedAction subclass, or a lambda expression >>>>>> instead: >>>>>> >>>>>> AccessController.doPrivileged((PrivilegedAction) () -> >>>>>> System.getProperty("os.name")); >>>> >>> >>> >> From valerie.peng at oracle.com Fri Jul 18 01:16:47 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 17 Jul 2014 18:16:47 -0700 Subject: RFR [8050893] (smartcardio) Invert reset argument in tests in sun/security/smartcardio In-Reply-To: <53C6E7D6.8000108@oracle.com> References: <53C6E7D6.8000108@oracle.com> Message-ID: <53C8757F.8060908@oracle.com> Looks fine. Valerie On 7/16/2014 2:00 PM, Ivan Gerasimov wrote: > Hello! > > With the fix for JDK-7047033, the meaning of the argument for the > Card.disconnect(boolean reset) function was inverted. > As a result, all its uses in the tests have to be updated. > Would you please review the simple fix for that? > I also took a chance to organize the imports. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8050893 > WEBREV: http://cr.openjdk.java.net/~igerasim/8050893/0/webrev/ > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Fri Jul 18 12:17:53 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 18 Jul 2014 16:17:53 +0400 Subject: RFR [8050893] (smartcardio) Invert reset argument in tests in sun/security/smartcardio In-Reply-To: <53C8757F.8060908@oracle.com> References: <53C6E7D6.8000108@oracle.com> <53C8757F.8060908@oracle.com> Message-ID: <53C91071.8030004@oracle.com> Thanks Valerie! On 18.07.2014 5:16, Valerie Peng wrote: > Looks fine. > Valerie > > On 7/16/2014 2:00 PM, Ivan Gerasimov wrote: >> Hello! >> >> With the fix for JDK-7047033, the meaning of the argument for the >> Card.disconnect(boolean reset) function was inverted. >> As a result, all its uses in the tests have to be updated. >> Would you please review the simple fix for that? >> I also took a chance to organize the imports. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8050893 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8050893/0/webrev/ >> >> Sincerely yours, >> Ivan >> > > From ivan.gerasimov at oracle.com Fri Jul 18 12:18:20 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 18 Jul 2014 16:18:20 +0400 Subject: RFR [8046343] (smartcardio) CardTerminal.connect('direct') does not work on MacOSX In-Reply-To: <53C7E10C.5000308@oracle.com> References: <53C3F27F.8080208@oracle.com> <53C5487D.7030302@oracle.com> <952AE60B-DADC-469D-8742-8ABA17745A3C@oracle.com> <53C5E71D.2030102@oracle.com> <53C66D84.6050808@oracle.com> <53C6C896.3050406@oracle.com> <53C6F7DA.3090100@oracle.com> <53C7E10C.5000308@oracle.com> Message-ID: <53C9108C.3070303@oracle.com> Thank you Valerie and Sean! On 17.07.2014 18:43, Sean Mullan wrote: > Looks fine to me too. > > --Sean > > On 07/16/2014 06:08 PM, Valerie Peng wrote: >> >> Looks fine to me. >> Thanks, >> Valerie >> >> On 7/16/2014 11:46 AM, Ivan Gerasimov wrote: >>> Thanks everyone for the input! >>> >>> I've updated the webrev as suggested: >>> http://cr.openjdk.java.net/~igerasim/8046343/1/webrev/ >>> >>> I have also added a simple manual test, which should help SQE make >>> sure the bug is gone. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 16.07.2014 16:18, Sean Mullan wrote: >>>> On 07/15/2014 10:44 PM, Mandy Chung wrote: >>>>> But someone could modify the default permissions and take out the >>>>> PropertyPermission for "os.name", right? >>>> >>>> True. I think it would be better to wrap it in a doPriv in that case. >>>> >>>> --Sean >>>> >>>>> >>>>> Mandy >>>>> >>>>> On 7/15/2014 6:19 PM, Wang Weijun wrote: >>>>>> There is no permission needed to get the "os.name" property. The >>>>>> global jre/lib/security/java.policy file also granted all codes >>>>>> to get >>>>>> that. >>>>>> >>>>>> --Max >>>>>> >>>>>> On Jul 15, 2014, at 23:27, Sean Mullan >>>>>> wrote: >>>>>> >>>>>>> 2. The code on lines 65-69 introduces an undesirable dependency on >>>>>>> sun.security.action for the JDK 9 modularization work. Please >>>>>>> replace >>>>>>> this with a nested PrivilegedAction subclass, or a lambda >>>>>>> expression >>>>>>> instead: >>>>>>> >>>>>>> AccessController.doPrivileged((PrivilegedAction) () -> >>>>>>> System.getProperty("os.name")); >>>>> >>>> >>>> >>> > > From valerie.peng at oracle.com Fri Jul 18 17:13:01 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 18 Jul 2014 10:13:01 -0700 Subject: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider Message-ID: <53C9559D.5070209@oracle.com> Vinnie, Could you please help reviewing this change? My current approach is to minimize code changes/refactoring - move the ECParameters, NamedCurve, CurveDB classes to sun.security.util package and then change the depending classes to use sun.security.util.XXX rather than sun.security.ec.XXX. Besides moving the 3 classes, I also changed some methods to public to be accessible from sun.security.ec package. webrev: http://cr.openjdk.java.net/~valeriep/8035166/webrev.00/ Thanks, Valerie From martinrb at google.com Fri Jul 18 19:35:01 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Jul 2014 12:35:01 -0700 Subject: [concurrency-interest] 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> <53A9EF29.7030208@gmail.com> <53AB09E5.9070303@gmail.com> <53C3F4D0.5090407@oracle.com> Message-ID: I support Peter at al's plan to add an API that ThreadLocalRandom et al can use to get some system entropy without unbounded class dependency loading. It should not surprise anyone that at Google, we are most interested in running on Linux, so while we're waiting for a proper fix to happen we are locally applying a simpler patch that tries explicitly /dev/urandom, falling back to SecureRandom if necessary: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ThreadLocalRandom-system-entropy/ On Mon, Jul 14, 2014 at 1:54 PM, Bernd wrote: > SecureRandom is unfortunatelly pretty complex. It is interpreting the > seed url in some way (the configuration you mentioned behave very special > since Java 6) , it is mixing seed and continues data and it reorders the > implementations used. > > JEP 123 intended to clear things, but getInstanceStrong() (which nobody > uses?!) did not improve things IMHO. > > Bernd > > PS: I think the webrev changed since then, but the mail from Brad > describes the problem well: > http://mail.openjdk.java.net/pipermail/security-dev/2013-January/006288.html > Am 14.07.2014 21:05 schrieb "Oleksandr Otenko" < > oleksandr.otenko at oracle.com>: > > Can someone summarize what happened? >> >> SecureRandom used to get entropy from /dev/random, which is configurable >> through a policy file to /dev/urandom. Has this changed? >> >> Alex >> >> On 12/07/2014 00:33, Martin Buchholz wrote: >> >> Thanks to Peter for digging into the secure seed generator classes and >> coming up with a patch. Openjdk security folks, please review. I confess >> to getting lost whenever I try to orient myself in the twisty maze of seed >> generator implementation files. >> >> Anyways, it seems important to have prngs like ThreadLocalRandom be >> able to get a few bits of seed entropy without loading hundreds of classes >> and without occupying any file descriptors permanently. Perhaps at Google >> we will go back to writing some simple non-portable startup code to read >> /dev/urandom until openjdk security team comes up with a more principled >> solution (but one that doesn't drag in too much machinery). >> >> >> _______________________________________________ >> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jul 18 20:55:33 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Jul 2014 16:55:33 -0400 Subject: RFR 8043071: Expose session key and KRB_CRED through extended GSS-API In-Reply-To: <03ED7B0D-5503-4A72-A5D2-71A8F47702B2@oracle.com> References: <62344483-E9E6-4FA9-B3AA-F7099DC48192@oracle.com> <53BC44B2.4020406@oracle.com> <0E051012-E0F7-42A4-A847-67209C908C7F@oracle.com> <53BD9F16.3090704@oracle.com> <03ED7B0D-5503-4A72-A5D2-71A8F47702B2@oracle.com> Message-ID: <53C989C5.9000403@oracle.com> The updated webrev looks good. --Sean On 07/10/2014 01:59 AM, Wang Weijun wrote: > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8043071/webrev.01/ > > All your suggestions accepted, plus > > - New test on new classes added into KerberosHashEqualsTest.java > > - A duplicate test/sun/security/krb5/auto/KerberosHashEqualsTest.java removed > > - I don't know why KerberosKey allows a null principal, but anyway update its toString() to avoid NPE > > - KerberosTicket.toString() now returns "Destroyed KerberosTicket" instead of throwing an ISE, to be consistent with other classes > > Thanks > Max > From david.lloyd at redhat.com Fri Jul 18 21:43:21 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 18 Jul 2014 16:43:21 -0500 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <535A72F0.3050800@oracle.com> References: <535A72F0.3050800@oracle.com> Message-ID: <53C994F9.9090101@redhat.com> On 04/25/2014 09:36 AM, Sean Mullan wrote: > Please review a draft of a proposed research JEP to improve the > performance of the Security Manager: > > > http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00 > > > I am particularly interested in any experience you have measuring or > profiling the performance of your code when run with a Security Manager, > and any potential ideas for optimizations that you may have. It occurs to me that there is also another axis along which SM performance might be improved. The first part is clearly making the various stages of permission checking, access control context acquisition, etc. all more efficient, as previously discussed, but another thing worth looking at is examining and reducing the number of permission checks and privileged actions actually required by a typical application. For example, most commonly, the privileged actions in our code bases are doing things like: 1. Getting a class loader for a class 2. Getting and (less commonly) setting system properties 3. Getting environment properties 4. Making reflection objects accessible The permission checks for all of these actions could be hoisted to dedicated object classes which perform the action, where the permission is actually checked when the object instance is acquired. For example: public final class ClassClassLoaderAccessor { [...] public static ClassClassLoaderAccessor getInstance() { System.getSecurityManager().checkPermission(CLASS_LOADER_PERMISSION); return INSTANCE; } public ClassLoader getClassLoader(Class clazz) { // bypass security check (this is a contrived example) return clazz.classLoader; } } The exact mechanism would necessarily be JDK specific - especially if these classes would reside in separate packages from their related functionality - but the point is that the permission check only happens once, and the object could then be efficiently utilized in a tight loop. We use a similar pattern in a few places where permission checks are done, and it seems to work adequately. The command object instance can easily be placed into a non-public static final field for convenient access. -- - DML From valerie.peng at oracle.com Fri Jul 18 23:12:24 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 18 Jul 2014 16:12:24 -0700 Subject: [9] RFR 8049312: AES/CICO test failed with on several modes Message-ID: <53C9A9D8.1060109@oracle.com> Can someone please help reviewing this following fix? https://bugs.openjdk.java.net/browse/JDK-8049312 Webrev: http://cr.openjdk.java.net/~valeriep/8049312/webrev.00/ The must-fix change is in || src/share/classes/com/sun/crypto/provider/CipherCore.java which is to correct the data size calculation based on "unitBytes". For example, for CFB24, our current impl assumes the given data will be multiples of 3 bytes. When the given data isn't multiples of 3, it will continue but then the result is incorrect. To make the code more robust, I think we should explicitly check and error out when the given data doesn't have the correct size. Thus, I have added the input-length check to the various mode implementations. Along the way, I also fixed javadoc typos, removed redundancies, etc. Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Jul 19 02:36:24 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 19 Jul 2014 10:36:24 +0800 Subject: RFR 8051399: Fix for JDK-8043071 breaks dev build Message-ID: <45CC6EDD-3E5A-4EEA-89D2-BF5F455BE415@oracle.com> Please review the code changes at http://cr.openjdk.java.net/~weijun/8051399/webrev.00/ A new class was introduced with the same name and build would show error: reference to EncryptionKey is ambiguous Thanks Max From xuelei.fan at oracle.com Sat Jul 19 05:50:23 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 19 Jul 2014 13:50:23 +0800 Subject: RFR 8051399: Fix for JDK-8043071 breaks dev build In-Reply-To: <45CC6EDD-3E5A-4EEA-89D2-BF5F455BE415@oracle.com> References: <45CC6EDD-3E5A-4EEA-89D2-BF5F455BE415@oracle.com> Message-ID: <53CA071F.2070704@oracle.com> Looks fine to me. Xuelei On 7/19/2014 10:36 AM, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8051399/webrev.00/ > > A new class was introduced with the same name and build would show > > error: reference to EncryptionKey is ambiguous > > Thanks > Max > From peter.firmstone at zeus.net.au Sat Jul 19 08:31:19 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 19 Jul 2014 18:31:19 +1000 Subject: Policy provider comparison Message-ID: <53CA2CD7.7010301@zeus.net.au> Thought I might provide a comparison using our random stress test on a 4 way sony vaio, JDK7 Windows 7 amd64: Note that using sun.security.provider.PolicyFile doubles the duration of the stress test and it consumes 73% of CPU. In comparison org.apache.river.api.security.ConcurrentPolicyFile uses 0% CPU and the test completes in half the time, with our policy provider we run at raw socket speed. See attached. Regards, Peter. -------------- next part -------------- A non-text attachment was scrubbed... Name: RandomStressTest-ConcurrentPolicyProvider.csv Type: application/vnd.ms-excel Size: 29569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RandomStressTest-SunPolicyProvider.csv Type: application/vnd.ms-excel Size: 31305 bytes Desc: not available URL: From peter.firmstone at zeus.net.au Sun Jul 20 02:06:48 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 20 Jul 2014 12:06:48 +1000 Subject: Policy provider comparison In-Reply-To: <53CA2CD7.7010301@zeus.net.au> References: <53CA2CD7.7010301@zeus.net.au> Message-ID: <53CB2438.8040300@zeus.net.au> There doesn't seem to be much interest in adopting an external policy provider, so I'll explain how to achieve a significant performance improvement, in case someone's interested in improving performance of the default jvm policy provider. 1. Thread confine and immediately discard PermissionCollection objects, do not cache them as is done presently. 2. We created an object representation of grant statements from policy files in memory, it is immutable and replaced during policy refresh calls, it is also non blocking and highly scalable. 3. During a policy implies call, collect all grant statements that imply a ProtectionDomain from an implies call. Take Permission objects from the grant statements and add them to PermissionCollection and Permissions (a heterogenous collection of PermissionCollection objects, itself an instance of PermissionCollection). Determine the result of the implies call and discard the Permissions, do not cache or share them with other threads. 4. Sort Permission objects before adding them to ProtectionDomain, to minimise unnecessary DNS calls from SocketPermission etc. 5. Do not add Permissions to a ProtectionDomain that delegates to the Policy provider, or Permissions may be checked twice. 6. Only add Permissions to ProtectionDomain's when they have AllPermissions or when it does not delegate to a Policy provider. PermissionCollection was designed to be threadsafe, I think this was a mistake (hindsight is 20:20), similar to HashTable and Vector, PermissionCollection instances should be thread confined (uncontended synchronization is fast). Permissions has a race condition that prevents UnresolvedPermission's from resolving on occassion too, thread confinement fixes that too. Regards, Peter. On 19/07/2014 6:31 PM, Peter Firmstone wrote: > Thought I might provide a comparison using our random stress test on a > 4 way sony vaio, JDK7 Windows 7 amd64: > > Note that using sun.security.provider.PolicyFile doubles the duration > of the stress test and it consumes 73% of CPU. > > In comparison org.apache.river.api.security.ConcurrentPolicyFile uses > 0% CPU and the test completes in half the time, with our policy > provider we run at raw socket speed. > > See attached. > > Regards, > > Peter. From weijun.wang at oracle.com Mon Jul 21 08:22:42 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jul 2014 16:22:42 +0800 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <53C75299.3060007@oracle.com> References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> <53C75299.3060007@oracle.com> Message-ID: Please review the updated webrev at http://cr.openjdk.java.net/~weijun/8038089/webrev.01 Some comment changes. Some arguments rearrangement between classes. The interface is still in sun.security.ssl. It will be easy to move it to somewhere else later. When module is introduced, we may need to export the interface from java.base to java.security.jgss. Thanks Max On Jul 17, 2014, at 12:35, Xuelei Fan wrote: > On 7/16/2014 4:41 PM, Wang Weijun wrote: >> Hi Xuelei >> >> A *primitive* version of webrev available at >> >> http://cr.openjdk.java.net/~weijun/8038089/webrev.00 >> >> Please confirm this is the way you like it. >> > I have not read too much about the details of the update. But looks > like it is in the right way. > >> ExternalCipherSuite is the service interface and Krb5CipherSuite implements it. It's a modification of the old Krb5Proxy but I've moved as many as Kerberos-related codes to the implementation side so it has less methods now. >> >> Most likely we will define this new interface in a public package. >> > If krb5 is the only external implementation of TLS cipher suites, I > think, we may want to try the best not to define public interface if > possible. > > Thanks, > Xuelei > >> I didn't touch any core SSL classes except for ClientHandshaker and ServerHandShaker. If you think there are other places too closely connected with kerberos, please let me know. >> >> Ideally, those >> >> case K_KRB5: case K_KRB5_EXPORT: >> Krb5Helper.doXXX(...): >> >> should be something like >> >> default: >> getExternalHelper(keyExchange).doXXX(...) >> >> but I guess we won't do that unless we know there will be a second implementation. >> >> Thanks >> Max >> >> >> >> >> >> > From weijun.wang at oracle.com Mon Jul 21 11:12:35 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jul 2014 19:12:35 +0800 Subject: RFR 8049834: Two security tools tests do not run with only JRE In-Reply-To: References: Message-ID: Ping again. On Jul 10, 2014, at 16:36, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8049834/webrev.00/ > > These 2 tests do not run with only JRE because they are testing on jarsigner. The weaksize.sh is simply moved to jarsigner, and default_options.sh is broken into 2 parts with the jarsigner part going to jarsigner. > > After this change, I can safely run > > jtreg -compilejdk:../build/macosx-x86_64-normal-server-fastdebug/images/j2sdk-image/ -jdk:../build/macosx-x86_64-normal-server-fastdebug/images/j2re-image/ test/sun/security/tools/keytool/default_options.sh > > Thanks > Max > From sean.mullan at oracle.com Mon Jul 21 11:12:01 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Jul 2014 07:12:01 -0400 Subject: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred In-Reply-To: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> References: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> Message-ID: <53CCF581.5000305@oracle.com> Why does the test have a 2009,2011 copyright? Otherwise, looks ok to me. --Sean On 07/07/2014 10:12 PM, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8048194/webrev.00 > > The original code goes on accepting the input mechToken even if it's of an unsupported mech. It also mistakenly interprets the input token as a mech token instead of a NegTokenTarg at the 2nd step. > > Thanks > Max > From weijun.wang at oracle.com Mon Jul 21 11:13:08 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jul 2014 19:13:08 +0800 Subject: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred In-Reply-To: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> References: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> Message-ID: Ping again. On Jul 8, 2014, at 10:12, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8048194/webrev.00 > > The original code goes on accepting the input mechToken even if it's of an unsupported mech. It also mistakenly interprets the input token as a mech token instead of a NegTokenTarg at the 2nd step. > > Thanks > Max > From weijun.wang at oracle.com Mon Jul 21 11:16:45 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jul 2014 19:16:45 +0800 Subject: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred In-Reply-To: <53CCF581.5000305@oracle.com> References: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> <53CCF581.5000305@oracle.com> Message-ID: Oops, I didn't realized you've already reviewed it until I see see the whole thread after the "ping again" mail. Must be because your mail does not have name in either TO or CC. On Jul 21, 2014, at 19:12, Sean Mullan wrote: > Why does the test have a 2009,2011 copyright? Otherwise, looks ok to me. I copied a test nearby and modified it into the new test. Will fix. Thanks Max > > --Sean > > On 07/07/2014 10:12 PM, Wang Weijun wrote: >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8048194/webrev.00 >> >> The original code goes on accepting the input mechToken even if it's of an unsupported mech. It also mistakenly interprets the input token as a mech token instead of a NegTokenTarg at the 2nd step. >> >> Thanks >> Max >> From weijun.wang at oracle.com Mon Jul 21 11:22:03 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jul 2014 19:22:03 +0800 Subject: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred In-Reply-To: References: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> <53CCF581.5000305@oracle.com> Message-ID: Then I realized your mail comes in the same minute as my ping. Either you are reviewing super fast or we happen to be writing on this thread at the same time. Anyway, amazing. --Max On Jul 21, 2014, at 19:16, Wang Weijun wrote: > Oops, I didn't realized you've already reviewed it until I see see the whole thread after the "ping again" mail. Must be because your mail does not have name in either TO or CC. > > On Jul 21, 2014, at 19:12, Sean Mullan wrote: > >> Why does the test have a 2009,2011 copyright? Otherwise, looks ok to me. > > I copied a test nearby and modified it into the new test. Will fix. > > Thanks > Max > > >> >> --Sean >> >> On 07/07/2014 10:12 PM, Wang Weijun wrote: >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8048194/webrev.00 >>> >>> The original code goes on accepting the input mechToken even if it's of an unsupported mech. It also mistakenly interprets the input token as a mech token instead of a NegTokenTarg at the 2nd step. >>> >>> Thanks >>> Max >>> > From sean.mullan at oracle.com Mon Jul 21 11:29:32 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Jul 2014 07:29:32 -0400 Subject: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred In-Reply-To: References: <9F7EE732-3932-4309-AE95-5D7B10F11F5B@oracle.com> <53CCF581.5000305@oracle.com> Message-ID: <53CCF99C.3010600@oracle.com> On 07/21/2014 07:22 AM, Wang Weijun wrote: > Then I realized your mail comes in the same minute as my ping. Either you are reviewing super fast or we happen to be writing on this thread at the same time. Anyway, amazing. The latter. I felt refreshed after the weekend so started to do some email housekeeping, reviewing old emails, etc ;) --Sean > > --Max > > On Jul 21, 2014, at 19:16, Wang Weijun wrote: > >> Oops, I didn't realized you've already reviewed it until I see see the whole thread after the "ping again" mail. Must be because your mail does not have name in either TO or CC. >> >> On Jul 21, 2014, at 19:12, Sean Mullan wrote: >> >>> Why does the test have a 2009,2011 copyright? Otherwise, looks ok to me. >> >> I copied a test nearby and modified it into the new test. Will fix. >> >> Thanks >> Max >> >> >>> >>> --Sean >>> >>> On 07/07/2014 10:12 PM, Wang Weijun wrote: >>>> Please review the code change at >>>> >>>> http://cr.openjdk.java.net/~weijun/8048194/webrev.00 >>>> >>>> The original code goes on accepting the input mechToken even if it's of an unsupported mech. It also mistakenly interprets the input token as a mech token instead of a NegTokenTarg at the 2nd step. >>>> >>>> Thanks >>>> Max >>>> >> > From sean.mullan at oracle.com Mon Jul 21 12:11:41 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Jul 2014 08:11:41 -0400 Subject: RFR 8049834: Two security tools tests do not run with only JRE In-Reply-To: References: Message-ID: <53CD037D.1090306@oracle.com> This looks fine to me, but I was wondering why you needed to do this - are there requirements to run some regression tests with just the JRE instead of the full JDK? --Sean On 07/21/2014 07:12 AM, Wang Weijun wrote: > Ping again. > > On Jul 10, 2014, at 16:36, Wang Weijun wrote: > >> Hi All >> >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8049834/webrev.00/ >> >> These 2 tests do not run with only JRE because they are testing on jarsigner. The weaksize.sh is simply moved to jarsigner, and default_options.sh is broken into 2 parts with the jarsigner part going to jarsigner. >> >> After this change, I can safely run >> >> jtreg -compilejdk:../build/macosx-x86_64-normal-server-fastdebug/images/j2sdk-image/ -jdk:../build/macosx-x86_64-normal-server-fastdebug/images/j2re-image/ test/sun/security/tools/keytool/default_options.sh >> >> Thanks >> Max >> > From weijun.wang at oracle.com Mon Jul 21 12:19:15 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jul 2014 20:19:15 +0800 Subject: RFR 8049834: Two security tools tests do not run with only JRE In-Reply-To: <53CD037D.1090306@oracle.com> References: <53CD037D.1090306@oracle.com> Message-ID: On Jul 21, 2014, at 20:11, Sean Mullan wrote: > This looks fine to me, but I was wondering why you needed to do this - are there requirements to run some regression tests with just the JRE instead of the full JDK? The embedded team has the requirement. They've already spotted several tests in jdk8 having the problem. These 2 tests are new in jdk9 and I think they will run into it one day. --Max From sean.mullan at oracle.com Mon Jul 21 12:24:35 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Jul 2014 08:24:35 -0400 Subject: RFR 8049834: Two security tools tests do not run with only JRE In-Reply-To: References: <53CD037D.1090306@oracle.com> Message-ID: <53CD0683.1080106@oracle.com> On 07/21/2014 08:19 AM, Wang Weijun wrote: > > On Jul 21, 2014, at 20:11, Sean Mullan wrote: > >> This looks fine to me, but I was wondering why you needed to do this - are there requirements to run some regression tests with just the JRE instead of the full JDK? > > The embedded team has the requirement. They've already spotted several tests in jdk8 having the problem. These 2 tests are new in jdk9 and I think they will run into it one day. How are they doing this? How do they know to not run the jarsigner tests? Are they identifying and then creating separate jtreg groups for tests that run with the JRE only? It seems like there should be a new jtreg tag or something like that which specifies if a test can run with the JRE only; otherwise this seems like it will be hard to maintain over time. --Sean From weijun.wang at oracle.com Mon Jul 21 13:41:44 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jul 2014 21:41:44 +0800 Subject: RFR 8049834: Two security tools tests do not run with only JRE In-Reply-To: <53CD0683.1080106@oracle.com> References: <53CD037D.1090306@oracle.com> <53CD0683.1080106@oracle.com> Message-ID: <668A0927-BBFB-4B6E-A457-54EFFAD4A6F0@oracle.com> On Jul 21, 2014, at 20:24, Sean Mullan wrote: > On 07/21/2014 08:19 AM, Wang Weijun wrote: >> >> On Jul 21, 2014, at 20:11, Sean Mullan wrote: >> >>> This looks fine to me, but I was wondering why you needed to do this - are there requirements to run some regression tests with just the JRE instead of the full JDK? >> >> The embedded team has the requirement. They've already spotted several tests in jdk8 having the problem. These 2 tests are new in jdk9 and I think they will run into it one day. > > How are they doing this? How do they know to not run the jarsigner tests? Are they identifying and then creating separate jtreg groups for tests that run with the JRE only? It seems like there should be a new jtreg tag or something like that which specifies if a test can run with the JRE only; otherwise this seems like it will be hard to maintain over time. test/TEST.groups has a group named needs_jdk which includes sun/security/tools/jarsigner. These test are not run when testing jre. In fact, it should be called test_jdk because as long as a test is not testing jdk itself and jdk is only used in preparing testing materials, we can use -compilejdk to provide a good-old-jdk to prepare them. In this sense, -compilejdk should also probably be renamed to -goodoldjdk (CCing Jon). :-) --Max > > --Sean From Alan.Bateman at oracle.com Mon Jul 21 15:09:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jul 2014 16:09:55 +0100 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> <53C75299.3060007@oracle.com> Message-ID: <53CD2D43.8020300@oracle.com> On 21/07/2014 09:22, Wang Weijun wrote: > Please review the updated webrev at > > http://cr.openjdk.java.net/~weijun/8038089/webrev.01 > > Some comment changes. Some arguments rearrangement between classes. > > The interface is still in sun.security.ssl. It will be easy to move it to somewhere else later. When module is introduced, we may need to export the interface from java.base to java.security.jgss. > I'm skimmed over the changes (not a detailed review yet) and just want to check one thing - would I be correct to say that this isn't a general solution for plugging in addition cipher suites, the ServiceLoader usage in Krb5Helper looks specifically for a provider that supports TLS_KRB5_XXX from what I can establish. One other thing about the ServiceLoader usage in Krb5Helper is that it's using the one-arg load method, hence the TCCL will be used to locate the cipher suite providers. As the provider is cached system-wide then I assume you meant to specify the system class loader here. The profiles build currently uses a simple dependency checker to ensure that there aren't any dependencies in a compact N build on something that is in a larger profile or the JRE. It allows a few exceptions, due to the need to keep jsse.jar and these are maintained in jdk/make/data/checkdeps/refs.allowed. I think this file will need to be updated to drop references to classes that no longer exist. A minor comment is that the new files are missing a copyright header, I assume you'll fix that up before pushing. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Mon Jul 21 15:12:31 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 21 Jul 2014 16:12:31 +0100 Subject: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: <53C9559D.5070209@oracle.com> References: <53C9559D.5070209@oracle.com> Message-ID: <93DBFD12-3A27-4F38-B3B6-98EE58F85B5E@oracle.com> Your fix looks good. BTW the Webrev doesn?t identify the 3 renamed files, did you use ?hg rename?? On 18 Jul 2014, at 18:13, Valerie Peng wrote: > Vinnie, > > Could you please help reviewing this change? > > My current approach is to minimize code changes/refactoring - move the ECParameters, NamedCurve, CurveDB classes to sun.security.util package and then change the depending classes to use sun.security.util.XXX rather than sun.security.ec.XXX. > > Besides moving the 3 classes, I also changed some methods to public to be accessible from sun.security.ec package. > > webrev: http://cr.openjdk.java.net/~valeriep/8035166/webrev.00/ > > Thanks, > Valerie > From sean.mullan at oracle.com Mon Jul 21 17:42:16 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Jul 2014 13:42:16 -0400 Subject: Policy provider comparison In-Reply-To: <53CB2438.8040300@zeus.net.au> References: <53CA2CD7.7010301@zeus.net.au> <53CB2438.8040300@zeus.net.au> Message-ID: <53CD50F8.5030707@oracle.com> Hi Peter, This list of optimizations looks very useful - thank you for sending more details! I am going to spend some time thinking about your suggestions in more detail and how they apply to the OpenJDK JavaPolicy provider and will get back to you with any further questions ... --Sean On 07/19/2014 10:06 PM, Peter Firmstone wrote: > There doesn't seem to be much interest in adopting an external policy > provider, so I'll explain how to achieve a significant performance > improvement, in case someone's interested in improving performance of > the default jvm policy provider. > > 1. Thread confine and immediately discard PermissionCollection > objects, do not cache them as is done presently. > 2. We created an object representation of grant statements from > policy files in memory, it is immutable and replaced during policy > refresh calls, it is also non blocking and highly scalable. > 3. During a policy implies call, collect all grant statements that > imply a ProtectionDomain from an implies call. Take Permission > objects from the grant statements and add them to > PermissionCollection and Permissions (a heterogenous collection of > PermissionCollection objects, itself an instance of > PermissionCollection). Determine the result of the implies call > and discard the Permissions, do not cache or share them with other > threads. > 4. Sort Permission objects before adding them to ProtectionDomain, to > minimise unnecessary DNS calls from SocketPermission etc. > 5. Do not add Permissions to a ProtectionDomain that delegates to the > Policy provider, or Permissions may be checked twice. > 6. Only add Permissions to ProtectionDomain's when they have > AllPermissions or when it does not delegate to a Policy provider. > > PermissionCollection was designed to be threadsafe, I think this was a > mistake (hindsight is 20:20), similar to HashTable and Vector, > PermissionCollection instances should be thread confined (uncontended > synchronization is fast). Permissions has a race condition that > prevents UnresolvedPermission's from resolving on occassion too, thread > confinement fixes that too. > > Regards, > > Peter. > > On 19/07/2014 6:31 PM, Peter Firmstone wrote: >> Thought I might provide a comparison using our random stress test on a >> 4 way sony vaio, JDK7 Windows 7 amd64: >> >> Note that using sun.security.provider.PolicyFile doubles the duration >> of the stress test and it consumes 73% of CPU. >> >> In comparison org.apache.river.api.security.ConcurrentPolicyFile uses >> 0% CPU and the test completes in half the time, with our policy >> provider we run at raw socket speed. >> >> See attached. >> >> Regards, >> >> Peter. > From sean.mullan at oracle.com Mon Jul 21 18:18:45 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Jul 2014 14:18:45 -0400 Subject: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: <53C9559D.5070209@oracle.com> References: <53C9559D.5070209@oracle.com> Message-ID: <53CD5985.6050803@oracle.com> Can you also change the following comment in sun/security/ssl/SupportedEllipticCurvesExtension.java: // See sun.security.ec.NamedCurve for the OIDs to // See sun.security.util.NamedCurve for the OIDs Rest looks good to me. Please add a noreg label though. --Sean On 07/18/2014 01:13 PM, Valerie Peng wrote: > Vinnie, > > Could you please help reviewing this change? > > My current approach is to minimize code changes/refactoring - move the > ECParameters, NamedCurve, CurveDB classes to sun.security.util package > and then change the depending classes to use sun.security.util.XXX > rather than sun.security.ec.XXX. > > Besides moving the 3 classes, I also changed some methods to public to > be accessible from sun.security.ec package. > > webrev: http://cr.openjdk.java.net/~valeriep/8035166/webrev.00/ > > Thanks, > Valerie > From sean.mullan at oracle.com Mon Jul 21 20:04:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Jul 2014 16:04:18 -0400 Subject: RFR 8049834: Two security tools tests do not run with only JRE In-Reply-To: <668A0927-BBFB-4B6E-A457-54EFFAD4A6F0@oracle.com> References: <53CD037D.1090306@oracle.com> <53CD0683.1080106@oracle.com> <668A0927-BBFB-4B6E-A457-54EFFAD4A6F0@oracle.com> Message-ID: <53CD7242.40307@oracle.com> On 07/21/2014 09:41 AM, Wang Weijun wrote: > > On Jul 21, 2014, at 20:24, Sean Mullan > wrote: > >> On 07/21/2014 08:19 AM, Wang Weijun wrote: >>> >>> On Jul 21, 2014, at 20:11, Sean Mullan >>> wrote: >>> >>>> This looks fine to me, but I was wondering why you needed to do >>>> this - are there requirements to run some regression tests with >>>> just the JRE instead of the full JDK? >>> >>> The embedded team has the requirement. They've already spotted >>> several tests in jdk8 having the problem. These 2 tests are new >>> in jdk9 and I think they will run into it one day. >> >> How are they doing this? How do they know to not run the jarsigner >> tests? Are they identifying and then creating separate jtreg groups >> for tests that run with the JRE only? It seems like there should be >> a new jtreg tag or something like that which specifies if a test >> can run with the JRE only; otherwise this seems like it will be >> hard to maintain over time. > > test/TEST.groups has a group named needs_jdk which includes > sun/security/tools/jarsigner. These test are not run when testing > jre. ah, didn't know about that. Fix looks fine, then. --Sean > In fact, it should be called test_jdk because as long as a test is > not testing jdk itself and jdk is only used in preparing testing > materials, we can use -compilejdk to provide a good-old-jdk to > prepare them. In this sense, -compilejdk should also probably be > renamed to -goodoldjdk (CCing Jon). :-) > > --Max > >> >> --Sean > From valerie.peng at oracle.com Mon Jul 21 22:06:19 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 21 Jul 2014 15:06:19 -0700 Subject: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: <93DBFD12-3A27-4F38-B3B6-98EE58F85B5E@oracle.com> References: <53C9559D.5070209@oracle.com> <93DBFD12-3A27-4F38-B3B6-98EE58F85B5E@oracle.com> Message-ID: <53CD8EDB.5090601@oracle.com> Yeah, I used "hg rename" to move the 3 files to their new location. Is there other way that I should handle the move? Valerie On 7/21/2014 8:12 AM, Vincent Ryan wrote: > Your fix looks good. > > BTW the Webrev doesn?t identify the 3 renamed files, did you use ?hg rename?? > > > On 18 Jul 2014, at 18:13, Valerie Peng wrote: > >> Vinnie, >> >> Could you please help reviewing this change? >> >> My current approach is to minimize code changes/refactoring - move the ECParameters, NamedCurve, CurveDB classes to sun.security.util package and then change the depending classes to use sun.security.util.XXX rather than sun.security.ec.XXX. >> >> Besides moving the 3 classes, I also changed some methods to public to be accessible from sun.security.ec package. >> >> webrev: http://cr.openjdk.java.net/~valeriep/8035166/webrev.00/ >> >> Thanks, >> Valerie >> From valerie.peng at oracle.com Mon Jul 21 22:33:21 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 21 Jul 2014 15:33:21 -0700 Subject: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: <53CD5985.6050803@oracle.com> References: <53C9559D.5070209@oracle.com> <53CD5985.6050803@oracle.com> Message-ID: <53CD9531.9090103@oracle.com> Done, webrev updated at http://cr.openjdk.java.net/~valeriep/8035166/webrev.01/ Thanks, Valerie On 7/21/2014 11:18 AM, Sean Mullan wrote: > Can you also change the following comment in > sun/security/ssl/SupportedEllipticCurvesExtension.java: > > // See sun.security.ec.NamedCurve for the OIDs > > to > > // See sun.security.util.NamedCurve for the OIDs > > Rest looks good to me. Please add a noreg label though. > > --Sean > > On 07/18/2014 01:13 PM, Valerie Peng wrote: >> Vinnie, >> >> Could you please help reviewing this change? >> >> My current approach is to minimize code changes/refactoring - move the >> ECParameters, NamedCurve, CurveDB classes to sun.security.util package >> and then change the depending classes to use sun.security.util.XXX >> rather than sun.security.ec.XXX. >> >> Besides moving the 3 classes, I also changed some methods to public to >> be accessible from sun.security.ec package. >> >> webrev: http://cr.openjdk.java.net/~valeriep/8035166/webrev.00/ >> >> Thanks, >> Valerie >> From weijun.wang at oracle.com Tue Jul 22 01:09:54 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 22 Jul 2014 09:09:54 +0800 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <53CD2D43.8020300@oracle.com> References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> <53C75299.3060007@oracle.com> <53CD2D43.8020300@oracle.com> Message-ID: <98FEFC40-00F0-43E2-B8F1-6464C0C4EF0B@oracle.com> On Jul 21, 2014, at 23:09, Alan Bateman wrote: > On 21/07/2014 09:22, Wang Weijun wrote: >> Please review the updated webrev at >> >> >> http://cr.openjdk.java.net/~weijun/8038089/webrev.01 >> >> >> Some comment changes. Some arguments rearrangement between classes. >> >> The interface is still in sun.security.ssl. It will be easy to move it to somewhere else later. When module is introduced, we may need to export the interface from java.base to java.security.jgss. >> >> > I'm skimmed over the changes (not a detailed review yet) and just want to check one thing - would I be correct to say that this isn't a general solution for plugging in addition cipher suites, the ServiceLoader usage in Krb5Helper looks specifically for a provider that supports TLS_KRB5_XXX from what I can establish. It's meant to be a general solution, and that's why I add a support() method. Said that, we have no idea what a non-KRB5 not-certificate-based cipher suite would look like. As for Krb5Helper, it's only used by KRB5 cipher suites. I don't want to modify too many SSL codes where the helper class is called like case KRB5: Krb5Helper.doXXX(); break; Ideally, it should be something like: case RSA: bla-bla-bla(); break; default: getHelper(ciphersuite).doXXX(); break; We will do this if we have more provider(s) later. > > One other thing about the ServiceLoader usage in Krb5Helper is that it's using the one-arg load method, hence the TCCL will be used to locate the cipher suite providers. As the provider is cached system-wide then I assume you meant to specify the system class loader here. Yes. > > The profiles build currently uses a simple dependency checker to ensure that there aren't any dependencies in a compact N build on something that is in a larger profile or the JRE. It allows a few exceptions, due to the need to keep jsse.jar and these are maintained in jdk/make/data/checkdeps/refs.allowed. I think this file will need to be updated to drop references to classes that no longer exist. I didn't know that file. Now only one line left there. > > A minor comment is that the new files are missing a copyright header, I assume you'll fix that up before pushing. Sure. Thanks Max > > -Alan. From Alan.Bateman at oracle.com Tue Jul 22 03:50:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jul 2014 04:50:53 +0100 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <98FEFC40-00F0-43E2-B8F1-6464C0C4EF0B@oracle.com> References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> <53C75299.3060007@oracle.com> <53CD2D43.8020300@oracle.com> <98FEFC40-00F0-43E2-B8F1-6464C0C4EF0B@oracle.com> Message-ID: <53CDDF9D.9080505@oracle.com> On 22/07/2014 02:09, Wang Weijun wrote: > : > > It's meant to be a general solution, and that's why I add a support() method. Said that, we have no idea what a non-KRB5 not-certificate-based cipher suite would look like. > > As for Krb5Helper, it's only used by KRB5 cipher suites. I don't want to modify too many SSL codes where the helper class is called like > > case KRB5: Krb5Helper.doXXX(); break; > > Ideally, it should be something like: > > case RSA: bla-bla-bla(); break; > default: getHelper(ciphersuite).doXXX(); break; > > We will do this if we have more provider(s) later. Okay, so it's a general interface but the only pluggability is KRB5 ciphers. > : >> The profiles build currently uses a simple dependency checker to ensure that there aren't any dependencies in a compact N build on something that is in a larger profile or the JRE. It allows a few exceptions, due to the need to keep jsse.jar and these are maintained in jdk/make/data/checkdeps/refs.allowed. I think this file will need to be updated to drop references to classes that no longer exist. > I didn't know that file. Now only one line left there. If it's the LogManager line then they can be removed too as it was missed by an early change in JDK 9 where that dependency was removed. -Alan From weijun.wang at oracle.com Tue Jul 22 05:51:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 22 Jul 2014 13:51:34 +0800 Subject: On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <53CDDF9D.9080505@oracle.com> References: <53A3C4A6.7030606@oracle.com> <780FD2A0-ADA6-4A77-ADBE-7FAA8AF8B866@oracle.com> <53A3D33C.9070009@oracle.com> <60040DD4-F887-45B0-85EE-678637B266CA@oracle.com> <53A3F4D9.4060102@oracle.com> <183BD754-34FB-4351-A25B-65A82830AA7B@oracle.com> <53A3FCFB.4090002@oracle.com> <215A6E73-07CA-44C1-87BB-934F420A666C@oracle.com> <53C3E241.5040606@oracle.com> <53C3F9AC.3040008@oracle.com> <53C75299.3060007@oracle.com> <53CD2D43.8020300@oracle.com> <98FEFC40-00F0-43E2-B8F1-6464C0C4EF0B@oracle.com> <53CDDF9D.9080505@oracle.com> Message-ID: <195E9572-C862-43B8-B983-D1A485FD6A09@oracle.com> On Jul 22, 2014, at 11:50, Alan Bateman wrote: > If it's the LogManager line then they can be removed too as it was missed by an early change in JDK 9 where that dependency was removed. # Residual references to java.beans. # The RemoveMethods tool does not yet purge the constant pool. # java.beans.PropertyChangeListener=java.util.logging.LogManager,compact1,compact2,compact3 From jason.uh at oracle.com Tue Jul 22 07:52:39 2014 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 22 Jul 2014 00:52:39 -0700 Subject: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName Message-ID: <53CE1847.90700@oracle.com> Hi Max, Could you please review this fix? http://cr.openjdk.java.net/~juh/8007706/webrev.00/ With the fix, the rules will be: 1. A DNSName must begin with a letter or a digit 2. After the first character, valid characters in DNSName components are letters, digits, hyphens, and underscores A couple minor formatting changes included. Thanks, Jason From fweimer at redhat.com Tue Jul 22 08:23:33 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 22 Jul 2014 10:23:33 +0200 Subject: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName In-Reply-To: <53CE1847.90700@oracle.com> References: <53CE1847.90700@oracle.com> Message-ID: <53CE1F85.1090907@redhat.com> On 07/22/2014 09:52 AM, Jason Uh wrote: > Hi Max, > > Could you please review this fix? > > http://cr.openjdk.java.net/~juh/8007706/webrev.00/ > > With the fix, the rules will be: > 1. A DNSName must begin with a letter or a digit > 2. After the first character, valid characters in DNSName components are > letters, digits, hyphens, and underscores The underscore bit violates the requirements of RFC 5280. Perhaps the RFC is wrong, but I think more justification is needed. The part which accepts leading digits is fine. Technically, there is a difference between domain names (sequences of dotted case-insensitive label blobs) and host names (labels must consist of letters and digits and hyphens, and start with a letter or digit). RFC 5280 says "domain name", but the references make it clear that "host names" are meant instead. It's not even clear if IA5String can encode backslashes, which would be needed to cover the entire range of valid domain names. -- Florian Weimer / Red Hat Product Security From rob.mckenna at oracle.com Tue Jul 22 13:37:47 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 22 Jul 2014 14:37:47 +0100 Subject: RFR: 8042982: Unexpected RuntimeExceptions being thrown by SSLEngine Message-ID: <53CE692B.9090802@oracle.com> Hi folks, A simple change to use SSLHandshakeException instead of RuntimeException in getAgreedSecret in DHCrypt and ECDHCrypt. This will prevent these RuntimeExceptions from propagating to the application and allow application programmers to handle them as SSLHandshakeExceptions. http://cr.openjdk.java.net/~robm/8042982/webrev.01/ -Rob From sean.mullan at oracle.com Tue Jul 22 13:44:55 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jul 2014 09:44:55 -0400 Subject: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: <53CD9531.9090103@oracle.com> References: <53C9559D.5070209@oracle.com> <53CD5985.6050803@oracle.com> <53CD9531.9090103@oracle.com> Message-ID: <53CE6AD7.8010305@oracle.com> Looks good. --Sean On 07/21/2014 06:33 PM, Valerie Peng wrote: > Done, webrev updated at > http://cr.openjdk.java.net/~valeriep/8035166/webrev.01/ > Thanks, > Valerie > > On 7/21/2014 11:18 AM, Sean Mullan wrote: >> Can you also change the following comment in >> sun/security/ssl/SupportedEllipticCurvesExtension.java: >> >> // See sun.security.ec.NamedCurve for the OIDs >> >> to >> >> // See sun.security.util.NamedCurve for the OIDs >> >> Rest looks good to me. Please add a noreg label though. >> >> --Sean >> >> On 07/18/2014 01:13 PM, Valerie Peng wrote: >>> Vinnie, >>> >>> Could you please help reviewing this change? >>> >>> My current approach is to minimize code changes/refactoring - move the >>> ECParameters, NamedCurve, CurveDB classes to sun.security.util package >>> and then change the depending classes to use sun.security.util.XXX >>> rather than sun.security.ec.XXX. >>> >>> Besides moving the 3 classes, I also changed some methods to public to >>> be accessible from sun.security.ec package. >>> >>> webrev: http://cr.openjdk.java.net/~valeriep/8035166/webrev.00/ >>> >>> Thanks, >>> Valerie >>> From rob.mckenna at oracle.com Tue Jul 22 17:44:47 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 22 Jul 2014 18:44:47 +0100 Subject: RFR: 8044659: Java SecureRandom on SPARC T4 much slower than on x86/Linux Message-ID: <53CEA30F.5070707@oracle.com> Hi folks, When repeatedly gathering small amounts of random data the SUN provider is quicker ucrypto / pkcs11. This proposed fix from Brad allows ucrypto / pkcs11 leverage the SUN SHA1 provider for SHA1PRNG. This allows us to avoid the overhead of calling into the native level repeatedly for small amounts of random data and allows ucrypto / pkcs11 to perform as well as SUN for this particular corner case. Testcase attached to the bug. http://cr.openjdk.java.net/~robm/8044659/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8044659 -Rob From sean.mullan at oracle.com Tue Jul 22 19:42:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jul 2014 15:42:18 -0400 Subject: RFR: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode Message-ID: <53CEBE9A.6020200@oracle.com> This is a fix for a test that was on the problem list. The fix is simple, I just changed the test to run in othervm mode, it was failing due to a classloader issue running in agentvm mode. Was able to get a clean jprt run on all systems. http://cr.openjdk.java.net/~mullan/webrevs/7147060/webrev.00/ Thanks, Sean From sean.mullan at oracle.com Tue Jul 22 19:59:47 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jul 2014 15:59:47 -0400 Subject: RFR: 8044659: Java SecureRandom on SPARC T4 much slower than on x86/Linux In-Reply-To: <53CEA30F.5070707@oracle.com> References: <53CEA30F.5070707@oracle.com> Message-ID: <53CEC2B3.5010909@oracle.com> Looks fine to me. --Sean On 07/22/2014 01:44 PM, Rob McKenna wrote: > Hi folks, > > When repeatedly gathering small amounts of random data the SUN provider > is quicker ucrypto / pkcs11. This proposed fix from Brad allows ucrypto > / pkcs11 leverage the SUN SHA1 provider for SHA1PRNG. This allows us to > avoid the overhead of calling into the native level repeatedly for small > amounts of random data and allows ucrypto / pkcs11 to perform as well as > SUN for this particular corner case. > > Testcase attached to the bug. > > http://cr.openjdk.java.net/~robm/8044659/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8044659 > > -Rob > From sean.coffey at oracle.com Tue Jul 22 21:45:13 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 22 Jul 2014 22:45:13 +0100 Subject: RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission Message-ID: <53CEDB69.7090106@oracle.com> A recent fix was introduced to preserve the behaviour of an old buggy implementation of smartcardio Card.disconnect : https://bugs.openjdk.java.net/browse/JDK-8049250 The old behaviour is not fully restored with this flag if a security manager lacking sufficient permissions is present. This could disrupt legacy applications which may wish to rely on the old behaviour. Some internal testing has also highlighted this. To enhance the 8049250 fix, I'm proposing we delay the boolean flip operation until post the security check. http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/ Bug report is not public due to internal links and servers being present in description. I'd like to get this into JDK 9 and 8u20. regards, Sean. From valerie.peng at oracle.com Tue Jul 22 23:23:05 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 22 Jul 2014 16:23:05 -0700 Subject: RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission In-Reply-To: <53CEDB69.7090106@oracle.com> References: <53CEDB69.7090106@oracle.com> Message-ID: <53CEF259.3070701@oracle.com> Well, I see your point. However, I am a little concerned that the security check isn't being performed in the old buggy impl. Is there any customer running into this, e.g. rely on the old behavior with security manager enabled? Valerie On 7/22/2014 2:45 PM, Se?n Coffey wrote: > A recent fix was introduced to preserve the behaviour of an old buggy > implementation of smartcardio Card.disconnect : > https://bugs.openjdk.java.net/browse/JDK-8049250 > > The old behaviour is not fully restored with this flag if a security > manager lacking sufficient permissions is present. This could disrupt > legacy applications which may wish to rely on the old behaviour. Some > internal testing has also highlighted this. > > To enhance the 8049250 fix, I'm proposing we delay the boolean flip > operation until post the security check. > http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/ > Bug report is not public due to internal links and servers being > present in description. > > I'd like to get this into JDK 9 and 8u20. > > regards, > Sean. From weijun.wang at oracle.com Wed Jul 23 02:28:06 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Jul 2014 10:28:06 +0800 Subject: RFR 6997010: Consolidate java.security files into one file with modifications Message-ID: Please review the code change at http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ The fix consolidates java.security- files into one with #ifdef directives. There are several major changes: 1. Creation of file is moved from CopyFiles to GenerateData, since we are really generating something now. Said that, the source data is kept in src/share/lib/security instead of make/data. I am OK with moving it if anyone desires. 2. The new tool MakeJavaSecurity includes the function of old AddToRestrictedPkgs. MakeJavaSecurity includes a new argument to deal with the platform dependent entries. The restricted.pkgs argument is also changed from a list of entries to a file name, so that we can also support the same #ifdef mechanism inside restricted.pkgs. 3. The new consolidated java.security supports #ifdef and #ifndef. It is not necessary to support #else or (and|or) of multiple #ifdef's now. 4. *IMPORTANT*: In order to easily maintain platform-related entries, every line (including the last line) in package.access and package.definition MUST end with ',\' now. A blank line MUST exist after the last line. This avoid ugly lines like #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 #endif The MakeJavaSecurity tool will strip the trailing ",\" from the last line to make the file exactly the same as before, although personally I don't think it's really necessary since the following empty line will terminate the entry automatically. Thanks Max From david.lloyd at redhat.com Wed Jul 23 04:26:21 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Jul 2014 23:26:21 -0500 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <535A72F0.3050800@oracle.com> References: <535A72F0.3050800@oracle.com> Message-ID: <53CF396D.4080208@redhat.com> On 04/25/2014 09:36 AM, Sean Mullan wrote: > Please review a draft of a proposed research JEP to improve the > performance of the Security Manager: I have another idea that might be worth looking into. One problem with security manager performance is that many times a class will perform privileged actions in the static initializer block. This is because static class initialization runs with whatever security context is active when that class happens to be initialized - it's essentially random as far as most developers are concerned, and even the experts cannot always correctly predict how initialization happens (see: last several years of java.util.logging class init debacle). This causes performance (and usability) problems because: ? Static init blocks can, for most practical purposes, never rely on their caller, so they must always perform privileged actions within doPrivileged ? This also results in another class to load and initialize ? Often, there is more than one data item needed from the privileged block, requiring either multiple doPrivileged calls (slow) or using hackery like returning an Object[] array out of the block I would suggest that one or more of the following be done to mitigate this problem: ? Always have static initialization blocks be privileged (this does require users to be cognizant of this fact when writing static blocks) ? Allow static initialization blocks to partake in the aforementioned annotation-driven privileged method idea ? Introduce a new permission checking mechanism which examines only a specific relevant caller's protection domain (perhaps determined by filter expression, possibly using the stack examination scheme that Mandy Chung has been working on) ? Introduce a programmatic "elevation" mechanism that increases the privileges of the currently executing method for the remainder of its execution without requiring a call-in to doPrivileged or instantiation of a privileged action object -- - DML From sean.coffey at oracle.com Wed Jul 23 08:15:54 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 23 Jul 2014 09:15:54 +0100 Subject: RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission In-Reply-To: <53CEF259.3070701@oracle.com> References: <53CEDB69.7090106@oracle.com> <53CEF259.3070701@oracle.com> Message-ID: <53CF6F3A.9020607@oracle.com> Valerie, I agree it's not ideal, but we're doing nothing different than what was performed in the old JDK releases...(i.e no check there either). I can't say if many applications would be impacted by the Card.disconnect change going into 8u20 but we should make best efforts to preserve the old legacy/buggy behaviour via the new sun.security.smartcardio.invertCardReset system property. If you disagree, we can launch a challenge against the TCK tests which are failing with this new property flag. regards, Sean. On 23/07/2014 00:23, Valerie Peng wrote: > > Well, I see your point. > However, I am a little concerned that the security check isn't being > performed in the old buggy impl. > Is there any customer running into this, e.g. rely on the old behavior > with security manager enabled? > Valerie > > On 7/22/2014 2:45 PM, Se?n Coffey wrote: >> A recent fix was introduced to preserve the behaviour of an old buggy >> implementation of smartcardio Card.disconnect : >> https://bugs.openjdk.java.net/browse/JDK-8049250 >> >> The old behaviour is not fully restored with this flag if a security >> manager lacking sufficient permissions is present. This could disrupt >> legacy applications which may wish to rely on the old behaviour. Some >> internal testing has also highlighted this. >> >> To enhance the 8049250 fix, I'm proposing we delay the boolean flip >> operation until post the security check. >> http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/ >> Bug report is not public due to internal links and servers being >> present in description. >> >> I'd like to get this into JDK 9 and 8u20. >> >> regards, >> Sean. From tom.hawtin at oracle.com Wed Jul 23 12:07:35 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Wed, 23 Jul 2014 13:07:35 +0100 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <53CF396D.4080208@redhat.com> References: <535A72F0.3050800@oracle.com> <53CF396D.4080208@redhat.com> Message-ID: <53CFA587.5080109@oracle.com> On 23/07/2014 05:26, David M. Lloyd wrote: > I would suggest that one or more of the following be done to mitigate > this problem: > > ? Always have static initialization blocks be privileged (this does > require users to be cognizant of this fact when writing static blocks) If we were following "secure by default", this would break it. It turns out having a static initaliser run with an unprivileged acc highlights code that is doing something naughty. > ? Allow static initialization blocks to partake in the aforementioned > annotation-driven privileged method idea Together with the last point, this does make the elevated privilege contain a wider block of code than is necessary. This is [particularly the case with static initialisers and initialisers where the code can be spread throughout the class. OTOH, relevant sections of code could be split out into small methods. > ? Introduce a new permission checking mechanism which examines only a > specific relevant caller's protection domain (perhaps determined by > filter expression, possibly using the stack examination scheme that > Mandy Chung has been working on) Immediate caller checking, though has similarities to link-time access checking, has a spectacularly unfortunate history. > ? Introduce a programmatic "elevation" mechanism that increases the > privileges of the currently executing method for the remainder of its > execution without requiring a call-in to doPrivileged or instantiation > of a privileged action object Tom From david.lloyd at redhat.com Wed Jul 23 13:40:34 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Jul 2014 08:40:34 -0500 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <53CFA587.5080109@oracle.com> References: <535A72F0.3050800@oracle.com> <53CF396D.4080208@redhat.com> <53CFA587.5080109@oracle.com> Message-ID: <53CFBB52.802@redhat.com> On 07/23/2014 07:07 AM, Tom Hawtin wrote: > On 23/07/2014 05:26, David M. Lloyd wrote: >> I would suggest that one or more of the following be done to mitigate >> this problem: >> >> ? Always have static initialization blocks be privileged (this does >> require users to be cognizant of this fact when writing static blocks) > > If we were following "secure by default", this would break it. It turns > out having a static initaliser run with an unprivileged acc highlights > code that is doing something naughty. I thought this mindset might dominate, which is unfortunate. In practice, it is far better for code to be predictable, concise, and clear. It does not really make any sense to have random security contexts in place and then call it "secure"; it makes more sense to just tell people "hey your static initializers are privileged". It's not like normal directly invokable methods where the user can pass in arguments and get return values from code that runs in a privileged context. It is very, very unusual for a static initializer to perform any function which is practically exploitable; they are generally stateless already, taking no input and producing no output. I don't think that it can be shown that the blanket ideology really provides any measurable, real-world benefit; on the contrary, it causes real, measurable detriment. I don't think anyone ever said "Oh, it's a good thing I got that AccessControlException in my static initializer; now I know that doing XYZ needed a privileged block". Nevertheless, I never actually expected to convince anyone of this - it's one of those ideas which seems culturally "against the grain", i.e. the general principle tends to outweigh the practical reality. Still, I had to propose it, in order to be right with myself. :-) >> ? Allow static initialization blocks to partake in the aforementioned >> annotation-driven privileged method idea > > Together with the last point, this does make the elevated privilege > contain a wider block of code than is necessary. This is [particularly > the case with static initialisers and initialisers where the code can be > spread throughout the class. OTOH, relevant sections of code could be > split out into small methods. Exactly - in this case I would even expect that you could separately annotate each static init with its privileges. The important thing would still be that the compiler can do this without constructing a new class for each chunk (or even a lambda if it could be avoided). >> ? Introduce a new permission checking mechanism which examines only a >> specific relevant caller's protection domain (perhaps determined by >> filter expression, possibly using the stack examination scheme that >> Mandy Chung has been working on) > > Immediate caller checking, though has similarities to link-time access > checking, has a spectacularly unfortunate history. That is an observation. :-) >> ? Introduce a programmatic "elevation" mechanism that increases the >> privileges of the currently executing method for the remainder of its >> execution without requiring a call-in to doPrivileged or instantiation >> of a privileged action object > > Tom -- - DML From valerie.peng at oracle.com Wed Jul 23 16:51:04 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 23 Jul 2014 09:51:04 -0700 Subject: RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission In-Reply-To: <53CF6F3A.9020607@oracle.com> References: <53CEDB69.7090106@oracle.com> <53CEF259.3070701@oracle.com> <53CF6F3A.9020607@oracle.com> Message-ID: <53CFE7F8.4020709@oracle.com> Do you know which TCK tests fail? I want to check it out. Thanks, Valerie On 7/23/2014 1:15 AM, Se?n Coffey wrote: > Valerie, > > I agree it's not ideal, but we're doing nothing different than what > was performed in the old JDK releases...(i.e no check there either). I > can't say if many applications would be impacted by the > Card.disconnect change going into 8u20 but we should make best efforts > to preserve the old legacy/buggy behaviour via the new > sun.security.smartcardio.invertCardReset system property. > > If you disagree, we can launch a challenge against the TCK tests which > are failing with this new property flag. > > regards, > Sean. > > On 23/07/2014 00:23, Valerie Peng wrote: >> >> Well, I see your point. >> However, I am a little concerned that the security check isn't being >> performed in the old buggy impl. >> Is there any customer running into this, e.g. rely on the old >> behavior with security manager enabled? >> Valerie >> >> On 7/22/2014 2:45 PM, Se?n Coffey wrote: >>> A recent fix was introduced to preserve the behaviour of an old >>> buggy implementation of smartcardio Card.disconnect : >>> https://bugs.openjdk.java.net/browse/JDK-8049250 >>> >>> The old behaviour is not fully restored with this flag if a security >>> manager lacking sufficient permissions is present. This could >>> disrupt legacy applications which may wish to rely on the old >>> behaviour. Some internal testing has also highlighted this. >>> >>> To enhance the 8049250 fix, I'm proposing we delay the boolean flip >>> operation until post the security check. >>> http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/ >>> Bug report is not public due to internal links and servers being >>> present in description. >>> >>> I'd like to get this into JDK 9 and 8u20. >>> >>> regards, >>> Sean. > From valerie.peng at oracle.com Wed Jul 23 17:01:50 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 23 Jul 2014 10:01:50 -0700 Subject: RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission In-Reply-To: <53CFE7F8.4020709@oracle.com> References: <53CEDB69.7090106@oracle.com> <53CEF259.3070701@oracle.com> <53CF6F3A.9020607@oracle.com> <53CFE7F8.4020709@oracle.com> Message-ID: <53CFEA7E.5090807@oracle.com> I looked at the tests and thought about it some more. I agree that it makes sense to defer the check to post the security check. Changes look fine. Thanks, Valerie On 7/23/2014 9:51 AM, Valerie Peng wrote: > > Do you know which TCK tests fail? I want to check it out. > Thanks, > Valerie > > On 7/23/2014 1:15 AM, Se?n Coffey wrote: >> Valerie, >> >> I agree it's not ideal, but we're doing nothing different than what >> was performed in the old JDK releases...(i.e no check there either). >> I can't say if many applications would be impacted by the >> Card.disconnect change going into 8u20 but we should make best >> efforts to preserve the old legacy/buggy behaviour via the new >> sun.security.smartcardio.invertCardReset system property. >> >> If you disagree, we can launch a challenge against the TCK tests >> which are failing with this new property flag. >> >> regards, >> Sean. >> >> On 23/07/2014 00:23, Valerie Peng wrote: >>> >>> Well, I see your point. >>> However, I am a little concerned that the security check isn't being >>> performed in the old buggy impl. >>> Is there any customer running into this, e.g. rely on the old >>> behavior with security manager enabled? >>> Valerie >>> >>> On 7/22/2014 2:45 PM, Se?n Coffey wrote: >>>> A recent fix was introduced to preserve the behaviour of an old >>>> buggy implementation of smartcardio Card.disconnect : >>>> https://bugs.openjdk.java.net/browse/JDK-8049250 >>>> >>>> The old behaviour is not fully restored with this flag if a >>>> security manager lacking sufficient permissions is present. This >>>> could disrupt legacy applications which may wish to rely on the old >>>> behaviour. Some internal testing has also highlighted this. >>>> >>>> To enhance the 8049250 fix, I'm proposing we delay the boolean flip >>>> operation until post the security check. >>>> http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/ >>>> Bug report is not public due to internal links and servers being >>>> present in description. >>>> >>>> I'd like to get this into JDK 9 and 8u20. >>>> >>>> regards, >>>> Sean. >> From mala.bankal at oracle.com Thu Jul 24 08:54:41 2014 From: mala.bankal at oracle.com (mala bankal) Date: Thu, 24 Jul 2014 14:24:41 +0530 Subject: Request review for backport of bug#8036709 to 7u-dev Message-ID: <53D0C9D1.3@oracle.com> Hi, Request review for the direct backport of bug#8036709 from 9/8 to 7u-dev. http://cr.openjdk.java.net/~mbankal/8036709/webrev.00/ JDK9 changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d1978cf32bc1 JDK8 changeset : http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/2aa925ce9852 Thanks. rgds mala From weijun.wang at oracle.com Thu Jul 24 08:59:10 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 24 Jul 2014 16:59:10 +0800 Subject: Request review for backport of bug#8036709 to 7u-dev In-Reply-To: <53D0C9D1.3@oracle.com> References: <53D0C9D1.3@oracle.com> Message-ID: Code change looks fine. Thanks for taking care of this. --Max On Jul 24, 2014, at 16:54, mala bankal wrote: > Hi, > > Request review for the direct backport of bug#8036709 from 9/8 to 7u-dev. > > http://cr.openjdk.java.net/~mbankal/8036709/webrev.00/ > > JDK9 changeset : > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d1978cf32bc1 > JDK8 changeset : > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/2aa925ce9852 > > Thanks. > rgds > mala > From tom.hawtin at oracle.com Thu Jul 24 09:17:34 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Thu, 24 Jul 2014 10:17:34 +0100 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <53CFBB52.802@redhat.com> References: <535A72F0.3050800@oracle.com> <53CF396D.4080208@redhat.com> <53CFA587.5080109@oracle.com> <53CFBB52.802@redhat.com> Message-ID: <53D0CF2E.7040706@oracle.com> On 23/07/2014 14:40, David M. Lloyd wrote: > On 07/23/2014 07:07 AM, Tom Hawtin wrote: >> On 23/07/2014 05:26, David M. Lloyd wrote: >>> ? Always have static initialization blocks be privileged (this does >>> require users to be cognizant of this fact when writing static blocks) >> >> If we were following "secure by default", this would break it. It turns >> out having a static initaliser run with an unprivileged acc highlights >> code that is doing something naughty. > > I thought this mindset might dominate, which is unfortunate. In > practice, it is far better for code to be predictable, concise, and > clear. It does not really make any sense to have random security > contexts in place and then call it "secure"; it makes more sense to just > tell people "hey your static initializers are privileged". I'm not suggesting that the random context is a good design. ("Random" in the sense that an adversary can often arrange for a trusted context when the code expects typical untrusted.) Years ago I suggested the same thing. I'm glad that it was rejected due to subsequent experience and a bit of reflection. > It's not > like normal directly invokable methods where the user can pass in > arguments and get return values from code that runs in a privileged > context. [...] Static initialisers deal with globals, and they're a bit worse than arguments. > I don't think anyone ever said "Oh, it's a good > thing I got that AccessControlException in my static initializer; now I > know that doing XYZ needed a privileged block". You don't need "in my static initializer" in that sentence. > > Exactly - in this case I would even expect that you could separately > annotate each static init with its privileges. The important thing > would still be that the compiler can do this without constructing a new > class for each chunk (or even a lambda if it could be avoided). I guess you could do that by generating synthetic methods where necessary. Tom From weijun.wang at oracle.com Fri Jul 25 01:51:16 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 25 Jul 2014 09:51:16 +0800 Subject: RFR 8051953: Add Unreachable.java test to ProblemList on Windows Message-ID: <143FC365-E79F-4EA5-9D45-45D67F0C2C48@oracle.com> Please review the code change at http://cr.openjdk.java.net/~weijun/8051953/webrev.00/test/ProblemList.txt.udiff.html which add one item into test/ProblemList.txt +# 8051952: Unreachable.java test failing on Windows +sun/security/krb5/auto/Unreachable.java windows-all The test started failing since July 13 on multiple test machines. The reason is that a UDP receive() call does not throw an UnreachablePortException. Microsoft's own portqry.exe also cannot receive the ICMP destination unreachable message. This might be due to a change of network configuration. Thanks Max From chris.hegarty at oracle.com Fri Jul 25 09:01:34 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Jul 2014 10:01:34 +0100 Subject: RFR 8051953: Add Unreachable.java test to ProblemList on Windows In-Reply-To: <143FC365-E79F-4EA5-9D45-45D67F0C2C48@oracle.com> References: <143FC365-E79F-4EA5-9D45-45D67F0C2C48@oracle.com> Message-ID: <53D21CEE.6030207@oracle.com> Looks good Max. -Chris. On 25/07/14 02:51, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8051953/webrev.00/test/ProblemList.txt.udiff.html > > which add one item into test/ProblemList.txt > > +# 8051952: Unreachable.java test failing on Windows > +sun/security/krb5/auto/Unreachable.java windows-all > > The test started failing since July 13 on multiple test machines. The reason is that a UDP receive() call does not throw an UnreachablePortException. Microsoft's own portqry.exe also cannot receive the ICMP destination unreachable message. > > This might be due to a change of network configuration. > > Thanks > Max > From sean.mullan at oracle.com Fri Jul 25 11:20:55 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Jul 2014 07:20:55 -0400 Subject: RFR 8051953: Add Unreachable.java test to ProblemList on Windows In-Reply-To: <143FC365-E79F-4EA5-9D45-45D67F0C2C48@oracle.com> References: <143FC365-E79F-4EA5-9D45-45D67F0C2C48@oracle.com> Message-ID: <53D23D97.7080905@oracle.com> On 07/24/2014 09:51 PM, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8051953/webrev.00/test/ProblemList.txt.udiff.html > > which add one item into test/ProblemList.txt > > +# 8051952: Unreachable.java test failing on Windows > +sun/security/krb5/auto/Unreachable.java windows-all 8051952 is closed though. There should ideally be an open bug to track its eventual removal from the ProblemList. > > The test started failing since July 13 on multiple test machines. The reason is that a UDP receive() call does not throw an UnreachablePortException. Microsoft's own portqry.exe also cannot receive the ICMP destination unreachable message. Can this test ever come off the problem list? If so, I think there should be an open bug to track that. If not, I think we should adjust the test itself to not run on Windows or work around the exception if possible. --Sean > > This might be due to a change of network configuration. > > Thanks > Max > From weijun.wang at oracle.com Fri Jul 25 11:29:27 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 25 Jul 2014 19:29:27 +0800 Subject: RFR 8051953: Add Unreachable.java test to ProblemList on Windows In-Reply-To: <53D23D97.7080905@oracle.com> References: <143FC365-E79F-4EA5-9D45-45D67F0C2C48@oracle.com> <53D23D97.7080905@oracle.com> Message-ID: <09D4EA46-3446-45BA-82AD-C967B505C4DA@oracle.com> On Jul 25, 2014, at 19:20, Sean Mullan wrote: > On 07/24/2014 09:51 PM, Wang Weijun wrote: >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8051953/webrev.00/test/ProblemList.txt.udiff.html >> >> which add one item into test/ProblemList.txt >> >> +# 8051952: Unreachable.java test failing on Windows >> +sun/security/krb5/auto/Unreachable.java windows-all > > 8051952 is closed though. There should ideally be an open bug to track its eventual removal from the ProblemList. I meant to reopen it later. It was closed because I can do nothing and it's only a noise. > >> >> The test started failing since July 13 on multiple test machines. The reason is that a UDP receive() call does not throw an UnreachablePortException. Microsoft's own portqry.exe also cannot receive the ICMP destination unreachable message. > > Can this test ever come off the problem list? If so, I think there should be an open bug to track that. If not, I think we should adjust the test itself to not run on Windows or work around the exception if possible. If my opinion, the current config we see is abnormal. I'd like to remove it from problem list one day. --Max > > --Sean > >> >> This might be due to a change of network configuration. >> >> Thanks >> Max >> From sean.mullan at oracle.com Fri Jul 25 14:00:20 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Jul 2014 10:00:20 -0400 Subject: RFR 8051953: Add Unreachable.java test to ProblemList on Windows In-Reply-To: <09D4EA46-3446-45BA-82AD-C967B505C4DA@oracle.com> References: <143FC365-E79F-4EA5-9D45-45D67F0C2C48@oracle.com> <53D23D97.7080905@oracle.com> <09D4EA46-3446-45BA-82AD-C967B505C4DA@oracle.com> Message-ID: <53D262F4.1000304@oracle.com> On 07/25/2014 07:29 AM, Wang Weijun wrote: > > On Jul 25, 2014, at 19:20, Sean Mullan wrote: > >> On 07/24/2014 09:51 PM, Wang Weijun wrote: >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8051953/webrev.00/test/ProblemList.txt.udiff.html >>> >>> which add one item into test/ProblemList.txt >>> >>> +# 8051952: Unreachable.java test failing on Windows >>> +sun/security/krb5/auto/Unreachable.java windows-all >> >> 8051952 is closed though. There should ideally be an open bug to track its eventual removal from the ProblemList. > > I meant to reopen it later. It was closed because I can do nothing and it's only a noise. I would suggest to keep it open and add a teststabilization label. --Sean > >> >>> >>> The test started failing since July 13 on multiple test machines. The reason is that a UDP receive() call does not throw an UnreachablePortException. Microsoft's own portqry.exe also cannot receive the ICMP destination unreachable message. >> >> Can this test ever come off the problem list? If so, I think there should be an open bug to track that. If not, I think we should adjust the test itself to not run on Windows or work around the exception if possible. > > If my opinion, the current config we see is abnormal. I'd like to remove it from problem list one day. > > --Max > >> >> --Sean >> >>> >>> This might be due to a change of network configuration. >>> >>> Thanks >>> Max >>> > From sean.mullan at oracle.com Fri Jul 25 14:30:59 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Jul 2014 10:30:59 -0400 Subject: RFR 6997010: Consolidate java.security files into one file with modifications In-Reply-To: References: Message-ID: <53D26A23.2010806@oracle.com> On 07/22/2014 10:28 PM, Wang Weijun wrote: > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ > > The fix consolidates java.security- files into one with > #ifdef directives. > > There are several major changes: > > 1. Creation of file is moved from CopyFiles to GenerateData, since we > are really generating something now. Said that, the source data is > kept in src/share/lib/security instead of make/data. I am OK with > moving it if anyone desires. > > 2. The new tool MakeJavaSecurity includes the function of old > AddToRestrictedPkgs. MakeJavaSecurity includes a new argument to deal > with the platform dependent entries. The restricted.pkgs argument is > also changed from a list of entries to a file name, so that we can > also support the same #ifdef mechanism inside restricted.pkgs. > > 3. The new consolidated java.security supports #ifdef and #ifndef. It > is not necessary to support #else or (and|or) of multiple #ifdef's > now. > > 4. *IMPORTANT*: In order to easily maintain platform-related entries, > every line (including the last line) in package.access and > package.definition MUST end with ',\' now. A blank line MUST exist > after the last line. This avoid ugly lines like > > #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 > #endif What happens if someone (inevitably) adds a new package to the list and forgets to do either of these? Does it result in a build failure? Otherwise looks good, although I think it would be useful to write an additional test to make sure the correct providers are installed and ordered correctly on the different platforms, something similar to the java/lang/SecurityManager/CheckPackageAccess.java test but specific to providers. Thanks for doing this, it will really help maintaining this file going forward! --Sean > > The MakeJavaSecurity tool will strip the trailing ",\" from the last > line to make the file exactly the same as before, although personally > I don't think it's really necessary since the following empty line > will terminate the entry automatically. > > Thanks Max > From weijun.wang at oracle.com Fri Jul 25 14:44:42 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 25 Jul 2014 22:44:42 +0800 Subject: RFR 6997010: Consolidate java.security files into one file with modifications In-Reply-To: <53D26A23.2010806@oracle.com> References: <53D26A23.2010806@oracle.com> Message-ID: On Jul 25, 2014, at 22:30, Sean Mullan wrote: >> http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ >> >> 4. *IMPORTANT*: In order to easily maintain platform-related entries, >> every line (including the last line) in package.access and >> package.definition MUST end with ',\' now. A blank line MUST exist >> after the last line. This avoid ugly lines like >> >> #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 >> #endif > > What happens if someone (inevitably) adds a new package to the list and forgets to do either of these? Does it result in a build failure? No build failure, but test/java/security/SecurityManager/CheckPackageAccess.java will fail. I can add check in the build tool. > > Otherwise looks good, although I think it would be useful to write an additional test to make sure the correct providers are installed and ordered correctly on the different platforms, something similar to the java/lang/SecurityManager/CheckPackageAccess.java test but specific to providers. OK. Thanks Max From sean.mullan at oracle.com Fri Jul 25 14:47:15 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Jul 2014 10:47:15 -0400 Subject: Policy provider comparison In-Reply-To: <53CB2438.8040300@zeus.net.au> References: <53CA2CD7.7010301@zeus.net.au> <53CB2438.8040300@zeus.net.au> Message-ID: <53D26DF3.6000008@oracle.com> On 07/19/2014 10:06 PM, Peter Firmstone wrote: > There doesn't seem to be much interest in adopting an external policy > provider, so I'll explain how to achieve a significant performance > improvement, in case someone's interested in improving performance of > the default jvm policy provider. > > 1. Thread confine and immediately discard PermissionCollection > objects, do not cache them as is done presently. Did you consider storing the PermissionCollection objects in a ConcurrentHashMap (instead of the current Collections.synchronizedMap)? My jmh benchmark (with 5 threads where each thread has its own ProtectionDomain) shows a ~3x increase in throughput of Policy.implies with just this change. I plan to try the thread confinement approach next. --Sean > 2. We created an object representation of grant statements from > policy files in memory, it is immutable and replaced during policy > refresh calls, it is also non blocking and highly scalable. > 3. During a policy implies call, collect all grant statements that > imply a ProtectionDomain from an implies call. Take Permission > objects from the grant statements and add them to > PermissionCollection and Permissions (a heterogenous collection of > PermissionCollection objects, itself an instance of > PermissionCollection). Determine the result of the implies call > and discard the Permissions, do not cache or share them with other > threads. > 4. Sort Permission objects before adding them to ProtectionDomain, to > minimise unnecessary DNS calls from SocketPermission etc. > 5. Do not add Permissions to a ProtectionDomain that delegates to the > Policy provider, or Permissions may be checked twice. > 6. Only add Permissions to ProtectionDomain's when they have > AllPermissions or when it does not delegate to a Policy provider. > > PermissionCollection was designed to be threadsafe, I think this was a > mistake (hindsight is 20:20), similar to HashTable and Vector, > PermissionCollection instances should be thread confined (uncontended > synchronization is fast). Permissions has a race condition that > prevents UnresolvedPermission's from resolving on occassion too, thread > confinement fixes that too. > > Regards, > > Peter. > > On 19/07/2014 6:31 PM, Peter Firmstone wrote: >> Thought I might provide a comparison using our random stress test on a >> 4 way sony vaio, JDK7 Windows 7 amd64: >> >> Note that using sun.security.provider.PolicyFile doubles the duration >> of the stress test and it consumes 73% of CPU. >> >> In comparison org.apache.river.api.security.ConcurrentPolicyFile uses >> 0% CPU and the test completes in half the time, with our policy >> provider we run at raw socket speed. >> >> See attached. >> >> Regards, >> >> Peter. > From xuelei.fan at oracle.com Sat Jul 26 00:52:03 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Jul 2014 08:52:03 +0800 Subject: RFR: 8042982: Unexpected RuntimeExceptions being thrown by SSLEngine In-Reply-To: <53CE692B.9090802@oracle.com> References: <53CE692B.9090802@oracle.com> Message-ID: <53D2FBB3.8000609@oracle.com> Looks fine to me. Thanks, Xuelei On 7/22/2014 9:37 PM, Rob McKenna wrote: > Hi folks, > > A simple change to use SSLHandshakeException instead of RuntimeException > in getAgreedSecret in DHCrypt and ECDHCrypt. This will prevent these > RuntimeExceptions from propagating to the application and allow > application programmers to handle them as SSLHandshakeExceptions. > > http://cr.openjdk.java.net/~robm/8042982/webrev.01/ > > -Rob > From xuelei.fan at oracle.com Sat Jul 26 01:25:12 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Jul 2014 09:25:12 +0800 Subject: RFR: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode In-Reply-To: <53CEBE9A.6020200@oracle.com> References: <53CEBE9A.6020200@oracle.com> Message-ID: <53D30378.5040303@oracle.com> Looks fine to me. Xuelei On 7/23/2014 3:42 AM, Sean Mullan wrote: > This is a fix for a test that was on the problem list. The fix is > simple, I just changed the test to run in othervm mode, it was failing > due to a classloader issue running in agentvm mode. Was able to get a > clean jprt run on all systems. > > http://cr.openjdk.java.net/~mullan/webrevs/7147060/webrev.00/ > > Thanks, > Sean From weijun.wang at oracle.com Mon Jul 28 01:44:27 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 28 Jul 2014 09:44:27 +0800 Subject: RFR 6997010: Consolidate java.security files into one file with modifications In-Reply-To: References: <53D26A23.2010806@oracle.com> Message-ID: <902FCDAA-E90B-4677-836C-D294D725FB45@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/6997010/webrev.01/ New test CheckSecurityProvider.java, and updates to MakeJavaSecurity.addPackages(). Thanks Max On Jul 25, 2014, at 22:44, Wang Weijun wrote: > > On Jul 25, 2014, at 22:30, Sean Mullan wrote: > >>> http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ >>> >>> 4. *IMPORTANT*: In order to easily maintain platform-related entries, >>> every line (including the last line) in package.access and >>> package.definition MUST end with ',\' now. A blank line MUST exist >>> after the last line. This avoid ugly lines like >>> >>> #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 >>> #endif >> >> What happens if someone (inevitably) adds a new package to the list and forgets to do either of these? Does it result in a build failure? > > No build failure, but test/java/security/SecurityManager/CheckPackageAccess.java will fail. > > I can add check in the build tool. > >> >> Otherwise looks good, although I think it would be useful to write an additional test to make sure the correct providers are installed and ordered correctly on the different platforms, something similar to the java/lang/SecurityManager/CheckPackageAccess.java test but specific to providers. > > OK. > > Thanks > Max > From rajan.halade at oracle.com Mon Jul 28 07:15:57 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 28 Jul 2014 00:15:57 -0700 Subject: [JDK-9] RFR: 8041787: Need new regressions tests for buffer handling for PBE algorithms Message-ID: <53D5F8AD.2060804@oracle.com> May I request you to review these 4 new tests to be added for PBE keys. New tests are added to address following: - same buffer can be used for encrypt and decrypt with PBE - Mac update works correctly with different size of ByteBuffer - doFinal and update operation result in same PBMac - for PBEWithMD5AndDES cipher, only CBC mode and PKCS#5Padding is allowed JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8041787 Webrev: http://cr.openjdk.java.net/~rhalade/8041787/webrev.00/ Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghu.k.nair at oracle.com Mon Jul 28 08:07:40 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Mon, 28 Jul 2014 13:37:40 +0530 Subject: Review request for CR 8048362 Test doPrivileged with accomplice Message-ID: <53D604CC.9090502@oracle.com> Hello, Please review the test for doPrivliaged with accomplice. Bug - https://bugs.openjdk.java.net/browse/JDK-8048362 webrev- http://cr.openjdk.java.net/~rhalade/8048362/webrev.00/ Thanks, Raghu Nair From raghu.k.nair at oracle.com Mon Jul 28 08:20:34 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Mon, 28 Jul 2014 13:50:34 +0530 Subject: Review request for CR 8049233 Need new tests for testing openssl created certificate Message-ID: <53D607D2.7040809@oracle.com> Hello, Please review the tests for openssl generated certificates and CRLS. This tests java.security.cert.Certificate.verify() method and behaviors of the following classes java.security.X509CRL, java.security.X509CRLSelector, java.security.X509CRLRevocationReason and java.security.X509Certificate. Bug - |https://bugs.openjdk.java.net/browse/JDK-8049233| webrev- http://cr.openjdk.java.net/~rhalade/8049233/webrev.00/ Thanks, Raghu Nair -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.yang at oracle.com Mon Jul 28 08:57:43 2014 From: felix.yang at oracle.com (FELIX YANG) Date: Mon, 28 Jul 2014 16:57:43 +0800 Subject: RFR 8043836: Need new tests for AES cipher Message-ID: <53D61087.6030008@oracle.com> May I request you to review these 6 new tests to be added for AES cipher. New tests are added to address following: - Test AES for different modes and padding schemes - Test AES encryption with no padding - same buffer can be used for encrypt and decrypt with AES JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8043836 Webrev: http://cr.openjdk.java.net/~rhalade/8043836/webrev.00/ Thanks, From felix.yang at oracle.com Mon Jul 28 09:04:40 2014 From: felix.yang at oracle.com (FELIX YANG) Date: Mon, 28 Jul 2014 17:04:40 +0800 Subject: RFR 8048052: Permission tests for "setFactory" In-Reply-To: <53D61087.6030008@oracle.com> References: <53D61087.6030008@oracle.com> Message-ID: <53D61228.5030307@oracle.com> Please review a new test to "setFactory" permission. It is to address that "setFactory" permission is required or not as expected in a series of classes/methods under java.net. JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048052 Webrev: http://cr.openjdk.java.net/~rhalade/8048052/webrev.00/ Thanks -Felix From erik.joelsson at oracle.com Mon Jul 28 11:43:30 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Jul 2014 13:43:30 +0200 Subject: RFR 6997010: Consolidate java.security files into one file with modifications In-Reply-To: <902FCDAA-E90B-4677-836C-D294D725FB45@oracle.com> References: <53D26A23.2010806@oracle.com> <902FCDAA-E90B-4677-836C-D294D725FB45@oracle.com> Message-ID: <53D63762.3040200@oracle.com> Hello Max, Shouldn't the rule for $(GENDATA_JAVA_SECURITY) depend on $(RESTRICTED_PKGS_SRC) so that updates to the pkgs file triggers a rebuild? For that to work, the variable $(RESTRICTED_PKGS_SRC) needs to be empty for the OPENJDK case rather than have a dummy name and MakeJavaSecurity.java needs to handle missing the last argument. /Erik On 2014-07-28 03:44, Wang Weijun wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/6997010/webrev.01/ > > New test CheckSecurityProvider.java, and updates to MakeJavaSecurity.addPackages(). > > Thanks > Max > > On Jul 25, 2014, at 22:44, Wang Weijun wrote: > >> On Jul 25, 2014, at 22:30, Sean Mullan wrote: >> >>>> http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ >>>> >>>> 4. *IMPORTANT*: In order to easily maintain platform-related entries, >>>> every line (including the last line) in package.access and >>>> package.definition MUST end with ',\' now. A blank line MUST exist >>>> after the last line. This avoid ugly lines like >>>> >>>> #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 >>>> #endif >>> What happens if someone (inevitably) adds a new package to the list and forgets to do either of these? Does it result in a build failure? >> No build failure, but test/java/security/SecurityManager/CheckPackageAccess.java will fail. >> >> I can add check in the build tool. >> >>> Otherwise looks good, although I think it would be useful to write an additional test to make sure the correct providers are installed and ordered correctly on the different platforms, something similar to the java/lang/SecurityManager/CheckPackageAccess.java test but specific to providers. >> OK. >> >> Thanks >> Max >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1983-01-06 at gmx.net Mon Jul 28 13:16:23 2014 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Mon, 28 Jul 2014 15:16:23 +0200 Subject: getKDCFromDNS called too often Message-ID: Hi folks, I am experiencing a performance degregation when JGSS tries to locate a KDC via DNS. We have for our default realm 120 KDCs running. My Java code performs a SASL bind with Kerberos (keytab) to get some data from AD over LDAP. This takes sometimes minutes to do where weeks ago mere seconds were necessary. It seems now we have the double amount of KDCs and this is the problem with JGSS. I can see that the roundtrips with the KDC like AS-REQ, preauth required, AS-REQ, AS-REP, TGS-REQ, TGS-REP, etc. are always preceeded by a getKDCFromDNS. A grep and wc -l over my logfile shows 110 roundtrips for KDC lookup. This is insane. The request time and payload slow down the entire operation. Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working? I have to disable the DNS resolution for Java temporarily. Michael From david.lloyd at redhat.com Mon Jul 28 13:34:01 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 28 Jul 2014 08:34:01 -0500 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <53D0CF2E.7040706@oracle.com> References: <535A72F0.3050800@oracle.com> <53CF396D.4080208@redhat.com> <53CFA587.5080109@oracle.com> <53CFBB52.802@redhat.com> <53D0CF2E.7040706@oracle.com> Message-ID: <53D65149.8030504@redhat.com> On 07/24/2014 04:17 AM, Tom Hawtin wrote: > On 23/07/2014 14:40, David M. Lloyd wrote: >> On 07/23/2014 07:07 AM, Tom Hawtin wrote: >>> On 23/07/2014 05:26, David M. Lloyd wrote: > >>>> ? Always have static initialization blocks be privileged (this does >>>> require users to be cognizant of this fact when writing static blocks) >>> >>> If we were following "secure by default", this would break it. It turns >>> out having a static initaliser run with an unprivileged acc highlights >>> code that is doing something naughty. >> >> I thought this mindset might dominate, which is unfortunate. In >> practice, it is far better for code to be predictable, concise, and >> clear. It does not really make any sense to have random security >> contexts in place and then call it "secure"; it makes more sense to just >> tell people "hey your static initializers are privileged". > > I'm not suggesting that the random context is a good design. ("Random" > in the sense that an adversary can often arrange for a trusted context > when the code expects typical untrusted.) Years ago I suggested the same > thing. I'm glad that it was rejected due to subsequent experience and a > bit of reflection. Logically speaking there is no weakness here though. In order to do privileged things (in static init), you must use a privileged block. You must always assume that the context is random (because it is). Thus static blocks are already using privileged blocks. There is no meaningful way (in a static init) to test that a caller has permission to cause a class to initialize. Therefore every privileged block is superfluous and wasteful. There is no logically provable benefit to requiring the privileged block on static init - only superstition. There is no attack vector here that is not already here. >> It's not >> like normal directly invokable methods where the user can pass in >> arguments and get return values from code that runs in a privileged >> context. [...] > > Static initialisers deal with globals, and they're a bit worse than > arguments. That generalization is meaningless. >> I don't think anyone ever said "Oh, it's a good >> thing I got that AccessControlException in my static initializer; now I >> know that doing XYZ needed a privileged block". > > You don't need "in my static initializer" in that sentence. This is also meaningless. >> >> Exactly - in this case I would even expect that you could separately >> annotate each static init with its privileges. The important thing >> would still be that the compiler can do this without constructing a new >> class for each chunk (or even a lambda if it could be avoided). > > I guess you could do that by generating synthetic methods where necessary. Not sure how or why that helps? -- - DML From weijun.wang at oracle.com Mon Jul 28 13:53:31 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 28 Jul 2014 21:53:31 +0800 Subject: RFR 6997010: Consolidate java.security files into one file with modifications In-Reply-To: <53D63762.3040200@oracle.com> References: <53D26A23.2010806@oracle.com> <902FCDAA-E90B-4677-836C-D294D725FB45@oracle.com> <53D63762.3040200@oracle.com> Message-ID: Yes, you are right. Webrev updated at http://cr.openjdk.java.net/~weijun/6997010/webrev.02. GendataJavaSecurity.gmk and MakeJavaSecurity.java updated. Thanks Max On Jul 28, 2014, at 19:43, Erik Joelsson wrote: > Hello Max, > > Shouldn't the rule for $(GENDATA_JAVA_SECURITY) depend on $(RESTRICTED_PKGS_SRC) so that updates to the pkgs file triggers a rebuild? For that to work, the variable $(RESTRICTED_PKGS_SRC) needs to be empty for the OPENJDK case rather than have a dummy name and MakeJavaSecurity.java needs to handle missing the last argument. > > /Erik > > On 2014-07-28 03:44, Wang Weijun wrote: >> Webrev updated at >> >> >> http://cr.openjdk.java.net/~weijun/6997010/webrev.01/ >> >> >> New test CheckSecurityProvider.java, and updates to MakeJavaSecurity.addPackages(). >> >> Thanks >> Max >> >> On Jul 25, 2014, at 22:44, Wang Weijun >> >> wrote: >> >> >>> On Jul 25, 2014, at 22:30, Sean Mullan >>> wrote: >>> >>> >>>>> http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ >>>>> >>>>> >>>>> 4. *IMPORTANT*: In order to easily maintain platform-related entries, >>>>> every line (including the last line) in package.access and >>>>> package.definition MUST end with ',\' now. A blank line MUST exist >>>>> after the last line. This avoid ugly lines like >>>>> >>>>> #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 >>>>> #endif >>>>> >>>> What happens if someone (inevitably) adds a new package to the list and forgets to do either of these? Does it result in a build failure? >>>> >>> No build failure, but test/java/security/SecurityManager/CheckPackageAccess.java will fail. >>> >>> I can add check in the build tool. >>> >>> >>>> Otherwise looks good, although I think it would be useful to write an additional test to make sure the correct providers are installed and ordered correctly on the different platforms, something similar to the java/lang/SecurityManager/CheckPackageAccess.java test but specific to providers. >>>> >>> OK. >>> >>> Thanks >>> Max >>> >>> > From weijun.wang at oracle.com Mon Jul 28 13:58:49 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 28 Jul 2014 21:58:49 +0800 Subject: getKDCFromDNS called too often In-Reply-To: References: Message-ID: Is it possible to specify the kdc for the realm inside krb5.conf? Java only use DNS to get kdc when it cannot read one from krb5.conf. --Max On Jul 28, 2014, at 21:16, Michael Osipov <1983-01-06 at gmx.net> wrote: > Hi folks, > > I am experiencing a performance degregation when JGSS tries to locate a KDC via DNS. > We have for our default realm 120 KDCs running. My Java code performs a SASL bind with Kerberos (keytab) > to get some data from AD over LDAP. This takes sometimes minutes to do where weeks ago mere seconds were necessary. > It seems now we have the double amount of KDCs and this is the problem with JGSS. > > I can see that the roundtrips with the KDC like AS-REQ, preauth required, AS-REQ, AS-REP, TGS-REQ, TGS-REP, etc. > are always preceeded by a getKDCFromDNS. A grep and wc -l over my logfile shows 110 roundtrips for KDC lookup. This is insane. > The request time and payload slow down the entire operation. > > Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working? > > I have to disable the DNS resolution for Java temporarily. > > Michael From erik.joelsson at oracle.com Mon Jul 28 14:27:48 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Jul 2014 16:27:48 +0200 Subject: RFR 6997010: Consolidate java.security files into one file with modifications In-Reply-To: References: <53D26A23.2010806@oracle.com> <902FCDAA-E90B-4677-836C-D294D725FB45@oracle.com> <53D63762.3040200@oracle.com> Message-ID: <53D65DE4.2050408@oracle.com> Build change looks good to me now. /Erik On 2014-07-28 15:53, Wang Weijun wrote: > Yes, you are right. > > Webrev updated at http://cr.openjdk.java.net/~weijun/6997010/webrev.02. GendataJavaSecurity.gmk and MakeJavaSecurity.java updated. > > Thanks > Max > > On Jul 28, 2014, at 19:43, Erik Joelsson wrote: > >> Hello Max, >> >> Shouldn't the rule for $(GENDATA_JAVA_SECURITY) depend on $(RESTRICTED_PKGS_SRC) so that updates to the pkgs file triggers a rebuild? For that to work, the variable $(RESTRICTED_PKGS_SRC) needs to be empty for the OPENJDK case rather than have a dummy name and MakeJavaSecurity.java needs to handle missing the last argument. >> >> /Erik >> >> On 2014-07-28 03:44, Wang Weijun wrote: >>> Webrev updated at >>> >>> >>> http://cr.openjdk.java.net/~weijun/6997010/webrev.01/ >>> >>> >>> New test CheckSecurityProvider.java, and updates to MakeJavaSecurity.addPackages(). >>> >>> Thanks >>> Max >>> >>> On Jul 25, 2014, at 22:44, Wang Weijun >>> >>> wrote: >>> >>> >>>> On Jul 25, 2014, at 22:30, Sean Mullan >>>> wrote: >>>> >>>> >>>>>> http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ >>>>>> >>>>>> >>>>>> 4. *IMPORTANT*: In order to easily maintain platform-related entries, >>>>>> every line (including the last line) in package.access and >>>>>> package.definition MUST end with ',\' now. A blank line MUST exist >>>>>> after the last line. This avoid ugly lines like >>>>>> >>>>>> #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 >>>>>> #endif >>>>>> >>>>> What happens if someone (inevitably) adds a new package to the list and forgets to do either of these? Does it result in a build failure? >>>>> >>>> No build failure, but test/java/security/SecurityManager/CheckPackageAccess.java will fail. >>>> >>>> I can add check in the build tool. >>>> >>>> >>>>> Otherwise looks good, although I think it would be useful to write an additional test to make sure the correct providers are installed and ordered correctly on the different platforms, something similar to the java/lang/SecurityManager/CheckPackageAccess.java test but specific to providers. >>>>> >>>> OK. >>>> >>>> Thanks >>>> Max >>>> >>>> From 1983-01-06 at gmx.net Mon Jul 28 17:01:50 2014 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Mon, 28 Jul 2014 19:01:50 +0200 Subject: getKDCFromDNS called too often Message-ID: > > Is it possible to specify the kdc for the realm inside krb5.conf? Java only use DNS to get kdc when it cannot read one from krb5.conf. Max, this is what I did but this is not a solution because we have dozens of realms which in turn have tens of KDCs. Add those static lists to all Unix machines is annoying. It defeats the whole purpose of DNS SRV. To compare numbers, the entire LDAP operation requires from request to display in the browser no more than 4 seconds with static KDCs. With DNS resolutions: minutes. If you are interested, I can provide log files privately. Moreover, I have access to My Oracle Support if necessary. Michael > On Jul 28, 2014, at 21:16, Michael Osipov <1983-01-06 at gmx.net> wrote: > > > Hi folks, > > > > I am experiencing a performance degregation when JGSS tries to locate a KDC via DNS. > > We have for our default realm 120 KDCs running. My Java code performs a SASL bind with Kerberos (keytab) > > to get some data from AD over LDAP. This takes sometimes minutes to do where weeks ago mere seconds were necessary. > > It seems now we have the double amount of KDCs and this is the problem with JGSS. > > > > I can see that the roundtrips with the KDC like AS-REQ, preauth required, AS-REQ, AS-REP, TGS-REQ, TGS-REP, etc. > > are always preceeded by a getKDCFromDNS. A grep and wc -l over my logfile shows 110 roundtrips for KDC lookup. This is insane. > > The request time and payload slow down the entire operation. > > > > Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working? > > > > I have to disable the DNS resolution for Java temporarily. > > > > Michael > > From raghu.k.nair at oracle.com Mon Jul 28 06:20:55 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Mon, 28 Jul 2014 11:50:55 +0530 Subject: Review request for CR 8049233 Need new tests for testing openssl created certificate Message-ID: <53D5EBC7.6020102@oracle.com> Hello, Please review the tests for openssl generated certificates and CRLS. This tests java.security.cert.Certificate.verify() method and behaviors of the following classes java.security.X509CRL, java.security.X509CRLSelector, java.security.X509CRLRevocationReason and java.security.X509Certificate. Bug - |https://bugs.openjdk.java.net/browse/JDK-8049233| webrev- http://cr.openjdk.java.net/~rhalade/8049233/webrev.00/ Thanks, Raghu Nair -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Mon Jul 28 20:33:21 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 28 Jul 2014 22:33:21 +0200 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <53D65149.8030504@redhat.com> References: <535A72F0.3050800@oracle.com> <53CF396D.4080208@redhat.com> <53CFA587.5080109@oracle.com> <53CFBB52.802@redhat.com> <53D0CF2E.7040706@oracle.com> <53D65149.8030504@redhat.com> Message-ID: <53D6B391.1060502@gmail.com> On 07/28/2014 03:34 PM, David M. Lloyd wrote: > On 07/24/2014 04:17 AM, Tom Hawtin wrote: >> On 23/07/2014 14:40, David M. Lloyd wrote: >>> On 07/23/2014 07:07 AM, Tom Hawtin wrote: >>>> On 23/07/2014 05:26, David M. Lloyd wrote: >> >>>>> ? Always have static initialization blocks be privileged (this does >>>>> require users to be cognizant of this fact when writing static >>>>> blocks) >>>> >>>> If we were following "secure by default", this would break it. It >>>> turns >>>> out having a static initaliser run with an unprivileged acc highlights >>>> code that is doing something naughty. >>> >>> I thought this mindset might dominate, which is unfortunate. In >>> practice, it is far better for code to be predictable, concise, and >>> clear. It does not really make any sense to have random security >>> contexts in place and then call it "secure"; it makes more sense to >>> just >>> tell people "hey your static initializers are privileged". >> >> I'm not suggesting that the random context is a good design. ("Random" >> in the sense that an adversary can often arrange for a trusted context >> when the code expects typical untrusted.) Years ago I suggested the same >> thing. I'm glad that it was rejected due to subsequent experience and a >> bit of reflection. > > Logically speaking there is no weakness here though. > > In order to do privileged things (in static init), you must use a > privileged block. You must always assume that the context is random > (because it is). Thus static blocks are already using privileged blocks. But what to do if you don't want to do privileged things and play safe. Would following help? public class SomeClass { static { AccessController.doPrivileged( (PrivilegedAction) ::unprivilegedInit, new AccessControlContext(new ProtectionDomain[] { new ProtectionDomain(null, null) }) ); } private static void unprivilegedInit() { ... } ... I guess the majority of static initializers don't do privileged things so they should not be privileged by default. I suspect it would be better for static initializers to behave like the above code - the contrary to what David would like them to be... Regards, Peter > There is no meaningful way (in a static init) to test that a caller > has permission to cause a class to initialize. Therefore every > privileged block is superfluous and wasteful. There is no logically > provable benefit to requiring the privileged block on static init - > only superstition. There is no attack vector here that is not already > here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Mon Jul 28 21:58:39 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 28 Jul 2014 16:58:39 -0500 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <53D6B391.1060502@gmail.com> References: <535A72F0.3050800@oracle.com> <53CF396D.4080208@redhat.com> <53CFA587.5080109@oracle.com> <53CFBB52.802@redhat.com> <53D0CF2E.7040706@oracle.com> <53D65149.8030504@redhat.com> <53D6B391.1060502@gmail.com> Message-ID: <53D6C78F.40605@redhat.com> On 07/28/2014 03:33 PM, Peter Levart wrote: > > On 07/28/2014 03:34 PM, David M. Lloyd wrote: >> On 07/24/2014 04:17 AM, Tom Hawtin wrote: >>> On 23/07/2014 14:40, David M. Lloyd wrote: >>>> On 07/23/2014 07:07 AM, Tom Hawtin wrote: >>>>> On 23/07/2014 05:26, David M. Lloyd wrote: >>> >>>>>> ? Always have static initialization blocks be privileged (this does >>>>>> require users to be cognizant of this fact when writing static >>>>>> blocks) >>>>> >>>>> If we were following "secure by default", this would break it. It >>>>> turns >>>>> out having a static initaliser run with an unprivileged acc highlights >>>>> code that is doing something naughty. >>>> >>>> I thought this mindset might dominate, which is unfortunate. In >>>> practice, it is far better for code to be predictable, concise, and >>>> clear. It does not really make any sense to have random security >>>> contexts in place and then call it "secure"; it makes more sense to >>>> just >>>> tell people "hey your static initializers are privileged". >>> >>> I'm not suggesting that the random context is a good design. ("Random" >>> in the sense that an adversary can often arrange for a trusted context >>> when the code expects typical untrusted.) Years ago I suggested the same >>> thing. I'm glad that it was rejected due to subsequent experience and a >>> bit of reflection. >> >> Logically speaking there is no weakness here though. >> >> In order to do privileged things (in static init), you must use a >> privileged block. You must always assume that the context is random >> (because it is). Thus static blocks are already using privileged blocks. > > But what to do if you don't want to do privileged things and play safe. > Would following help? > > public class SomeClass { > static { > AccessController.doPrivileged( > (PrivilegedAction) ::unprivilegedInit, > new AccessControlContext(new ProtectionDomain[] { new > ProtectionDomain(null, null) }) > ); > } > > private static void unprivilegedInit() { > ... > } > > ... > > > I guess the majority of static initializers don't do privileged things > so they should not be privileged by default. I suspect it would be > better for static initializers to behave like the above code - the > contrary to what David would like them to be... On the contrary, I think very many static initializers (most, if you're talking about frameworks and libraries only) are reading system properties, loading JNI libraries, performing I/O, accessing class loaders, or calling operations that do one of these things, causing an explosion of *Action classes and doPrivileged executions during class init. Nevertheless, I'd rather at least see consistent behavior than the bucket of random we have today; if that means a minimal no-permission ACC is in effect, that's still an improvement in my book. I would then go back to advocating some kind of compiler-enhanced way of lexically establishing permissions and privilege that does not entail object construction or lambda realization. -- - DML From weijun.wang at oracle.com Mon Jul 28 23:27:12 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Jul 2014 07:27:12 +0800 Subject: getKDCFromDNS called too often In-Reply-To: References: Message-ID: <7FE13B17-8EAE-41BB-ACA4-63CD3586ED45@oracle.com> I understand your problem. Will see what we can do. When you say "Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working?" do you mean the DNS query result could contain KDCs which do not work? Is this common? Guess there is no need for log file, I know we don't cache the result of that method. Thanks Max On Jul 29, 2014, at 1:01, Michael Osipov <1983-01-06 at gmx.net> wrote: > >> >> Is it possible to specify the kdc for the realm inside krb5.conf? Java only use DNS to get kdc when it cannot read one from krb5.conf. > > Max, this is what I did but this is not a solution because we have dozens of realms which in turn have tens of KDCs. > Add those static lists to all Unix machines is annoying. It defeats the whole purpose of DNS SRV. > > To compare numbers, the entire LDAP operation requires from request to display in the browser no more than 4 seconds with static KDCs. > With DNS resolutions: minutes. > > If you are interested, I can provide log files privately. Moreover, I have access to My Oracle Support if necessary. > > Michael > >> On Jul 28, 2014, at 21:16, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >>> Hi folks, >>> >>> I am experiencing a performance degregation when JGSS tries to locate a KDC via DNS. >>> We have for our default realm 120 KDCs running. My Java code performs a SASL bind with Kerberos (keytab) >>> to get some data from AD over LDAP. This takes sometimes minutes to do where weeks ago mere seconds were necessary. >>> It seems now we have the double amount of KDCs and this is the problem with JGSS. >>> >>> I can see that the roundtrips with the KDC like AS-REQ, preauth required, AS-REQ, AS-REP, TGS-REQ, TGS-REP, etc. >>> are always preceeded by a getKDCFromDNS. A grep and wc -l over my logfile shows 110 roundtrips for KDC lookup. This is insane. >>> The request time and payload slow down the entire operation. >>> >>> Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working? >>> >>> I have to disable the DNS resolution for Java temporarily. >>> >>> Michael >> >> From zaiyao.liu at oracle.com Tue Jul 29 04:36:47 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Tue, 29 Jul 2014 12:36:47 +0800 Subject: Review request for CR 8044193 Need to add known answer tests for AES cipher In-Reply-To: <53D607D2.7040809@oracle.com> References: <53D607D2.7040809@oracle.com> Message-ID: <53D724DF.6060404@oracle.com> Hello, Please help to review the tests for AES cipher. This tests test AES ciphers with different modes and padding schemes when provider change,are part of tests for bug 8044193(Open part) Bug - https://bugs.openjdk.java.net/browse/JDK-8044193 webrev- http://cr.openjdk.java.net/~rhalade/8044193/webrev.00/ Thanks Kevin Liu From fweimer at redhat.com Tue Jul 29 07:45:19 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 29 Jul 2014 09:45:19 +0200 Subject: RFR 8043836: Need new tests for AES cipher In-Reply-To: <53D61087.6030008@oracle.com> References: <53D61087.6030008@oracle.com> Message-ID: <53D7510F.60308@redhat.com> On 07/28/2014 10:57 AM, FELIX YANG wrote: > JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8043836 This bug does not seem to be publicly accessible. -- Florian Weimer / Red Hat Product Security From 1983-01-06 at gmx.net Tue Jul 29 09:42:09 2014 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Tue, 29 Jul 2014 11:42:09 +0200 Subject: getKDCFromDNS called too often In-Reply-To: <7FE13B17-8EAE-41BB-ACA4-63CD3586ED45@oracle.com> References: , <7FE13B17-8EAE-41BB-ACA4-63CD3586ED45@oracle.com> Message-ID: > I understand your problem. Will see what we can do. When you say "Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working?" do you mean the DNS query result could contain KDCs which do not work? Is this common? It can contain invalid entries. Slave DNS servers aren't up to date or a KDC has been dismanted but stale records exist. > Guess there is no need for log file, I know we don't cache the result of that method. Yes, the caching is vital if response is big. It consumes to much time. I have retried that mit MIT Kerberos 1.12.1 on that machine with gss-client. Turned on DNS resolution and KRB5_TRACE. It does several SRV lookups but far less that JGSS and it is extremely fast. I have a TGT and service ticket in second. > On Jul 29, 2014, at 1:01, Michael Osipov <1983-01-06 at gmx.net> wrote: > > > > >> > >> Is it possible to specify the kdc for the realm inside krb5.conf? Java only use DNS to get kdc when it cannot read one from krb5.conf. > > > > Max, this is what I did but this is not a solution because we have dozens of realms which in turn have tens of KDCs. > > Add those static lists to all Unix machines is annoying. It defeats the whole purpose of DNS SRV. > > > > To compare numbers, the entire LDAP operation requires from request to display in the browser no more than 4 seconds with static KDCs. > > With DNS resolutions: minutes. > > > > If you are interested, I can provide log files privately. Moreover, I have access to My Oracle Support if necessary. > > > > Michael > > > >> On Jul 28, 2014, at 21:16, Michael Osipov <1983-01-06 at gmx.net> wrote: > >> > >>> Hi folks, > >>> > >>> I am experiencing a performance degregation when JGSS tries to locate a KDC via DNS. > >>> We have for our default realm 120 KDCs running. My Java code performs a SASL bind with Kerberos (keytab) > >>> to get some data from AD over LDAP. This takes sometimes minutes to do where weeks ago mere seconds were necessary. > >>> It seems now we have the double amount of KDCs and this is the problem with JGSS. > >>> > >>> I can see that the roundtrips with the KDC like AS-REQ, preauth required, AS-REQ, AS-REP, TGS-REQ, TGS-REP, etc. > >>> are always preceeded by a getKDCFromDNS. A grep and wc -l over my logfile shows 110 roundtrips for KDC lookup. This is insane. > >>> The request time and payload slow down the entire operation. > >>> > >>> Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working? > >>> > >>> I have to disable the DNS resolution for Java temporarily. > >>> > >>> Michael > >> > >> > > From weijun.wang at oracle.com Tue Jul 29 09:50:51 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Jul 2014 17:50:51 +0800 Subject: getKDCFromDNS called too often In-Reply-To: References: , <7FE13B17-8EAE-41BB-ACA4-63CD3586ED45@oracle.com> Message-ID: <32130224-C23D-49DD-A0B9-5215CAD36E1A@oracle.com> I guess we can cache the result and remove invalid ones, and probably requery when all are removed. https://bugs.openjdk.java.net/browse/JDK-8052412 filed. You said you are having double numbers of KDCs now, so I guess the DNS response could also double. How come the time spent change from "mere seconds" to minutes? Is there any other change? Thanks Max On Jul 29, 2014, at 17:42, Michael Osipov <1983-01-06 at gmx.net> wrote: > >> I understand your problem. Will see what we can do. When you say "Wouldn't it be possible to perform the lookup *once* and then issue all KDC request to the KDC whis is working?" do you mean the DNS query result could contain KDCs which do not work? Is this common? > > It can contain invalid entries. Slave DNS servers aren't up to date or a KDC has been dismanted but stale records exist. > >> Guess there is no need for log file, I know we don't cache the result of that method. > > Yes, the caching is vital if response is big. It consumes to much time. > > I have retried that mit MIT Kerberos 1.12.1 on that machine with gss-client. Turned on DNS resolution and > KRB5_TRACE. It does several SRV lookups but far less that JGSS and it is extremely fast. I have a TGT and service ticket > in second. From vincent.x.ryan at oracle.com Tue Jul 29 15:02:40 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 29 Jul 2014 16:02:40 +0100 Subject: [9] request for review 8051972: sun/security/pkcs11/ec/ReadCertificates.java fails intermittently Message-ID: Please review this simple fix to eliminate an intermittent test failure. Bug: https://bugs.openjdk.java.net/browse/JDK-8051972 Webrev: http://cr.openjdk.java.net/~vinnie/8051972/webrev.00/ The fix detects if a self-signed cert has inadvertently been selected for an invalid-signature test and ignores the resulting false positive. Thanks. From weijun.wang at oracle.com Tue Jul 29 15:13:29 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Jul 2014 23:13:29 +0800 Subject: RFR 8052999: ProblemList update for Unreachable.java Message-ID: <33B0DA05-5BCD-438F-96A3-94601D9714A2@oracle.com> Please review the problem list change at http://cr.openjdk.java.net/~weijun/8052999/webrev.00/ Looks like the same test on two lines with different platform labels does not work. Now combined. Should this be a noreg-cleanup? --Max From weijun.wang at oracle.com Tue Jul 29 15:29:47 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Jul 2014 23:29:47 +0800 Subject: RFR 8052999: ProblemList update for Unreachable.java In-Reply-To: <33B0DA05-5BCD-438F-96A3-94601D9714A2@oracle.com> References: <33B0DA05-5BCD-438F-96A3-94601D9714A2@oracle.com> Message-ID: <54463C37-70D6-486A-A362-F21748636A74@oracle.com> I decide to further investigate why the 2-line version does not work. Webrev withdrawn. --Max On Jul 29, 2014, at 23:13, Wang Weijun wrote: > Please review the problem list change at > > http://cr.openjdk.java.net/~weijun/8052999/webrev.00/ > > Looks like the same test on two lines with different platform labels does not work. Now combined. > > Should this be a noreg-cleanup? > > --Max > From petr.pchelko at oracle.com Tue Jul 29 08:50:02 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Jul 2014 12:50:02 +0400 Subject: apple.security.KeychainStore does not load private key (when called from javaws) In-Reply-To: <53D75D03.4070403@3kraft.com> References: <53C40783.4060204@3kraft.com> <53C4ECC8.3020909@3kraft.com> <53D75D03.4070403@3kraft.com> Message-ID: <0F9AD930-8C72-4BC9-A0FA-A5A5CDA850FC@oracle.com> Added security-dev. With best regards. Petr. > On Jul 29, 2014, at 12:36 PM, Florian Bruckner (3kraft) wrote: > > Hey guys, > > any feedback on this? > > What is the process to have a patch like this accepted? > > regards, > > Florian > > On 15.07.14 10:56, Florian Bruckner (3kraft) wrote: >> To answer my own question: >> >> KeychainStore loads the private key through native code in KeystoreImpl.m. KeystoreImpl.m uses this osx API to retrieve a PKCS#12 bag: >> >> https://developer.apple.com/library/mac/documentation/security/Reference/keychainservices/Reference/reference.html#jumpTo_63 >> >> The API documentation says the PKCS#12 keystore requires a password. This is either supplied by the caller or the user is prompted (if a flag is set, which is not the case). >> >> KeychainStore then goes on to extract the private key from the returned PKCS#12 store and decrypts it with the password. >> >> Therefore, the password passed into engineGetKey is actually used to encrypt and decrypt only in the scope of this method. Therefore, the approach to create a dummy password for this use case is not as weird as I initially thought. >> >> Please consider these patches to fix this issue: >> >> For jdk7u-dev: >> >> diff -r 35aabd00a534 src/macosx/classes/apple/security/KeychainStore.java >> --- a/src/macosx/classes/apple/security/KeychainStore.java Tue Jul 15 02:26:55 2014 +0400 >> +++ b/src/macosx/classes/apple/security/KeychainStore.java Tue Jul 15 10:52:44 2014 +0200 >> @@ -134,7 +134,7 @@ >> * password to recover it. >> * >> * @param alias the alias name >> - * @param password the password for recovering the key >> + * @param password the password for recovering the key. This password is not used to access the private key in KeyChain, it is used internally only. >> * >> * @return the requested key, or null if the given alias does not exist >> * or does not identify a key entry. >> @@ -148,6 +148,16 @@ >> throws NoSuchAlgorithmException, UnrecoverableKeyException >> { >> permissionCheck(); >> + // An empty password is rejected by MacOS API, no private key data >> + // is exported. If no password is passed (as is the case when >> + // this implementation is used as browser keystore in various >> + // deployment scenarios like webstart, JFX and applets), create >> + // a dummy password to MacOS API is happy. >> + if (password == null || password.length ==0) { >> + // Must not be a char array with only a 0, as this is an empty >> + // string. Therefore use a single character. >> + password = new char[]{'A'} >> + } >> >> Object entry = entries.get(alias.toLowerCase()); >> >> >> >> For jdk8u-dev: >> >> diff -r baec3649f6c0 src/macosx/classes/apple/security/KeychainStore.java >> --- a/src/macosx/classes/apple/security/KeychainStore.java Tue Jul 15 02:00:52 2014 +0400 >> +++ b/src/macosx/classes/apple/security/KeychainStore.java Tue Jul 15 10:54:45 2014 +0200 >> @@ -140,7 +140,7 @@ >> * password to recover it. >> * >> * @param alias the alias name >> - * @param password the password for recovering the key >> + * @param password the password for recovering the key. This password is not used to access the private key in KeyChain, it is used internally only. >> * >> * @return the requested key, or null if the given alias does not exist >> * or does not identify a key entry. >> @@ -154,7 +154,16 @@ >> throws NoSuchAlgorithmException, UnrecoverableKeyException >> { >> permissionCheck(); >> - >> + // An empty password is rejected by MacOS API, no private key data >> + // is exported. If no password is passed (as is the case when >> + // this implementation is used as browser keystore in various >> + // deployment scenarios like webstart, JFX and applets), create >> + // a dummy password to MacOS API is happy. >> + if (password == null || password.length ==0) { >> + // Must not be a char array with only a 0, as this is an empty >> + // string. Therefore use a single character. >> + password = new char[]{'A'} >> + } >> Object entry = entries.get(alias.toLowerCase()); >> >> if (entry == null || !(entry instanceof KeyEntry)) { >> >> >> With best regards, >> >> Florian >> > From weijun.wang at oracle.com Wed Jul 30 02:56:39 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 30 Jul 2014 10:56:39 +0800 Subject: RFR 8052999: ProblemList update for Unreachable.java In-Reply-To: <54463C37-70D6-486A-A362-F21748636A74@oracle.com> References: <33B0DA05-5BCD-438F-96A3-94601D9714A2@oracle.com> <54463C37-70D6-486A-A362-F21748636A74@oracle.com> Message-ID: It seems jtharness just doesn't support one test on two lines. Please review the same webrev at http://cr.openjdk.java.net/~weijun/8052999/webrev.00/ Thanks Max On Jul 29, 2014, at 23:29, Wang Weijun wrote: > I decide to further investigate why the 2-line version does not work. Webrev withdrawn. > > --Max > > On Jul 29, 2014, at 23:13, Wang Weijun wrote: > >> Please review the problem list change at >> >> http://cr.openjdk.java.net/~weijun/8052999/webrev.00/ >> >> Looks like the same test on two lines with different platform labels does not work. Now combined. >> >> Should this be a noreg-cleanup? >> >> --Max >> > From xuelei.fan at oracle.com Wed Jul 30 06:41:23 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 30 Jul 2014 14:41:23 +0800 Subject: RFR 8052999: ProblemList update for Unreachable.java In-Reply-To: References: <33B0DA05-5BCD-438F-96A3-94601D9714A2@oracle.com> <54463C37-70D6-486A-A362-F21748636A74@oracle.com> Message-ID: <53D89393.1090504@oracle.com> Looks fine to me. Xuelei On 7/30/2014 10:56 AM, Wang Weijun wrote: > It seems jtharness just doesn't support one test on two lines. Please review the same webrev at > > http://cr.openjdk.java.net/~weijun/8052999/webrev.00/ > > Thanks > Max > > On Jul 29, 2014, at 23:29, Wang Weijun wrote: > >> I decide to further investigate why the 2-line version does not work. Webrev withdrawn. >> >> --Max >> >> On Jul 29, 2014, at 23:13, Wang Weijun wrote: >> >>> Please review the problem list change at >>> >>> http://cr.openjdk.java.net/~weijun/8052999/webrev.00/ >>> >>> Looks like the same test on two lines with different platform labels does not work. Now combined. >>> >>> Should this be a noreg-cleanup? >>> >>> --Max >>> >> > From xuelei.fan at oracle.com Wed Jul 30 12:56:15 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 30 Jul 2014 20:56:15 +0800 Subject: Code review request, JDK-8052406, SSLv2Hello protocol may be filter out unexpectedly Message-ID: <53D8EB6F.20502@oracle.com> Hi, Please review this fix for JDK-8052406: Webrev: http://cr.openjdk.java.net/~xuelei/8052406/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8049321 For TLS connections, if no suitable cipher suite available for a particular TLS protocol, such protocol should not be negotiated. For example, if only "TLS_RSA_WITH_AES_128_CBC_SHA256" enabled, as it is only supported by TLS version 1.2, the connection should be negotiated TLS version 1 and 1.1. In SunJSSE implementation, we check the binding of enabled protocols and enabled cipher suites. SSLv2Hello may be improperly filter out when making the checking above. Actually, SSLv2Hello is not a real SSL/TLS protocol, it is only used as the format of ClientHello message. If SSLv2Hello is enabled, it should not be filter out. This fix address the SunJSSE problem implementation above. Thanks, Xuelei From amanda.jiang at oracle.com Wed Jul 30 23:50:50 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Wed, 30 Jul 2014 16:50:50 -0700 Subject: RFR J8050281: New permission tests for JEP 140 Message-ID: <53D984DA.2090908@oracle.com> Hi All, Could you please review following 2 new regression tests to be added for JEP140 (Limied doPrivileged). New tests are added to perform permission tests for limited doprivileged with multiple threads , and basic API testing. JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8050281 webrev: http://cr.openjdk.java.net/~rhalade/8050281/webrev.00/ Thanks, Amanda From weijun.wang at oracle.com Thu Jul 31 00:14:15 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 31 Jul 2014 08:14:15 +0800 Subject: Code review request, JDK-8052406, SSLv2Hello protocol may be filter out unexpectedly In-Reply-To: <53D8EB6F.20502@oracle.com> References: <53D8EB6F.20502@oracle.com> Message-ID: The fix looks harmless, but I don't understand the test. What happens if SSLv2Hello is filtered out? --Max On Jul 30, 2014, at 20:56, Xuelei Fan wrote: > Hi, > > Please review this fix for JDK-8052406: > > Webrev: http://cr.openjdk.java.net/~xuelei/8052406/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8049321 > > For TLS connections, if no suitable cipher suite available for a > particular TLS protocol, such protocol should not be negotiated. For > example, if only "TLS_RSA_WITH_AES_128_CBC_SHA256" enabled, as it is > only supported by TLS version 1.2, the connection should be negotiated > TLS version 1 and 1.1. > > In SunJSSE implementation, we check the binding of enabled protocols and > enabled cipher suites. SSLv2Hello may be improperly filter out when > making the checking above. Actually, SSLv2Hello is not a real SSL/TLS > protocol, it is only used as the format of ClientHello message. If > SSLv2Hello is enabled, it should not be filter out. > > This fix address the SunJSSE problem implementation above. > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Jul 31 00:54:41 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 31 Jul 2014 08:54:41 +0800 Subject: Code review request, JDK-8052406, SSLv2Hello protocol may be filter out unexpectedly In-Reply-To: References: <53D8EB6F.20502@oracle.com> Message-ID: <53D993D1.5090708@oracle.com> On 7/31/2014 8:14 AM, Wang Weijun wrote: > The fix looks harmless, but I don't understand the test. What happens if SSLv2Hello is filtered out? > If SSLv2Hello is filtered out, this side would not support SSLv2Hello any more. If SSLv2Hello format client hello requested, the server would reject the connection. In the test case, before the fix, the connection cannot be established as server side filters out SSLv2Hello protocol. Thanks, Xuelei > --Max > > On Jul 30, 2014, at 20:56, Xuelei Fan wrote: > >> Hi, >> >> Please review this fix for JDK-8052406: >> >> Webrev: http://cr.openjdk.java.net/~xuelei/8052406/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8049321 >> >> For TLS connections, if no suitable cipher suite available for a >> particular TLS protocol, such protocol should not be negotiated. For >> example, if only "TLS_RSA_WITH_AES_128_CBC_SHA256" enabled, as it is >> only supported by TLS version 1.2, the connection should be negotiated >> TLS version 1 and 1.1. >> >> In SunJSSE implementation, we check the binding of enabled protocols and >> enabled cipher suites. SSLv2Hello may be improperly filter out when >> making the checking above. Actually, SSLv2Hello is not a real SSL/TLS >> protocol, it is only used as the format of ClientHello message. If >> SSLv2Hello is enabled, it should not be filter out. >> >> This fix address the SunJSSE problem implementation above. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Thu Jul 31 01:11:05 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 31 Jul 2014 09:11:05 +0800 Subject: Code review request, JDK-8052406, SSLv2Hello protocol may be filter out unexpectedly In-Reply-To: <53D993D1.5090708@oracle.com> References: <53D8EB6F.20502@oracle.com> <53D993D1.5090708@oracle.com> Message-ID: <7449D11F-B7F3-40AE-A088-9794C73F37AC@oracle.com> On Jul 31, 2014, at 8:54, Xuelei Fan wrote: > On 7/31/2014 8:14 AM, Wang Weijun wrote: >> The fix looks harmless, but I don't understand the test. What happens if SSLv2Hello is filtered out? >> > If SSLv2Hello is filtered out, this side would not support SSLv2Hello > any more. The server side now only enables TLS_RSA_WITH_AES_128_CBC_SHA256. If other protocols are enabled, what will be the difference? You mean TLS 1.0 and 1.1 has built-in support for SSLv2Hello but TLS 1.2 does not? --Max > If SSLv2Hello format client hello requested, the server would > reject the connection. In the test case, before the fix, the connection > cannot be established as server side filters out SSLv2Hello protocol. > > Thanks, > Xuelei > >> --Max >> >> On Jul 30, 2014, at 20:56, Xuelei Fan wrote: >> >>> Hi, >>> >>> Please review this fix for JDK-8052406: >>> >>> Webrev: http://cr.openjdk.java.net/~xuelei/8052406/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8049321 >>> >>> For TLS connections, if no suitable cipher suite available for a >>> particular TLS protocol, such protocol should not be negotiated. For >>> example, if only "TLS_RSA_WITH_AES_128_CBC_SHA256" enabled, as it is >>> only supported by TLS version 1.2, the connection should be negotiated >>> TLS version 1 and 1.1. >>> >>> In SunJSSE implementation, we check the binding of enabled protocols and >>> enabled cipher suites. SSLv2Hello may be improperly filter out when >>> making the checking above. Actually, SSLv2Hello is not a real SSL/TLS >>> protocol, it is only used as the format of ClientHello message. If >>> SSLv2Hello is enabled, it should not be filter out. >>> >>> This fix address the SunJSSE problem implementation above. >>> >>> Thanks, >>> Xuelei >> > From xuelei.fan at oracle.com Thu Jul 31 02:15:31 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 31 Jul 2014 10:15:31 +0800 Subject: Code review request, JDK-8052406, SSLv2Hello protocol may be filter out unexpectedly In-Reply-To: <7449D11F-B7F3-40AE-A088-9794C73F37AC@oracle.com> References: <53D8EB6F.20502@oracle.com> <53D993D1.5090708@oracle.com> <7449D11F-B7F3-40AE-A088-9794C73F37AC@oracle.com> Message-ID: <53D9A6C3.6040905@oracle.com> On 7/31/2014 9:11 AM, Wang Weijun wrote: > > On Jul 31, 2014, at 8:54, Xuelei Fan wrote: > >> On 7/31/2014 8:14 AM, Wang Weijun wrote: >>> The fix looks harmless, but I don't understand the test. What happens if SSLv2Hello is filtered out? >>> >> If SSLv2Hello is filtered out, this side would not support SSLv2Hello >> any more. > > The server side now only enables TLS_RSA_WITH_AES_128_CBC_SHA256. If other protocols are enabled, what will be the difference? You mean TLS 1.0 and 1.1 has built-in support for SSLv2Hello but TLS 1.2 does not? > Protocols other then TLS v1.2 and SSLv2Hello would be filtered out, i.e., cannot be negotiated as there is no suitable cipher suite for those protocols ("TLS_RSA_WITH_AES_128_CBC_SHA256" only applies to TLS 1.2). SSLv2Hello is a symbol to accept ClientHello message in SSLv2 format. It is not a actual protocol, just a CLientHello message format. The actual negotiated protocol should be one of SSL 3.0/TLS 1.0/1.1/1.2. Therefore, if there is one suitable protocol of SSL 3.0/TLS 1.0/1.1/1.2, SSLv2Hello ClientHello message should be accepted. If SSLv2Hello is not enabled, it means that ClientHello message in SSLv2 format should not be accepted during handshaking. In this case, as will result in that the server side would reject client request, as the requested ClientHello message is in SSLv2 format. Thanks, Xuelei > --Max > >> If SSLv2Hello format client hello requested, the server would >> reject the connection. In the test case, before the fix, the connection >> cannot be established as server side filters out SSLv2Hello protocol. >> >> Thanks, >> Xuelei >> >>> --Max >>> >>> On Jul 30, 2014, at 20:56, Xuelei Fan wrote: >>> >>>> Hi, >>>> >>>> Please review this fix for JDK-8052406: >>>> >>>> Webrev: http://cr.openjdk.java.net/~xuelei/8052406/webrev.00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8049321 >>>> >>>> For TLS connections, if no suitable cipher suite available for a >>>> particular TLS protocol, such protocol should not be negotiated. For >>>> example, if only "TLS_RSA_WITH_AES_128_CBC_SHA256" enabled, as it is >>>> only supported by TLS version 1.2, the connection should be negotiated >>>> TLS version 1 and 1.1. >>>> >>>> In SunJSSE implementation, we check the binding of enabled protocols and >>>> enabled cipher suites. SSLv2Hello may be improperly filter out when >>>> making the checking above. Actually, SSLv2Hello is not a real SSL/TLS >>>> protocol, it is only used as the format of ClientHello message. If >>>> SSLv2Hello is enabled, it should not be filter out. >>>> >>>> This fix address the SunJSSE problem implementation above. >>>> >>>> Thanks, >>>> Xuelei >>> >> > From 1983-01-06 at gmx.net Thu Jul 31 07:14:47 2014 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 31 Jul 2014 09:14:47 +0200 Subject: getKDCFromDNS called too often In-Reply-To: <3048C15A-7C8A-43FC-92DC-98D733BC9AC7@oracle.com> References: <9E9F6DE3-330F-478E-A75A-3C3855772591@oracle.com> <53D95F9D.9040807@gmx.net>, <3048C15A-7C8A-43FC-92DC-98D733BC9AC7@oracle.com> Message-ID: On Jul 31, 2014, at 5:11, Michael Osipov <1983-01-06 at gmx.net> wrote: > > > Am 2014-07-30 um 15:42 schrieb Wang Weijun: > >> > >> On Jul 29, 2014, at 1:01, Michael Osipov <1983-01-06 at gmx.net> wrote: > >> > >>> Moreover, I have access to My Oracle Support if necessary. > >> > >> I'll fix this bug in jdk9 first and backport it to jdk8u myself. > >> However, jdk7u is owned by another engineering group. Since you > >> already have My Oracle Support (honestly I don't know what that is), > >> you can talk to your contact to push this to jdk7u. > > > > OK, aren't you able to propose to a backport on the mailing list? > > If I understand correctly, back porting to older releases (i.e. <= 7) needs a business justification. Since it's not myself working on it, it's always better to make it look important so that the sustaining manager can assign someone to do it. I can give my opinion too. Maybe it won't be even necessary to stay put on Java 7 forever if this gets backported to Java 8. My company is discontinuing every Java release 6 month after Oracle has discontinued it. > > > > I can raise an issue but as far as I know My Oracle Support (though my company is paying big money for that), this will be classified as a wish > > and hell knows when this will be implemented. > > > > Anyway, I won't be able to raise until that bug in fixed in JIRA and committed to master. > > I am writing regression tests and will request for code review for jdk9 soon. Thanks, I will have an eye on the mailing list for that. Michael From 1983-01-06 at gmx.net Thu Jul 31 11:42:37 2014 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 31 Jul 2014 13:42:37 +0200 Subject: Java fails to read crendential cache which has ben obtained through a client keytab Message-ID: Hi, I recently started using the client keytab feature MIT Kerberos introduced some time ago. While C based programs work fine with KRB5_CLIENT_KTNAME, Java is unable to read the credential cache created by that client keytab initiation code because some addtional marker principals are added. In order to analyze the issue, I can provide logfiles, etc. Michael From weijun.wang at oracle.com Thu Jul 31 14:07:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 31 Jul 2014 22:07:34 +0800 Subject: Java fails to read crendential cache which has ben obtained through a client keytab In-Reply-To: References: Message-ID: <084FC9B9-890D-4445-8EF2-D374724E8B66@oracle.com> Hi Michael We've recently fixed a bug where the principal name in ccache has no realm: http://bugs.openjdk.java.net/browse/JDK-8048073 8048073: Cannot read ccache entry with a realm-less service name Is this the same one? If not, can you send me a copy of your ccache? Thanks Max On Jul 31, 2014, at 19:42, Michael Osipov <1983-01-06 at gmx.net> wrote: > Hi, > > I recently started using the client keytab feature MIT Kerberos introduced some time ago. > While C based programs work fine with KRB5_CLIENT_KTNAME, Java is unable to read the credential > cache created by that client keytab initiation code because some addtional marker principals are added. > > In order to analyze the issue, I can provide logfiles, etc. > > Michael