From bradford.wetmore at oracle.com Fri Mar 2 00:01:09 2018 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 1 Mar 2018 16:01:09 -0800 Subject: provider registration In-Reply-To: References: Message-ID: <4f2320ac-7e1e-db94-b3e5-400a7fdb96f0@oracle.com> On 2/28/2018 8:36 AM, Bernd wrote: > Hello, > > there was a thread on BouncyCastle's crypto-dev mailing list how to use > a custom JCA provider with Java 9+. Since there is no alternative for > the lib/ext extension mechanism this is a bit tricky (if you do want to > make the extension in the java.security file permanent). > > There are multiple alternatives (adding to module path, to classpath, > using service loader or programmatic registration). Those are described > in the actual documentation. Hopefully it's clear. There was a lot of moving parts and sharp edges as JDK 9 came to a close. Comments welcome of course. > However expanding the java.security list To be clear, when you say "expanding the java.security list", you mean adding an entry like: security.provider.14=MyProvider > does not mention explicitely > that without the extension mechanism this produces a java home which > wont start without modifying the module path. The JDK should still start, but it wouldn't be able to find MyProvider if it's not in either the class or module path. > Not sure if there is actually a default way to storesuch a "security > provider module" Not aware of anything for JDK 9+, short of putting your provider into the module/classpath directory. As you note, the extension mechanism/directory was removed in the JDK 9 (see JEP 220). > without using for example jlink to build a new image > (or add the -mp argument). Please note from the Provider documentation: You can link a provider in a custom runtime image with the jlink command as long as it doesn't have a Cipher, KeyAgreement, or MAC implementation. Providers that don't have Cipher/KeyAgreement/MAC implementation can be jlinked. However, providers providing Cipher/KeyAgreement/MAC implementations must be signed using a valid certificate to pass the export tests in implementations like Oracle JDK. We only support signed modular jars (module-path) and signed jars (classpath). There is not a signed JMOD feature, and thus jlink can't be used to create an image that will pass the export tests. > Maybe this should be stated explicite? > > "Starting with Java 9 there is no extension mechanism where you could > install the provider JAR permanently. Therefore expanding the > java.security leaves typically a incomplete java home and should be > avoided. Permanently installing an additional module could be done with > a custom jlink image." > > (I havent tested if JLink works, BCProv is not yet modularized or > service loader enabled. Classpath and programmatic registration works fine). > > Is that correct? We could add some wording here to talk about the removal of the extension mechanism. Hope that helps. Brad From sean.mullan at oracle.com Fri Mar 2 18:52:35 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 2 Mar 2018 13:52:35 -0500 Subject: RFR 8191139: Remove deprecated javax.security.auth.Policy API In-Reply-To: References: Message-ID: <200924bd-8820-0946-fbf2-b5ca4722c654@oracle.com> In the related CSR, you should also list the system/security properties that were only used with javax.security.auth.Policy and therefore are no longer necessary: 1. auth.policy.provider 2. cache.auth.policy (seems to have never been documented but I found a reference to it in some old IBM javadocs). 3. java.security.auth.policy 4. auth.policy.url. For the 3rd/4th ones above, there is still some code in sun.security.provider.PolicyFile that looks for it, so it can be removed as part of this change now. Can you remove that and send an updated webrev? --Sean On 2/24/18 4:15 AM, Weijun Wang wrote: > Please take a review at > > 8191139: Remove deprecated javax.security.auth.Policy API > http://cr.openjdk.java.net/~weijun/8191139/webrev.00/ > > Thanks > Max > From ecki at zusammenkunft.net Sat Mar 3 07:31:11 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 3 Mar 2018 08:31:11 +0100 Subject: provider registration In-Reply-To: <4f2320ac-7e1e-db94-b3e5-400a7fdb96f0@oracle.com> References: <4f2320ac-7e1e-db94-b3e5-400a7fdb96f0@oracle.com> Message-ID: <5a9a4f40.f2b8df0a.29d6f.92c4@mx.google.com> Hello Brad, thanks for the answer. Yes I was talking about the security.provider properties. It is good to know that it wont work with jlink/jmod. The JCA/JCE documentation Looks quite good to follow. A text similiar to this would complete the picture: Note when changing the list of Providers in Java.security file, that this requires the signed Provider JAR to be present on the class- or module path of the JVM. When the Provider class cannot be loaded, it will be skipped. The extensions mechanism/library was deprecated in Java 8 and removed in Java 9. It can no longer be used to store your custom JCE Provider JAR. Storing JCE providers in custom runtime Images (JMOD files bundled with the JLink tool) is only possible if the provider does not provide Ciphers, Key Agreements or MACs (because there is no codesigning feature for jmod files). Gruss Bernd -- http://bernd.eckenfels.net Von: Brad Wetmore Gesendet: Freitag, 2. M?rz 2018 01:01 An: Bernd; OpenJDK Dev list Betreff: Re: provider registration On 2/28/2018 8:36 AM, Bernd wrote: > Hello, > > there was a thread on BouncyCastle's crypto-dev mailing list how to use > a custom JCA provider with Java 9+. Since there is no alternative for > the lib/ext extension mechanism this is a bit tricky (if you do want to > make the extension in the java.security file permanent). > > There are multiple alternatives (adding to module path, to classpath, > using service loader or programmatic registration). Those are described > in the actual documentation. Hopefully it's clear. There was a lot of moving parts and sharp edges as JDK 9 came to a close. Comments welcome of course. > However expanding the java.security list To be clear, when you say "expanding the java.security list", you mean adding an entry like: security.provider.14=MyProvider > does not mention explicitely > that without the extension mechanism this produces a java home which > wont start without modifying the module path. The JDK should still start, but it wouldn't be able to find MyProvider if it's not in either the class or module path. > Not sure if there is actually a default way to storesuch a "security > provider module" Not aware of anything for JDK 9+, short of putting your provider into the module/classpath directory. As you note, the extension mechanism/directory was removed in the JDK 9 (see JEP 220). > without using for example jlink to build a new image > (or add the -mp argument). Please note from the Provider documentation: You can link a provider in a custom runtime image with the jlink command as long as it doesn't have a Cipher, KeyAgreement, or MAC implementation. Providers that don't have Cipher/KeyAgreement/MAC implementation can be jlinked. However, providers providing Cipher/KeyAgreement/MAC implementations must be signed using a valid certificate to pass the export tests in implementations like Oracle JDK. We only support signed modular jars (module-path) and signed jars (classpath). There is not a signed JMOD feature, and thus jlink can't be used to create an image that will pass the export tests. > Maybe this should be stated explicite? > > "Starting with Java 9 there is no extension mechanism where you could > install the provider JAR permanently. Therefore expanding the > java.security leaves typically a incomplete java home and should be > avoided. Permanently installing an additional module could be done with > a custom jlink image." > > (I havent tested if JLink works, BCProv is not yet modularized or > service loader enabled. Classpath and programmatic registration works fine). > > Is that correct? We could add some wording here to talk about the removal of the extension mechanism. Hope that helps. Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 5 03:44:28 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 5 Mar 2018 11:44:28 +0800 Subject: RFR 8191139: Remove deprecated javax.security.auth.Policy API In-Reply-To: <200924bd-8820-0946-fbf2-b5ca4722c654@oracle.com> References: <200924bd-8820-0946-fbf2-b5ca4722c654@oracle.com> Message-ID: <44E19AF4-810C-4D37-B161-D0DFE5952F03@oracle.com> > On Mar 3, 2018, at 2:52 AM, Sean Mullan wrote: > > In the related CSR, you should also list the system/security properties that were only used with javax.security.auth.Policy and therefore are no longer necessary: > > 1. auth.policy.provider > 2. cache.auth.policy (seems to have never been documented but I found a reference to it in some old IBM javadocs). > 3. java.security.auth.policy > 4. auth.policy.url. CSR updated and re-finalized. > > For the 3rd/4th ones above, there is still some code in sun.security.provider.PolicyFile that looks for it, so it can be removed as part of this change now. Can you remove that and send an updated webrev? http://cr.openjdk.java.net/~weijun/8191139/webrev.01/ posted. I also removed the changes to the localized resources files. They should be maintained by the translation team. Thanks Max > > --Sean > > On 2/24/18 4:15 AM, Weijun Wang wrote: >> Please take a review at >> 8191139: Remove deprecated javax.security.auth.Policy API >> http://cr.openjdk.java.net/~weijun/8191139/webrev.00/ >> Thanks >> Max From sean.coffey at oracle.com Mon Mar 5 14:37:13 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 5 Mar 2018 14:37:13 +0000 Subject: RFR: 8199018: Test crypto provider not registering Message-ID: Brad pointed out to me off-line that the test case from 8193892 needs correcting. Some late editing to the test broke functionality. I've corrected the testcase and added extra checks to ensure that "MyProvider" is being registered correctly. https://bugs.openjdk.java.net/browse/JDK-8199018 http://cr.openjdk.java.net/~coffeys/webrev.8199018/webrev/ -- Regards, Sean. From mbalao at redhat.com Mon Mar 5 16:39:43 2018 From: mbalao at redhat.com (Martin Balao) Date: Mon, 5 Mar 2018 13:39:43 -0300 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <22b6c79c-dffd-2f2d-414b-d8a543bbc96c@oracle.com> References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> <22b6c79c-dffd-2f2d-414b-d8a543bbc96c@oracle.com> Message-ID: Any updates on this? Thanks, Martin.- On Thu, Feb 15, 2018 at 9:53 PM, Valerie Peng wrote: > > I am ok with the idea of putting the public API refactoring under a > separate RFE. > Let me apply your updated patch below and run existing regressions again. > Thanks, > Valerie > > > On 2/5/2018 5:51 AM, Martin Balao wrote: > > Hi Valerie, > > Thanks for your review. > > Here it's the new webrev updated to the new repository structure. I've > also updated the testcase to use the new @module jtreg feature: > > * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_ > 12_sunpkcs11/2018_02_02/8029661.webrev.02 (online) > * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_ > 12_sunpkcs11/2018_02_02/8029661.webrev.02.zip (download) > > A few comments in regards to creating public APIs from > sun.security.internal.spec classes. > > Classes in jdk/src/java.base/share/classes/sun/security/internal/spec: > * TlsKeyMaterialParameterSpec.java > * TlsMasterSecretParameterSpec.java > * TlsRsaPremasterSecretParameterSpec.java > * TlsKeyMaterialSpec.java > * TlsPrfParameterSpec.java > > Classes in jdk/src/java.base/share/classes/java/security/spec (which I > assume would be the destination): > * AlgorithmParameterSpec.java > * ECGenParameterSpec.java > * InvalidParameterSpecException.java > * RSAOtherPrimeInfo.java > * DSAGenParameterSpec.java > * ECParameterSpec.java > * KeySpec.java > * ... > > TlsRsaPremasterSecretParameterSpec class contains information about min > and max SSL/TLS version and, optionally, the pre-master encoded key. This > information may be useful to any 3rd party class that implements a > KeyGenerator to generate RSA pre-master secrets. > > TlsMasterSecretParameterSpec class contains information (client/server > random, pre-master secret, hash algorithm, etc.) to generate a master > secret from a pre-master secret. > > TlsKeyMaterialParameterSpec class contains information (client/server > random, master secret, hash algorithm, etc.) to generate keys for a session > from a master secret. > > TlsPrfParameterSpec class contains information (secret key, label, hash > algorithm, etc.) to generate handshake authentication codes. > > TlsKeyMaterialSpec class contains information about session keys. This > class inherits from SecretKey class. > > So, I agree with you: these parameters/specs may be used by a 3rd party > and would be better to have them as public interfaces. > > However, I suggest to address that in a new ticket because: > * it is not strictly inherent to SunPKCS11 + TLS 1.2 support we are > providing in the context of this ticket; > * it would be more clear both in tickets documentation and repository > changeset; > * this refactoring is going to go through CSR, which SunPKCS11 + TLS 1.2 > support does not need; and, > * we should also evaluate how TLS 1.3 changes going to impact into this. > > Would splitting this into a new ticket work for you? > > Kind regards, > Martin.- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Mar 5 16:45:48 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 5 Mar 2018 11:45:48 -0500 Subject: RFR 8191139: Remove deprecated javax.security.auth.Policy API In-Reply-To: <44E19AF4-810C-4D37-B161-D0DFE5952F03@oracle.com> References: <200924bd-8820-0946-fbf2-b5ca4722c654@oracle.com> <44E19AF4-810C-4D37-B161-D0DFE5952F03@oracle.com> Message-ID: On 3/4/18 10:44 PM, Weijun Wang wrote: >> For the 3rd/4th ones above, there is still some code in sun.security.provider.PolicyFile that looks for it, so it can be removed as part of this change now. Can you remove that and send an updated webrev? > http://cr.openjdk.java.net/~weijun/8191139/webrev.01/ posted. I also removed the changes to the localized resources files. They should be maintained by the translation team. Looks good. --Sean From tobias.wagner at n-design.de Mon Mar 5 18:39:20 2018 From: tobias.wagner at n-design.de (=?utf-8?Q?Tobias_Wagner?=) Date: Mon, 5 Mar 2018 19:39:20 +0100 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC In-Reply-To: <5e13ed7c-99d2-1bb7-4f0d-8a0ac594e57f@primekey.se> References: <5e13ed7c-99d2-1bb7-4f0d-8a0ac594e57f@primekey.se> Message-ID: Hi Valerie and Tomas, thanks for the hint about SoftHSM. I just found the time to test it. I was able to run TestECDH using it with a SoftHSM2 based SunPKCS11 provider. I did not hear anything about my last response - so I hope, this it might be helpful. I wonder if there is anything left to do for me or whether the proposed patch is acceptable as it is right now. There is a patch attached to show the test setup - but this is nothing to be used in production. There is also the jtreg output for TestECDH with SoftHSM2 To run this, I had to do some things before * Build SoftHSM2 myself. I've used this version: https://github.com/opendnssec/SoftHSMv2/releases/tag/2.4.0 . The versions available via package managers did not work for me * Generate a new token 'softhsm2-util --init-token --slot 0 --label "Token 0"' with PIN '123456' for the Token an the SO as well NOTE: The PIN is hard coded into the example patch. This worked on Linux and MacOS. Regards, Tobias Am 09.02.2018 um 10:22 schrieb Tomas Gustavsson: > > Just FYI. SoftHSM2 from the OpenDNSSec project is a good P11 to test > with, and I believe it supports brainpool in recent versions. > https://github.com/opendnssec/SoftHSMv2 > > It works really good) > > Regards, > Tomas > > On 2018-02-09 02:03, Valerie Peng wrote: >> Hi Tobias, >> >> Just curious, which PKCS11 library did you use to test your patch? After >> I applied your patch and ran the regression tests, I noticed that both >> the Solaris PKCS11 library and NSS skipped testing Brainpool curves with >> different error codes which may be due to lack of support... >> >> Regards, >> Valerie -------------- next part -------------- A non-text attachment was scrubbed... Name: TestECDH.jtr Type: application/octet-stream Size: 14883 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk_jdk_49130.patch Type: application/octet-stream Size: 3401 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5574 bytes Desc: not available URL: From bradford.wetmore at oracle.com Mon Mar 5 23:41:25 2018 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 5 Mar 2018 15:41:25 -0800 Subject: RFR: 8199018: Test crypto provider not registering In-Reply-To: References: Message-ID: <73838e52-6417-e90d-8176-647f8b232701@oracle.com> Looks good. This looks like it still needs to be done in jdk/jdk. Are you planning on doing that? Thanks, Brad On 3/5/2018 6:37 AM, Se?n Coffey wrote: > Brad pointed out to me off-line that the test case from 8193892 needs > correcting. Some late editing to the test broke functionality. I've > corrected the testcase and added extra checks to ensure that > "MyProvider" is being registered correctly. > > https://bugs.openjdk.java.net/browse/JDK-8199018 > http://cr.openjdk.java.net/~coffeys/webrev.8199018/webrev/ > From sean.coffey at oracle.com Tue Mar 6 09:03:23 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 6 Mar 2018 09:03:23 +0000 Subject: RFR: 8199018: Test crypto provider not registering In-Reply-To: <73838e52-6417-e90d-8176-647f8b232701@oracle.com> References: <73838e52-6417-e90d-8176-647f8b232701@oracle.com> Message-ID: <7166c276-ef35-d9f6-b522-929ea7f367f1@oracle.com> Thanks Brad - yes, this review is for JDK 11 (jdk/jdk). I've another review request open for you in order to handle the jdk8u-dev edit : http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007284.html regards, Sean. On 05/03/2018 23:41, Brad Wetmore wrote: > Looks good. > > This looks like it still needs to be done in jdk/jdk.? Are you > planning on doing that? > > Thanks, > > Brad > > > On 3/5/2018 6:37 AM, Se?n Coffey wrote: >> Brad pointed out to me off-line that the test case from 8193892 needs >> correcting. Some late editing to the test broke functionality. I've >> corrected the testcase and added extra checks to ensure that >> "MyProvider" is being registered correctly. >> >> https://bugs.openjdk.java.net/browse/JDK-8199018 >> http://cr.openjdk.java.net/~coffeys/webrev.8199018/webrev/ >> From weijun.wang at oracle.com Tue Mar 6 14:36:14 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Mar 2018 22:36:14 +0800 Subject: RFR 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8198898/webrev.00/ Two notes: 1. In fact, I am not able to build now because there are other codes not compiling with VS 2017 and they fail before security.cpp is compiled. I just installed VS 2017 locally, extracted the command lines (cl and link) compiling security.cpp when VS 2013 is used, and modified them to run with VS 2017. I can confirm that before this change the warnings in the bug description showed up and they disappeared after the change. 2. The Java_sun_security_mscapi_KeyStore_getKeyLength function seems useless. There is no getKeyLength() method in sun.security.mscapi.KeyStore at all. I looked at the history and it looks like this from the beginning. Maybe I should remove the function? Thanks Max From xuelei.fan at oracle.com Tue Mar 6 15:46:14 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Mar 2018 07:46:14 -0800 Subject: RFR 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 In-Reply-To: References: Message-ID: Looks fine to me. On 3/6/2018 6:36 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8198898/webrev.00/ > > Two notes: > > 1. In fact, I am not able to build now because there are other codes not compiling with VS 2017 and they fail before security.cpp is compiled. I just installed VS 2017 locally, extracted the command lines (cl and link) compiling security.cpp when VS 2013 is used, and modified them to run with VS 2017. I can confirm that before this change the warnings in the bug description showed up and they disappeared after the change. > > 2. The Java_sun_security_mscapi_KeyStore_getKeyLength function seems useless. There is no getKeyLength() method in sun.security.mscapi.KeyStore at all. I looked at the history and it looks like this from the beginning. Maybe I should remove the function? > I would like to remove unused code. Thanks, Xuelei From bradford.wetmore at oracle.com Tue Mar 6 18:18:58 2018 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 6 Mar 2018 10:18:58 -0800 Subject: RFR: 8199018: Test crypto provider not registering In-Reply-To: <7166c276-ef35-d9f6-b522-929ea7f367f1@oracle.com> References: <73838e52-6417-e90d-8176-647f8b232701@oracle.com> <7166c276-ef35-d9f6-b522-929ea7f367f1@oracle.com> Message-ID: <41a2d220-cecd-0d5b-0a29-b0f458e579e0@oracle.com> Thanks for pointing out where the review was, I don't check the update email list as often. Reviewed in jdk8u-dev. Looks good. Brad On 3/6/2018 1:03 AM, Se?n Coffey wrote: > Thanks Brad - yes, this review is for JDK 11 (jdk/jdk). > > I've another review request open for you in order to handle the > jdk8u-dev edit : > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007284.html > > regards, > Sean. > > > On 05/03/2018 23:41, Brad Wetmore wrote: >> Looks good. >> >> This looks like it still needs to be done in jdk/jdk.? Are you >> planning on doing that? >> >> Thanks, >> >> Brad >> >> >> On 3/5/2018 6:37 AM, Se?n Coffey wrote: >>> Brad pointed out to me off-line that the test case from 8193892 needs >>> correcting. Some late editing to the test broke functionality. I've >>> corrected the testcase and added extra checks to ensure that >>> "MyProvider" is being registered correctly. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8199018 >>> http://cr.openjdk.java.net/~coffeys/webrev.8199018/webrev/ >>> > From ivan.gerasimov at oracle.com Tue Mar 6 21:01:48 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 6 Mar 2018 13:01:48 -0800 Subject: RFR 8178370 : [TEST_BUG] java/security/Signature/SignatureLength.java fails Message-ID: Hello! The regression test SignatureLength.java was seen to fail on some Solaris systems. This is because signature verifier from SunPKCS11-Solaris provider doesn't always throw SignatureException when the signature is of wrong length, but can simply return false to indicate it is invalid. The test was also modified to try different combinations of providers used to create key-pair generator, signer and verifier. The fixed test passes well on all platforms with JDK 11 and JDK 8u. Would you please help review it? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8178370 WEBREV: http://cr.openjdk.java.net/~igerasim/8178370/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Wed Mar 7 01:38:59 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Mar 2018 09:38:59 +0800 Subject: RFR 8199154: Accessibility issues in jdk.security.auth In-Reply-To: References: Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8199154/webrev.00/ In LdapLoginModule.java, there seems to be an erroneous DL inside DL. I removed the outer DL and its incomplete DD. There is no visual difference after the change. In Krb5LoginModule.java, there were only DDs and no DT. I've simply removed all D? tags. The output is little more compact. See the attached screenshot. Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: auth-dd.jpeg Type: image/jpeg Size: 91296 bytes Desc: not available URL: From weijun.wang at oracle.com Wed Mar 7 02:10:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Mar 2018 10:10:01 +0800 Subject: RFR 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 In-Reply-To: References: Message-ID: > On Mar 6, 2018, at 11:46 PM, Xuelei Fan wrote: > > Looks fine to me. > > On 3/6/2018 6:36 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8198898/webrev.00/ >> Two notes: >> 1. In fact, I am not able to build now because there are other codes not compiling with VS 2017 and they fail before security.cpp is compiled. I just installed VS 2017 locally, extracted the command lines (cl and link) compiling security.cpp when VS 2013 is used, and modified them to run with VS 2017. I can confirm that before this change the warnings in the bug description showed up and they disappeared after the change. >> 2. The Java_sun_security_mscapi_KeyStore_getKeyLength function seems useless. There is no getKeyLength() method in sun.security.mscapi.KeyStore at all. I looked at the history and it looks like this from the beginning. Maybe I should remove the function? > I would like to remove unused code. There are other unused code in security.cpp. I'll fix all in a different bug. Thanks Max > > Thanks, > Xuelei From weijun.wang at oracle.com Wed Mar 7 02:19:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Mar 2018 10:19:33 +0800 Subject: RFR 8199198: Remove unused functions in jdk.crypto.mscapi native code Message-ID: <506B92F1-7AD2-4557-AB20-9B00A7CD27E4@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8199198/webrev.00 I just removed the 3 unused functions. They were there from the beginning (2005) but had never existed in any Java class. Thanks Max From ivan.gerasimov at oracle.com Wed Mar 7 02:33:57 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 6 Mar 2018 18:33:57 -0800 Subject: RFR 8199198: Remove unused functions in jdk.crypto.mscapi native code In-Reply-To: <506B92F1-7AD2-4557-AB20-9B00A7CD27E4@oracle.com> References: <506B92F1-7AD2-4557-AB20-9B00A7CD27E4@oracle.com> Message-ID: <3e552db7-5ce8-9292-04f7-ae9c88a90a44@oracle.com> It looks good! With kind regards, Ivan On 3/6/18 6:19 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8199198/webrev.00 > > I just removed the 3 unused functions. They were there from the beginning (2005) but had never existed in any Java class. > > Thanks > Max > > From weijun.wang at oracle.com Thu Mar 8 04:15:32 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Mar 2018 12:15:32 +0800 Subject: RFR 8193262: JNI array not released in libsunmscapi convertToLittleEndian In-Reply-To: <97EF5417-C37E-49BC-ABB3-3159DBA03A70@oracle.com> References: <97EF5417-C37E-49BC-ABB3-3159DBA03A70@oracle.com> Message-ID: <77F22620-DCB2-472A-95A9-F605EFD8C60D@oracle.com> Ping again. > On Feb 24, 2018, at 10:49 PM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8193262/webrev.00/ > > Noreg-hard. I modified my own JDK a little to directly call convertToLittleEndian() using bad input and I can see my debug line before the ReleaseByteArrayElements() call is always printed. > > Thanks > Max > From anthony.scarpino at oracle.com Thu Mar 8 04:58:55 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 7 Mar 2018 20:58:55 -0800 Subject: RFR 8193262: JNI array not released in libsunmscapi convertToLittleEndian In-Reply-To: <77F22620-DCB2-472A-95A9-F605EFD8C60D@oracle.com> References: <97EF5417-C37E-49BC-ABB3-3159DBA03A70@oracle.com> <77F22620-DCB2-472A-95A9-F605EFD8C60D@oracle.com> Message-ID: Looks good to me, but you need to update the copyright date. Also the bug will need at ?noreg? label Tony > On Mar 7, 2018, at 8:15 PM, Weijun Wang wrote: > > Ping again. > >> On Feb 24, 2018, at 10:49 PM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8193262/webrev.00/ >> >> Noreg-hard. I modified my own JDK a little to directly call convertToLittleEndian() using bad input and I can see my debug line before the ReleaseByteArrayElements() call is always printed. >> >> Thanks >> Max > From vincent.x.ryan at oracle.com Thu Mar 8 07:43:55 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 8 Mar 2018 07:43:55 +0000 Subject: RFR 8199198: Remove unused functions in jdk.crypto.mscapi native code In-Reply-To: <506B92F1-7AD2-4557-AB20-9B00A7CD27E4@oracle.com> References: <506B92F1-7AD2-4557-AB20-9B00A7CD27E4@oracle.com> Message-ID: Hello Max, Your change looks fine to me. Thanks. > On 7 Mar 2018, at 02:19, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8199198/webrev.00 > > I just removed the 3 unused functions. They were there from the beginning (2005) but had never existed in any Java class. > > Thanks > Max > From weijun.wang at oracle.com Thu Mar 8 10:13:44 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Mar 2018 18:13:44 +0800 Subject: RFR 8180570: Refactor sun/security/mscapi shell tests to plain java tests Message-ID: <3B74A4FA-D273-448C-8294-B2093AC48EAB@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8180570/webrev.00 Several notes: 1. The original KeyStoreCompatibilityMode.sh does not check the exit value of each command. I assume it should. 2. I don't really understand what SystemDrive is for in RSAEncryptDecrypt.sh. Maybe about running the test from \\remote\share? I also cannot find JDK-6449799. 3. SecurityTools::getProcessBuilder is modified a little. On my Windows machine without cygwin (major reason why I want to work on this RFE), setting -Djava.security.egd=file:/dev/./urandom causes an error. 4. nonUniqueAliases/NonUniqueAliases.sh is not touched. It has an @ignore. Thanks Max From weijun.wang at oracle.com Thu Mar 8 12:37:32 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Mar 2018 20:37:32 +0800 Subject: RFR 8180570: Refactor sun/security/mscapi shell tests to plain java tests In-Reply-To: <3B74A4FA-D273-448C-8294-B2093AC48EAB@oracle.com> References: <3B74A4FA-D273-448C-8294-B2093AC48EAB@oracle.com> Message-ID: <865D5A85-8CA2-40EA-8EA4-841F2B5FC756@oracle.com> > On Mar 8, 2018, at 6:13 PM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8180570/webrev.00 Updated in place. > > Several notes: > > 1. The original KeyStoreCompatibilityMode.sh does not check the exit value of each command. I assume it should. > > 2. I don't really understand what SystemDrive is for in RSAEncryptDecrypt.sh. Maybe about running the test from \\remote\share? I also cannot find JDK-6449799. > > 3. SecurityTools::getProcessBuilder is modified a little. On my Windows machine without cygwin (major reason why I want to work on this RFE), setting -Djava.security.egd=file:/dev/./urandom causes an error. > > 4. nonUniqueAliases/NonUniqueAliases.sh is not touched. It has an @ignore. This one is also updated. I tried it on a Windows Server 2016 with certutil.exe and it succeeds. --Max > > Thanks > Max > From sean.mullan at oracle.com Thu Mar 8 18:51:00 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 8 Mar 2018 13:51:00 -0500 Subject: RFR 8171277: Elliptic Curves for Security in Crypto In-Reply-To: References: Message-ID: I haven't reviewed all of it (mainly just the standard classes), but here are some comments so far: - General comments For new public classes, you don't need to start the sentence with the name of the class since that is implied and will show up in javadoc pages. For example, "XECKey is an interface ..." should just be "An interface ..." I think somewhere there should be a sentence or two on the difference between XECKeys and ECKeys and when you would want to use each. This is important enough that I think some detail should be in the javadoc to help users distinguish them. Perhaps put it in the XEC class description. Maybe more details can go in the JCA security guide. - ECGenParameterSpec 45: s/of provider/of the provider/ - NamedParameterSpec 36: the link looks wrong, since it is for SSLContext 39: I think the @see is unnecessary - XECKey The description should include some basic details so someone doesn't have to know what RFC 7748 is to understand it. - XECPrivateKey 47: would "cannot" be a more appropriate word than "may not"? May not sounds a bit vague. Perhaps also an example of why it cannot be extracted would be helpful. --Sean On 2/6/18 1:36 PM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8171277 > > Please review this change that adds key agreement via the X25519 and > X448 elliptic curve functions to the JCA API and SunEC provider. These > functions and related operations and encodings are described in RFC > 7748[1]. This work does not include JSSE integration, which will be done > later as a separate task (not part of JEP 324). The webrev does not > include the field arithmetic code, which is being reviewed > separately[2]. This change is a part of JEP 324, so it will not be > integrated into the repo until all work for that JEP is complete and it > has been targeted to a release. > > > [1] https://tools.ietf.org/html/rfc7748 > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016756.html > > From valerie.peng at oracle.com Fri Mar 9 03:30:53 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 8 Mar 2018 19:30:53 -0800 Subject: RFR 8199154: Accessibility issues in jdk.security.auth In-Reply-To: References: Message-ID: <6e415b72-8b35-bf3e-491e-bf7fdb791536@oracle.com> Line 196 of LdapLoginModule.java seems to miss a ? Rest of webrev look fine. Valerie On 3/6/2018 5:38 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8199154/webrev.00/ > > > In LdapLoginModule.java, there seems to be an erroneous DL inside DL. > I removed the outer DL and its incomplete DD.?There is no visual > difference after the change. > > In Krb5LoginModule.java, there were only DDs and no DT. I've simply > removed all D? tags. The output is little more?compact. See the > attached screenshot. > > > > Thanks > Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Mar 9 03:34:39 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 9 Mar 2018 11:34:39 +0800 Subject: RFR 8199154: Accessibility issues in jdk.security.auth In-Reply-To: <6e415b72-8b35-bf3e-491e-bf7fdb791536@oracle.com> References: <6e415b72-8b35-bf3e-491e-bf7fdb791536@oracle.com> Message-ID: <90926F22-D35F-4B1E-9253-B4531C77720D@oracle.com> > On Mar 9, 2018, at 11:30 AM, Valerie Peng wrote: > > > Line 196 of LdapLoginModule.java seems to miss a ? Maybe this is one of those inner tags (DD always inside DL) that will be automatically closed when its outer tag is closed? I'll add it anyway. Thanks. --Max > Rest of webrev look fine. > Valerie > > On 3/6/2018 5:38 PM, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8199154/webrev.00/ >> >> In LdapLoginModule.java, there seems to be an erroneous DL inside DL. I removed the outer DL and its incomplete DD. There is no visual difference after the change. >> >> In Krb5LoginModule.java, there were only DDs and no DT. I've simply removed all D? tags. The output is little more compact. See the attached screenshot. >> >> >> >> Thanks >> Max > From adam.petcher at oracle.com Fri Mar 9 16:25:41 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 9 Mar 2018 11:25:41 -0500 Subject: RFR 8171277: Elliptic Curves for Security in Crypto In-Reply-To: References: Message-ID: New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/ On 3/8/2018 1:51 PM, Sean Mullan wrote: > I haven't reviewed all of it (mainly just the standard classes), but > here are some comments so far: > > - General comments > > For new public classes, you don't need to start the sentence with the > name of the class since that is implied and will show up in javadoc > pages. For example, "XECKey is an interface ..." should just be "An > interface ..." fixed. > > I think somewhere there should be a sentence or two on the difference > between XECKeys and ECKeys and when you would want to use each. This > is important enough that I think some detail should be in the javadoc > to help users distinguish them. Perhaps put it in the XEC class > description. Maybe more details can go in the JCA security guide. I added a sentence to the comments in XECKey, but I'm not sure how much we should say here. I don't know if we should get into mathematical details. Take a look at the new wording and let me know if I should add more information. > > - ECGenParameterSpec > > 45: s/of provider/of the provider/ fixed > > - NamedParameterSpec > > 36: the link looks wrong, since it is for SSLContext Oops. I changed the section to "parameter-spec-names" which will be a new section that I'll add to this document. > 39: I think the @see is unnecessary removed. > > - XECKey > > The description should include some basic details so someone doesn't > have to know what RFC 7748 is to understand it. Similar response to a previous comment. I added some more information, but I don't know if it is enough. Let me know. > > - XECPrivateKey > > 47: would "cannot" be a more appropriate word than "may not"? May not > sounds a bit vague. Perhaps also an example of why it cannot be > extracted would be helpful. > I changed it to "cannot" and added the example. > --Sean > > On 2/6/18 1:36 PM, Adam Petcher wrote: >> Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8171277 >> >> Please review this change that adds key agreement via the X25519 and >> X448 elliptic curve functions to the JCA API and SunEC provider. >> These functions and related operations and encodings are described in >> RFC 7748[1]. This work does not include JSSE integration, which will >> be done later as a separate task (not part of JEP 324). The webrev >> does not include the field arithmetic code, which is being reviewed >> separately[2]. This change is a part of JEP 324, so it will not be >> integrated into the repo until all work for that JEP is complete and >> it has been targeted to a release. >> >> >> [1] https://tools.ietf.org/html/rfc7748 >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016756.html >> >> From xuelei.fan at oracle.com Sun Mar 11 16:04:41 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 11 Mar 2018 09:04:41 -0700 Subject: RFR 8181594: Efficient and constant-time modular arithmetic In-Reply-To: <9021dd99-4ac1-f7a1-fc91-ab0a9cf1685b@oracle.com> References: <7bd6c1ae-4173-4384-fc57-66d1b185ba56@oracle.com> <9021dd99-4ac1-f7a1-fc91-ab0a9cf1685b@oracle.com> Message-ID: On 2/26/2018 10:39 AM, Adam Petcher wrote: > > http://cr.openjdk.java.net/~apetcher/8181594/webrev.01/ > > See inline below. > > On 2/23/2018 12:46 PM, Xuelei Fan wrote: > >> ArrayUtil.java: >> =============== >> I'm not very sure how widely this utilities will be used in the >> future. Looks like only BigIntegerModuloP uses this classes.? I may >> prefer to define private methods for byte array swap in >> BigIntegerModuloP. > > It is also used by XDHPublicKeyImpl (in the XDH code review). XDH public > keys are represented as BigInteger, and I use the array reverse method > to convert encoded keys to BigInteger. > If it is not widely used by other classes, please have these methods in the class where is get called. The sun.security.util is exported to other modules as well, we may not want to add stuff into this package unless it is really necessary. >> >> MutableIntegerModuloP.java >> ========================== >> void conditionalSwapWith(MutableIntegerModuloP b, int swap); >> As the 'swap' parameter can only be 0 or 1, could it be a boolean >> parameter? > > I couldn't come up with a way to implement this without branching when > the swap parameter is boolean. See IntegerPolynomial.conditionalSwap to > see how this is implemented in arithmetic with an int swap argument. If > you (or anyone) can think of a way to do this with boolean, let me know. > > I added a sentence to the comment above conditionalSwapWith that > describes why it is an int instead of a boolean. > I did not get the point about the need to avoid branching. Can you have more details? >> >> Except the conditionalSwapWith() method, I did not get the points why >> we need a mutable version.? Would you please have more description of >> this requirement? > > The comment above the class definition has this sentence: > > "This interface can be used to improve performance and avoid the > allocation of a large number of temporary objects." > > Do you need more information than this in the comments? The performance > motivation is so that a.add(b).multiply(c)... can be done without > allocating a new buffer for each operation. For example, without mutable > field elements, an X25519 point multiplication would allocate around > 4,300 temporary arrays totaling 350,000 bytes. If I remember correctly, > switching the X25519 implementation to mutable field elements reduced > the point multiplication time by about half. > I see your point. The benefits is obviously. OK, why you need the immutable version then? Sounds like the mutable version interface is sufficient, including performance. If an immutable version is really needed, we can have the implementation making the decision. Accordingly, the conditionalSwapWith() can be defined as optional method, if it is not required to be implemented in immutable implementation. It's confusing to me that the immutable and mutable and the base versions/interfaces mixed together. It would be nice if we can simplify the interface a little bit. For internal APIs, sometimes we don't want the same quality level as public APIs. I think this set of class will be widely used by new EC curves, ChaCha20/Poly1305, or more in the future. It would be nice if we could do it good at the beginning. >> >> >> IntegerModuloP_Base.java >> ======================== >> default byte[] addModPowerTwo(IntegerModuloP_Base b, int len) >> void addModPowerTwo(IntegerModuloP_Base b, byte[] result); >> >> For the first sign of the method names, I thought it is to calculate >> as "(this + b) ^ 2 mod m". > > To be precise, it calculates "((this % p) + (b % p)) % 2^m" (where p is > the prime that defines the field, and m is the desired length, in bits). > Note that the addition here is normal integer addition (not addition in > GF(p)). > > This operation is not used in XDH, but it is used in Poly1305 to add the > AES encryption of a nonce to a field element. So you can get more > information about this operation by reading the Poly1305 paper/RFC. > I was not meant to say the function of the method. I meant that the method name is a little bit misleading, not very straightforward to me. >> Besides, what's the benefits of the two methods?? Could we just use: >> ????? this.add(b).asByteArray() > > No, because that would calculate "((this + b) mod p) mod 2^m". The value > of (this + b) can be larger than p, so this would not produce the > desired result. > >> >> I guess, but not very sure, it is for constant time calculation. If >> the function is required, could it be renamed as: >> >> ????? // the result is inside of the size range >> ????? IntegerModuloP addModSize(IntegerModuloP_Base b, int size) >> Or >> ????? // the result is wrapped if outside of the size range >> ????? IntegerModuloP addOnWrap(IntegerModuloP_Base b, int size) >> >> and the use may look like: >> ????? this.addModSize(b, size).asByteArray() >> > > Any attempt to perform the addition in IntegerModuloP and then pull out > the byte array will not work. Does it mean if I perform a addition, and cannot get the byte array in the following step? that = this.add(b); byte[] bs = that.asByteArray(); // does not work? or byte[] bs = that.asByteArray(length); // does not work? or byte[] bs = that.asByteArray(byteArray); // does not work? > This class can only represent field > elements, so the sum would be in the field, which is not what we want. > I did not get the point. If getting an add result, the add is done (sum in the field). Did you have an example that pulling out the byte array will not work? Xuelei >> >> Will review the rest when I understand more about the interfaces design. >> >> Thanks, >> Xuelei >> >> On 1/30/2018 8:52 AM, Adam Petcher wrote: >>> +core-libs-dev >>> >>> >>> On 1/26/2018 4:06 PM, Adam Petcher wrote: >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181594 >>>> Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/ >>>> >>>> This is a code review for the field arithmetic that will be used in >>>> implementations of X25519/X448 key agreement, the Poly1305 >>>> authenticator, and EdDSA signatures. I believe that the library has >>>> all the features necessary for X25519/X448 and Poly1305, and I >>>> expect at most a couple of minor enhancements will be required to >>>> support EdDSA. There is no public API for this library, so we can >>>> change it in the future to suit the needs of new algorithms without >>>> breaking compatibility with external code. Still, I made an attempt >>>> to clearly structure and document the (internal) API, and I want to >>>> make sure it is understandable and easy to use. >>>> >>>> This is not a general-purpose modular arithmetic library. It will >>>> only work well in circumstances where the sequence of operations is >>>> restricted, and where the prime that defines the field has some >>>> useful structure. Moreover, each new field will require some >>>> field-specific code that takes into account the structure of the >>>> prime and the way the field is used in the application. The initial >>>> implementation includes a field for Poly1305 and the fields for >>>> X25519/X448 which should also work for EdDSA. >>>> >>>> The benefits of using this library are that it is much more >>>> efficient than using similar operations in BigInteger. Also, many >>>> operations are branch-free, making them suitable for use in a >>>> side-channel resistant implementation that does not branch on secrets. >>>> >>>> To provide some context, I have attached a code snippet describing >>>> how this library can be used. The snippet is the constant-time >>>> Montgomery ladder from my X25519/X448 implementation, which I expect >>>> to be out for review soon. X25519/X448 only uses standard arithmetic >>>> operations, and the more unusual features (e.g. add modulo a power >>>> of 2) are needed by Poly1305. >>>> >>>> The field arithmetic (for all fields) is implemented using a 32-bit >>>> representation similar to the one described in the Ed448 paper[1] >>>> (in the "Implementation on 32-bit platforms" section). Though my >>>> implementation uses signed limbs, and grade-school multiplication >>>> instead of Karatsuba. The argument for correctness is essentially >>>> the same for all three fields: the magnitude of each 64-bit limb is >>>> at most 2^(k-1) after reduction, except for the last limb which may >>>> have a magnitude of up to 2^k. The values of k are between 26 to 28 >>>> (depending on the field), and we can calculate that the maximum >>>> magnitude for any limb during an add-multiply-carry-reduce sequence >>>> is always less than 2^63. Therefore, no overflow occurs and all >>>> operations are correct. >>>> >>>> Process note: this enhancement is part of JEP 324 (Key Agreement >>>> with Curve25519 and Curve448). When this code review is complete, >>>> nothing will happen until all other work for this JEP is complete, >>>> and the JEP is accepted as part of some release. This means that >>>> this code will be pushed to the repo along with the X25519/X448 code >>>> that uses it. >>>> >>>> [1] https://eprint.iacr.org/2015/625.pdf >>>> >>>> >>>> >>> > From xuelei.fan at oracle.com Sun Mar 11 19:18:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 11 Mar 2018 12:18:05 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: test/jdk/sun/security/ssl/internal/TEST.properties test/jdk/sun/security/ssl/internal/TestRun.java test/jdk/sun/security/ssl/internal/java.base/sun/security/ssl/TestHkdf.java ---------------------- Why put the test in a internal/java.base/.. sub-directory? I did not get the point why it cannot be in the general test/jdk/sun/security/ssl/HKDF directory. Using the "sun.security.ssl" in a test does not sound right to me, too. I also run into testing failure: TestHkdf.java:162: error: cannot find symbol HKDF kdfHkdf; ^ symbol: class HKDF location: class TestHkdf Xuelei On 2/22/2018 12:29 PM, Xuelei Fan wrote: > Updated to use package private HKDF implementation. > > webrev (based on JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 > > webrev (including JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > Thanks, > Xuelei > > On 2/20/2018 11:57 AM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 full handshake >> implementation.? I appreciate it if I could have feedback before March >> 9, 2018. >> >> In the "JDK-8185576: New handshake implementation" [1] code review >> around, I was trying to re-org the TLS handshaking implementation in the >> SunJSSE provider.? If you had reviewed that part, you can start from >> the following webrev that based on the update of JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >> >> If you would like start from earlier, here is the webrev that contains >> the handshaking implementation re-org in JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> >> This changeset only implements the full handshake of TLS 1.3, rather >> then a fully implementation of the latest TLS 1.3 draft [2]. >> >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite.? I may >> not add them back if no objections. >> >> 2. OCSP stapling. >> This feature will be added back later. >> >> Resumption and key update, and more features may be added later. >> >> Thanks & Regards, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >> >> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From weijun.wang at oracle.com Mon Mar 12 06:42:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Mar 2018 14:42:47 +0800 Subject: RFR 8186228: sun/security/krb5/auto/KdcPolicy.java fails with "java.lang.Exception: Does not match. Output is c30000c30000c30000" Message-ID: <9469B6B1-8C8D-4116-8B2C-51988D27A2DD@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8186228/webrev.00/ Even a timeout of 30 seconds could happen, maybe because the UDP packet is lost. The change covers all possible output where each request has 3 chances of retry: without pre-auth with pre-auth ---------------- --------------- OK OK OK ERR OK OK ERR ERR OK OK ERR ERR ERR (failure) ERR OK OK .... ERR ERR OK ERR ERR OK ERR ERR OK ERR ERR ERR (failure) ERR ERR ERR (failure) Thanks Max From weijun.wang at oracle.com Mon Mar 12 11:39:51 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Mar 2018 19:39:51 +0800 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints Message-ID: I put "SHA-1" in a DisabledAlgorithmConstraints, it rejects SHA1 but allows sha1. The reason is that http://hg.openjdk.java.net/jdk/jdk/file/6b54e8cd9b3d/jdk/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java#l96 does not see "sha1". On the other hand, it rejects both "SHA-1" and "sha-1", because it's a direct case-insenstive match. Also, it allows both "SHA" and "sha" because there is no special code for it. Isn't "SHA" also an alias of "SHA-1"? Do you think all these names should be recognized? Shall we clarify it in the spec? Thanks Max From sean.mullan at oracle.com Mon Mar 12 14:41:36 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 12 Mar 2018 07:41:36 -0700 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: References: Message-ID: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> On 3/12/18 4:39 AM, Weijun Wang wrote: > I put "SHA-1" in a DisabledAlgorithmConstraints, it rejects SHA1 but allows sha1. That sounds like a bug. > > The reason is that http://hg.openjdk.java.net/jdk/jdk/file/6b54e8cd9b3d/jdk/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java#l96 does not see "sha1". > > On the other hand, it rejects both "SHA-1" and "sha-1", because it's a direct case-insenstive match. > > Also, it allows both "SHA" and "sha" because there is no special code for it. Isn't "SHA" also an alias of "SHA-1"? > > Do you think all these names should be recognized? Shall we clarify it in the spec? I would tend to think that we should only specify (or guarantee) that standard names are checked and used in the disabled algorithm properties. Aliases have never been a supported/standard feature, so I think if we start to accommodate them, then we have to document that and it increases the complexity of the code and chance that we might miss one. For example, SHA is an alias for SHA-1 in the JDK Sun provider but there is no corresponding alias for SHAwithRSA in the SunRsaSign provider, so it is inconsistent already. --Sean From jamil.j.nimeh at oracle.com Mon Mar 12 15:37:50 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 12 Mar 2018 08:37:50 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: <4ecbbf91-ff71-4868-fe4e-93503cff7a45@oracle.com> This approach is only necessary when running a test that exercises a class with package-private visibility. The test itself has to run from within sun/security/ssl in this case. Originally some of my OCSP stapling tests for internal classes did this, but didn't use this exact approach and then a few months after committing it to JDK 9 another engineer modified those tests to use this new format. I have to dig up the old emails to get the reasons why (maybe because of module support? I don't recall exactly), but ever since then I've followed this approach when I have to test class that only has package-private visibility. I made the internal dir in case there were other package-private sun.security.ssl classes that we might want to exercise (OCSP stapling will have some, for instance), and this could be a catch-all for those tests. If you prefer not to do it that way I'm happy to shuffle things around. I'm not sure why you're having the problem creating the HKDF object in the test. I don't have that problem when I run the test. I thought at first that maybe I hadn't done an hg add on the HKDF.java file and then the commit would've skipped it, but I just checked the commit log this morning and it went back with everything else. Let's look at it together today. --Jamil On 03/11/2018 12:18 PM, Xuelei Fan wrote: > test/jdk/sun/security/ssl/internal/TEST.properties > test/jdk/sun/security/ssl/internal/TestRun.java > test/jdk/sun/security/ssl/internal/java.base/sun/security/ssl/TestHkdf.java > > ---------------------- > Why put the test in a internal/java.base/.. sub-directory? I did not > get the point why it cannot be in the general > test/jdk/sun/security/ssl/HKDF directory. Using the > "sun.security.ssl" in a test does not sound right to me, too. > > > I also run into testing failure: > > TestHkdf.java:162: error: cannot find symbol > HKDF kdfHkdf; > ^ > symbol: class HKDF > location: class TestHkdf > > > Xuelei > > On 2/22/2018 12:29 PM, Xuelei Fan wrote: >> Updated to use package private HKDF implementation. >> >> webrev (based on JDK-8185576): >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 >> >> webrev (including JDK-8185576): >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> Thanks, >> Xuelei >> >> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 full handshake >>> implementation. I appreciate it if I could have feedback before >>> March 9, 2018. >>> >>> In the "JDK-8185576: New handshake implementation" [1] code review >>> around, I was trying to re-org the TLS handshaking implementation in >>> the >>> SunJSSE provider. If you had reviewed that part, you can start from >>> the following webrev that based on the update of JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>> >>> If you would like start from earlier, here is the webrev that >>> contains the handshaking implementation re-org in JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> >>> This changeset only implements the full handshake of TLS 1.3, rather >>> then a fully implementation of the latest TLS 1.3 draft [2]. >>> >>> In this implementation, I removed: >>> 1. the KRB5 cipher suite implementation. >>> Please let me know if you are still using KRB5 cipher suite. I may >>> not add them back if no objections. >>> >>> 2. OCSP stapling. >>> This feature will be added back later. >>> >>> Resumption and key update, and more features may be added later. >>> >>> Thanks & Regards, >>> Xuelei >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>> >>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From ecki at zusammenkunft.net Mon Mar 12 19:07:41 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 12 Mar 2018 19:07:41 +0000 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> References: , <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> Message-ID: I always thought the logic is ?case insensitive substring of canonical name?, so it also works with things like ?DHE? in ciphers. In that case ?SHA? would match SHA-1 as well as SHA-xxx. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev on behalf of Sean Mullan Sent: Monday, March 12, 2018 3:41:36 PM To: Weijun Wang; security-dev at openjdk.java.net Subject: Re: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints On 3/12/18 4:39 AM, Weijun Wang wrote: > I put "SHA-1" in a DisabledAlgorithmConstraints, it rejects SHA1 but allows sha1. That sounds like a bug. > > The reason is that http://hg.openjdk.java.net/jdk/jdk/file/6b54e8cd9b3d/jdk/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java#l96 does not see "sha1". > > On the other hand, it rejects both "SHA-1" and "sha-1", because it's a direct case-insenstive match. > > Also, it allows both "SHA" and "sha" because there is no special code for it. Isn't "SHA" also an alias of "SHA-1"? > > Do you think all these names should be recognized? Shall we clarify it in the spec? I would tend to think that we should only specify (or guarantee) that standard names are checked and used in the disabled algorithm properties. Aliases have never been a supported/standard feature, so I think if we start to accommodate them, then we have to document that and it increases the complexity of the code and chance that we might miss one. For example, SHA is an alias for SHA-1 in the JDK Sun provider but there is no corresponding alias for SHAwithRSA in the SunRsaSign provider, so it is inconsistent already. --Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Mar 12 20:19:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 12 Mar 2018 13:19:10 -0700 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: References: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> Message-ID: <5e9bcfdf-ec5f-b1c3-ed91-b854c3a5fdac@oracle.com> On 3/12/18 12:07 PM, Bernd Eckenfels wrote: > I always thought the logic is ?case insensitive substring of canonical > name?, so it also works with things like ?DHE? in ciphers. In that case > ?SHA? would match SHA-1 as well as SHA-xxx. Right, I was more making the point that you shouldn't expect aliases to match their corresponding names. For example, if you block on the alias "Rijndael", you should not assume it will block "AES". --Sean > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *From:* security-dev on behalf > of Sean Mullan > *Sent:* Monday, March 12, 2018 3:41:36 PM > *To:* Weijun Wang; security-dev at openjdk.java.net > *Subject:* Re: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints > On 3/12/18 4:39 AM, Weijun Wang wrote: >> I put "SHA-1" in a DisabledAlgorithmConstraints, it rejects SHA1 but allows sha1. > > That sounds like a bug. > >> >> The reason is that http://hg.openjdk.java.net/jdk/jdk/file/6b54e8cd9b3d/jdk/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java#l96 > does not see "sha1". >> >> On the other hand, it rejects both "SHA-1" and "sha-1", because it's a direct case-insenstive match. >> >> Also, it allows both "SHA" and "sha" because there is no special code for it. Isn't "SHA" also an alias of "SHA-1"? >> >> Do you think all these names should be recognized? Shall we clarify it in the spec? > > I would tend to think that we should only specify (or guarantee) that > standard names are checked and used in the disabled algorithm > properties. Aliases have never been a supported/standard feature, so I > think if we start to accommodate them, then we have to document that and > it increases the complexity of the code and chance that we might miss > one. For example, SHA is an alias for SHA-1 in the JDK Sun provider but > there is no corresponding alias for SHAwithRSA in the SunRsaSign > provider, so it is inconsistent already. > > --Sean From sean.mullan at oracle.com Mon Mar 12 22:03:49 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 12 Mar 2018 15:03:49 -0700 Subject: RFR 8171277: Elliptic Curves for Security in Crypto In-Reply-To: References: Message-ID: On 3/9/18 8:25 AM, Adam Petcher wrote: > New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/ > >> I think somewhere there should be a sentence or two on the difference >> between XECKeys and ECKeys and when you would want to use each. This >> is important enough that I think some detail should be in the javadoc >> to help users distinguish them. Perhaps put it in the XEC class >> description. Maybe more details can go in the JCA security guide. > > I added a sentence to the comments in XECKey, but I'm not sure how much > we should say here. I don't know if we should get into mathematical > details. Take a look at the new wording and let me know if I should add > more information. Looks good. I would probably also put a similar sentence in the XECPublicKey and XECPrivateKey classes just so it is not missed. All other changes look good. --Sean From weijun.wang at oracle.com Tue Mar 13 00:29:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 13 Mar 2018 08:29:50 +0800 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: <5e9bcfdf-ec5f-b1c3-ed91-b854c3a5fdac@oracle.com> References: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> <5e9bcfdf-ec5f-b1c3-ed91-b854c3a5fdac@oracle.com> Message-ID: > On Mar 13, 2018, at 4:19 AM, Sean Mullan wrote: > > On 3/12/18 12:07 PM, Bernd Eckenfels wrote: >> I always thought the logic is ?case insensitive substring of canonical name?, so it also works with things like ?DHE? in ciphers. In that case ?SHA? would match SHA-1 as well as SHA-xxx. Really? my understanding is that SHA is an alias of SHA-1 and I never thought it covers SHA-256 etc., at least not in this case. --Max > Right, I was more making the point that you shouldn't expect aliases to match their corresponding names. For example, if you block on the alias "Rijndael", you should not assume it will block "AES". > > --Sean > >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *From:* security-dev on behalf of Sean Mullan >> *Sent:* Monday, March 12, 2018 3:41:36 PM >> *To:* Weijun Wang; security-dev at openjdk.java.net >> *Subject:* Re: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints >> On 3/12/18 4:39 AM, Weijun Wang wrote: >>> I put "SHA-1" in a DisabledAlgorithmConstraints, it rejects SHA1 but allows sha1. >> That sounds like a bug. >>> The reason is that http://hg.openjdk.java.net/jdk/jdk/file/6b54e8cd9b3d/jdk/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java#l96 >> does not see "sha1". >>> On the other hand, it rejects both "SHA-1" and "sha-1", because it's a direct case-insenstive match. >>> Also, it allows both "SHA" and "sha" because there is no special code for it. Isn't "SHA" also an alias of "SHA-1"? >>> Do you think all these names should be recognized? Shall we clarify it in the spec? >> I would tend to think that we should only specify (or guarantee) that >> standard names are checked and used in the disabled algorithm >> properties. Aliases have never been a supported/standard feature, so I >> think if we start to accommodate them, then we have to document that and >> it increases the complexity of the code and chance that we might miss >> one. For example, SHA is an alias for SHA-1 in the JDK Sun provider but >> there is no corresponding alias for SHAwithRSA in the SunRsaSign >> provider, so it is inconsistent already. >> --Sean From weijun.wang at oracle.com Tue Mar 13 08:06:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 13 Mar 2018 16:06:56 +0800 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> References: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> Message-ID: <276C3810-05FB-49CF-AAB1-C9C03975C9DF@oracle.com> > On Mar 12, 2018, at 10:41 PM, Sean Mullan wrote: > > I would tend to think that we should only specify (or guarantee) that standard names are checked and used in the disabled algorithm properties. But this means first we must only set standard names in the properties. What if someone sets a non-standard one? Do we just accept it as a raw string and only reject an algorithm if it is also using the non-standard name? --Max From xuelei.fan at oracle.com Tue Mar 13 15:54:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Mar 2018 08:54:05 -0700 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: <276C3810-05FB-49CF-AAB1-C9C03975C9DF@oracle.com> References: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> <276C3810-05FB-49CF-AAB1-C9C03975C9DF@oracle.com> Message-ID: <32622968-538e-658e-57db-1134cf5b55d2@oracle.com> On 3/13/2018 1:06 AM, Weijun Wang wrote: > > >> On Mar 12, 2018, at 10:41 PM, Sean Mullan wrote: >> >> I would tend to think that we should only specify (or guarantee) that standard names are checked and used in the disabled algorithm properties. > > But this means first we must only set standard names in the properties. What if someone sets a non-standard one? Do we just accept it as a raw string and only reject an algorithm if it is also using the non-standard name? > Where does the non-standard name come from? Maybe, before calling into the crypto constraints methods, the name can be standardized. Xuelei From weijun.wang at oracle.com Wed Mar 14 00:13:59 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Mar 2018 08:13:59 +0800 Subject: About duplicate aliases in MSCAPI keystore Message-ID: I am looking at this bug https://bugs.openjdk.java.net/browse/JDK-8185844 MSCAPI doesn't list aliases correctly For the Windows-MY keystore, if you call setEntry() on the same alias (say, "alias") twice, the keystore shows only one entry with the alias. But after closing and re-loading, two are shown, "alias", and "alias (1)". I know the Windows tool certutil.exe can be used to add 2 entries with the same name, and both will be stored. In this case, if we use Java to load the keystore, we will have to list both, with different aliases. But do we really need to support it on the Java side? Can we just overwrite the previous entry when setEntry() is called on an existing alias? Was this designed as a feature? Thanks Max From weijun.wang at oracle.com Wed Mar 14 01:17:32 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Mar 2018 09:17:32 +0800 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: <32622968-538e-658e-57db-1134cf5b55d2@oracle.com> References: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> <276C3810-05FB-49CF-AAB1-C9C03975C9DF@oracle.com> <32622968-538e-658e-57db-1134cf5b55d2@oracle.com> Message-ID: > On Mar 13, 2018, at 11:54 PM, Xuelei Fan wrote: > > On 3/13/2018 1:06 AM, Weijun Wang wrote: >>> On Mar 12, 2018, at 10:41 PM, Sean Mullan wrote: >>> >>> I would tend to think that we should only specify (or guarantee) that standard names are checked and used in the disabled algorithm properties. >> But this means first we must only set standard names in the properties. What if someone sets a non-standard one? Do we just accept it as a raw string and only reject an algorithm if it is also using the non-standard name? > Where does the non-standard name come from? The setting inside java.security. I know we use standard names now, but customer can change it. > Maybe, before calling into the crypto constraints methods, the name can be standardized. We will need a table, not based on aliases in any provider. --Max > > Xuelei From sean.coffey at oracle.com Wed Mar 14 14:48:07 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 14 Mar 2018 14:48:07 +0000 Subject: RFR: 8165996:PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite Message-ID: Looking to backport this fix to jdk8u-dev. Contributed to JDK Project by Martin Balao. https://bugs.openjdk.java.net/browse/JDK-8165996 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8165996.8u/webrev/ The test/jdk/sun/security/pkcs11/PKCS11Test.java edits didn't seem applicable to jdk8u. Also, I edited sun/security/pkcs11/Secmod/TestNssDbSqlite.java to exclude test where NSS Provider didn't register. (line 66). In particular, I saw this while running 32bit JDK tests on 64 bit Linux. -- Regards, Sean. From mbalao at redhat.com Wed Mar 14 14:55:14 2018 From: mbalao at redhat.com (Martin Balao) Date: Wed, 14 Mar 2018 11:55:14 -0300 Subject: RFR: 8165996:PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: References: Message-ID: Hi Sean, Is this related to http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016776.html ? Kind regards, Martin.- On Wed, Mar 14, 2018 at 11:48 AM, Se?n Coffey wrote: > Looking to backport this fix to jdk8u-dev. Contributed to JDK Project by > Martin Balao. > > https://bugs.openjdk.java.net/browse/JDK-8165996 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8165996.8u/webrev/ > > The test/jdk/sun/security/pkcs11/PKCS11Test.java edits didn't seem > applicable to jdk8u. > > Also, I edited sun/security/pkcs11/Secmod/TestNssDbSqlite.java to exclude > test where NSS Provider > didn't register. (line 66). In particular, I saw this while running 32bit > JDK tests on 64 bit Linux. > > -- > Regards, > Sean. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Mar 14 15:05:55 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 14 Mar 2018 15:05:55 +0000 Subject: RFR: 8165996:PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: References: Message-ID: Hi Martin, Thanks for the 8195607 pointer. I'll get this ported to jdk8u also. I didn't see that actual issue during testing but no harm to port it. Will submit a new webrev shortly. Regards, Sean. On 14/03/18 14:55, Martin Balao wrote: > Hi Sean, > > Is this related to > http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016776.html ? > > Kind regards, > Martin.- > > On Wed, Mar 14, 2018 at 11:48 AM, Se?n Coffey > wrote: > > Looking to backport this fix to jdk8u-dev. Contributed to JDK > Project by Martin Balao. > > https://bugs.openjdk.java.net/browse/JDK-8165996 > > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8165996.8u/webrev/ > > > The test/jdk/sun/security/pkcs11/PKCS11Test.java edits didn't seem > applicable to jdk8u. > > Also, I edited sun/security/pkcs11/Secmod/TestNssDbSqlite.java to > exclude test where NSS Provider > didn't register. (line 66). In particular, I saw this while > running 32bit JDK tests on 64 bit Linux. > > -- > Regards, > Sean. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Wed Mar 14 16:11:15 2018 From: mbalao at redhat.com (Martin Balao) Date: Wed, 14 Mar 2018 13:11:15 -0300 Subject: RFR: 8165996:PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: References: Message-ID: Hi Sean, Thanks! Can you please review the fix [0] so we have it in? As far as I know, fix makes Oracle internal tests pass. Kind regards, Martin.- -- [0] - http://mail.openjdk.java.net/pipermail/security-dev/ 2018-February/016776.html On Wed, Mar 14, 2018 at 12:05 PM, Se?n Coffey wrote: > Hi Martin, > > Thanks for the 8195607 pointer. I'll get this ported to jdk8u also. I > didn't see that actual issue during testing but no harm to port it. Will > submit a new webrev shortly. > > Regards, > Sean. > > On 14/03/18 14:55, Martin Balao wrote: > > Hi Sean, > > Is this related to http://mail.openjdk.java.net/pipermail/security-dev/ > 2018-February/016776.html ? > > Kind regards, > Martin.- > > On Wed, Mar 14, 2018 at 11:48 AM, Se?n Coffey > wrote: > >> Looking to backport this fix to jdk8u-dev. Contributed to JDK Project by >> Martin Balao. >> >> https://bugs.openjdk.java.net/browse/JDK-8165996 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8165996.8u/webrev/ >> >> The test/jdk/sun/security/pkcs11/PKCS11Test.java edits didn't seem >> applicable to jdk8u. >> >> Also, I edited sun/security/pkcs11/Secmod/TestNssDbSqlite.java to >> exclude test where NSS Provider >> didn't register. (line 66). In particular, I saw this while running 32bit >> JDK tests on 64 bit Linux. >> >> -- >> Regards, >> Sean. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Mar 14 18:04:01 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 14 Mar 2018 18:04:01 +0000 Subject: RFR: 8165996:PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: References: Message-ID: I'll have a look Martin, but it'll be better if we can get an NSS or PKCS11 expert to take a look. Any takers ? Can you expand some bit on the exact reason for your 8195607 changes ? Pointers to NSS changes etc. ? Regards, Sean. On 14/03/18 16:11, Martin Balao wrote: > Hi Sean, > > Thanks! > > Can you please review the fix [0] so we have it in? As far as I know, > fix makes Oracle internal tests pass. > > Kind regards, > Martin.- > > -- > [0] - > http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016776.html > > > On Wed, Mar 14, 2018 at 12:05 PM, Se?n Coffey > wrote: > > Hi Martin, > > Thanks for the 8195607 pointer. I'll get this ported to jdk8u > also. I didn't see that actual issue during testing but no harm to > port it. Will submit a new webrev shortly. > > Regards, > Sean. > > On 14/03/18 14:55, Martin Balao wrote: >> Hi Sean, >> >> Is this related to >> http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016776.html >> ? >> >> Kind regards, >> Martin.- >> >> On Wed, Mar 14, 2018 at 11:48 AM, Se?n Coffey >> > wrote: >> >> Looking to backport this fix to jdk8u-dev. Contributed to >> JDK Project by Martin Balao. >> >> https://bugs.openjdk.java.net/browse/JDK-8165996 >> >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8165996.8u/webrev/ >> >> >> The test/jdk/sun/security/pkcs11/PKCS11Test.java edits didn't >> seem applicable to jdk8u. >> >> Also, I edited >> sun/security/pkcs11/Secmod/TestNssDbSqlite.java to exclude >> test where NSS Provider >> didn't register. (line 66). In particular, I saw this while >> running 32bit JDK tests on 64 bit Linux. >> >> -- >> Regards, >> Sean. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Mar 14 21:50:48 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 22:50:48 +0100 Subject: RFR: JDK-8199636 Unify naming for jaas_unix and jaas_nt Message-ID: <0c202e34-28f6-4187-22bf-86308c7a17b8@oracle.com> For some odd reason, the native library compiled for jdk.security.auth is called jaas_unix on unix and jaas_nt on windows. There's no good reason for this, and it breaks with the common practice in OpenJDK. This patch renames both libraries to the basename "jaas" (that is, libjaas.so, libjaas.dylib or jaas.dll, depending on OS). Bug: https://bugs.openjdk.java.net/browse/JDK-8199636 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199636-rename-libjaas/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 14 23:18:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 00:18:10 +0100 Subject: RFR: JDK-8199640 Split up BUILD_LIBKRB5 into the two, unrelated compilations it consists of Message-ID: <0d4f4ca2-822a-6cc6-0de0-3f135193e48f@oracle.com> BUILD_LIBKRB5 is currently a strange chimera between compiling w2k_lsa_auth on windows, and osxkrb5 on macos. They do not share source code, name or compilation options. This patch separates them into two separate compilations, one for each platform, so that they then can follow the normal JDK pattern for compiling libs. Bug: https://bugs.openjdk.java.net/browse/JDK-8199640 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199640-split-up-BUILD_LIBJRB5/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Mar 14 23:24:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 16:24:35 -0700 Subject: RFR: JDK-8199636 Unify naming for jaas_unix and jaas_nt In-Reply-To: <0c202e34-28f6-4187-22bf-86308c7a17b8@oracle.com> References: <0c202e34-28f6-4187-22bf-86308c7a17b8@oracle.com> Message-ID: <65dea355-7865-3170-8ab4-24cc98529be0@oracle.com> Looks good. /Erik On 2018-03-14 14:50, Magnus Ihse Bursie wrote: > For some odd reason, the native library compiled for jdk.security.auth > is called jaas_unix on unix and jaas_nt on windows. There's no good > reason for this, and it breaks with the common practice in OpenJDK. > > This patch renames both libraries to the basename "jaas" (that is, > libjaas.so, libjaas.dylib or jaas.dll, depending on OS). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199636 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199636-rename-libjaas/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Mar 14 23:25:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 16:25:35 -0700 Subject: RFR: JDK-8199640 Split up BUILD_LIBKRB5 into the two, unrelated compilations it consists of In-Reply-To: <0d4f4ca2-822a-6cc6-0de0-3f135193e48f@oracle.com> References: <0d4f4ca2-822a-6cc6-0de0-3f135193e48f@oracle.com> Message-ID: <51ccdc51-354e-4230-098f-65d8b07fda73@oracle.com> Looks good. /Erik On 2018-03-14 16:18, Magnus Ihse Bursie wrote: > BUILD_LIBKRB5 is currently a strange chimera between compiling > w2k_lsa_auth on windows, and osxkrb5 on macos. They do not share > source code, name or compilation options. > > This patch separates them into two separate compilations, one for each > platform, so that they then can follow the normal JDK pattern for > compiling libs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199640 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199640-split-up-BUILD_LIBJRB5/webrev.01 > > /Magnus From tomas at primekey.se Thu Mar 15 14:53:30 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Thu, 15 Mar 2018 15:53:30 +0100 Subject: PKCS#11 provider issues with min and max size In-Reply-To: <0e20f50b-1830-67cc-ecad-f7adab14d0b9@oracle.com> References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> <041b119f-8341-2ddb-9347-dfcc552059c2@primekey.se> <4d8eccbc-9f2a-e42c-665f-a09be1626a94@oracle.com> <0e20f50b-1830-67cc-ecad-f7adab14d0b9@oracle.com> Message-ID: Hi Valerie, Sorry for delayed response, I've been away :-( Turns out there is a bug report for this already, although related to RSA keys, not EC as in my case. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8183107 I can not add additional information to the issue of course, but the information we exchanged here should be valuable input to this issue. Also that there are several users with this issue. Cheers, Tomas --- Meet us at RSA Conference, booth #1518. Use the code X8EPRIME to get your free expo pass. ********** PrimeKey Solutions AB Lundagatan 16, 171 63 Solna, Sweden Mob: +46 (0)707421096 Internet: www.primekey.se Twitter: twitter.com/primekeyPKI ********** On 2018-02-15 23:51, Valerie Peng wrote: > > Yes, please go ahead and file a bug for this. > Thanks! > Valerie > > On 2/13/2018 6:00 AM, Tomas Gustavsson wrote: >> Thanks for taking a look. >> >> I haven't created a bug for this (yet) Let me know if that would help. >> >> Regards, >> Tomas >> On 2018-02-09 20:04, Valerie Peng wrote: >>> Hmm, seems reasonable to support this in the provider configuration >>> file. >>> Or, on a similar note, but slightly different approach is to just add an >>> configuration option for disabling checking the supported key size >>> range. >>> Regards, >>> Valerie >>> >>> On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: >>>> I just realized that a natural place to configure provider behavior is >>>> in the provider construction, which is also per provider, so you can >>>> have multiple ones with different configuration. We are already >>>> using an >>>> InputStream to construct SunPKCS11, and adding more parameters to >>>> configure/override defaults would be natural. >>>> >>>> I.e.: >>>> ----- >>>> name =? >>>> library = ; >>>> slot = slot >>>> rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN >>>> rsakeygenmechminsize = 1024 >>>> rsakeygenmechmaxsize = 8192 >>>> >>>> attributes(*, CKO_PUBLIC_KEY, *) = { >>>> ??? CKA_TOKEN = false >>>> ??? CKA_ENCRYPT = true >>>> ??? CKA_VERIFY = true >>>> ??? CKA_WRAP = true >>>> } >>>> attributes(*, CKO_PRIVATE_KEY, *) = { >>>> ??? CKA_DERIVE = false >>>> ??? CKA_TOKEN = true >>>> ??? CKA_PRIVATE = true >>>> ??? CKA_SENSITIVE = true >>>> ??? CKA_EXTRACTABLE = false >>>> ??? CKA_DECRYPT = true >>>> ??? CKA_SIGN = true >>>> ??? CKA_UNWRAP = true >>>> } >>>> attributes(*, CKO_SECRET_KEY, *) = { >>>> ??? CKA_SENSITIVE = true >>>> ??? CKA_EXTRACTABLE = false >>>> ??? CKA_ENCRYPT = true >>>> ??? CKA_DECRYPT = true >>>> ??? CKA_SIGN = true >>>> ??? CKA_VERIFY = true >>>> ??? CKA_WRAP = true >>>> ??? CKA_UNWRAP = true >>>> } >>>> ----- >>>> >>>> Cheers, >>>> Tomas >>>> >>>> On 2018-02-09 09:55, Tomas Gustavsson wrote: >>>>> Hi, >>>>> >>>>> Thanks for the answer. (sorry I was out with the flu for a week) >>>>> >>>>>> I am not too keen to add an env var/system property to accommodate >>>>>> this >>>>>> kind of PKCS11 library bugs since this should be rare I hope. >>>>>> Valerie >>>>> Unfortunately I don't see it as rare and the impact is huge due to the >>>>> slow turnaround of HSM firmware. Due to FIPS certification and whatnot >>>>> HSM vendors do not fix simple things like this sometimes in years. >>>>> This >>>>> puts customers to a complete halt in the meantime. These are heavily >>>>> certified environments where re-certification alone takes at least 6 >>>>> months. >>>>> >>>>> Having worked with all major HSM vendors for many years I know that >>>>> PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 >>>>> natively, you can hack around by ignoring bad values, but when using >>>>> SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 >>>>> which is not for everyone. >>>>> >>>>> Due to the strictness of using SunPKCS11 compared to native PKCS#11, >>>>> some more flexibility in configuration would help a lot. >>>>> >>>>> For many years SunPKCS11 have worked great. But also the HSM world is >>>>> moving faster than they did 5 years ago, and unfortunately this means >>>>> that we're seeing a huge rise in PKCS#11 issues in the last year, >>>>> requiring quite a lot of hacking in SunPKCS11 to workaround. In theory >>>>> it should not be needed, but in practice it is. Faster evolution = >>>>> more >>>>> bugs. >>>>> >>>>> I just showed two real world use cases that you really need to be able >>>>> to work around. And these will not be the last. PKCS#11 is a complex >>>>> standard and implementors will rarely get it exactly right. >>>>> >>>>> Increased flexibility and more control around PKCS#11 will be >>>>> needed in >>>>> the future imho, or users will be forced to move to other solutions >>>>> like >>>>> JackNJI11. We'd much rather use SunPKCS11 but customers (end users) >>>>> can't get stuck between Java and HSM vendors in a fight who does >>>>> PKCS#11 >>>>> right or wrong. >>>>> >>>>> Cheers, >>>>> Tomas >>>>> >>>>> On 2018-02-01 01:07, Valerie Peng wrote: >>>>>> Thanks for the feedback. I suppose we can ignore values which >>>>>> obviously >>>>>> don't make sense such as 0 or max being less than min key size. >>>>>> However, if the underlying PKCS11 library vendors forgot to update >>>>>> the >>>>>> max value as in your comment#2, supposedly they should fix it. >>>>>> I am not too keen to add an env var/system property to accommodate >>>>>> this >>>>>> kind of PKCS11 library bugs since this should be rare I hope. >>>>>> Valerie >>>>>> >>>>>> On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> At some revision in the PKCS#11 provider there was introduced >>>>>>> checking >>>>>>> of C_GetMechanismInfo min and max sizes. >>>>>>> >>>>>>> This has turned out to be a bit fragile. Let me give two real world >>>>>>> examples: >>>>>>> >>>>>>> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >>>>>>> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >>>>>>> generate any EC keys at all. Needless to say, without the Java >>>>>>> check it >>>>>>> would be no problem. >>>>>>> >>>>>>> 131: C_GetMechanismInfo >>>>>>> 2018-01-30 07:52:20.740 >>>>>>> [in] slotID = 0x1 >>>>>>> ??? CKM_EC_KEY_PAIR_GEN >>>>>>> [out] pInfo: >>>>>>> CKM_EC_KEY_PAIR_GEN?????????? : min:0 max:0 flags:0x10001 ( Hardware >>>>>>> KeyPair ) >>>>>>> Returned:? 0 CKR_OK >>>>>>> >>>>>>> (we are reporting this to Amazon as well) >>>>>>> >>>>>>> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >>>>>>> 4096, but will happily generate 8192 bit keys. I.e. the reported >>>>>>> maxSize >>>>>>> is not true. >>>>>>> We have customers who used to generate 8192 bit RSA keys, but >>>>>>> after a >>>>>>> Java update can not do so anymore, because Java compares against >>>>>>> this >>>>>>> value. >>>>>>> >>>>>>> >>>>>>> * Suggestions: >>>>>>> >>>>>>> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >>>>>>> maxKeyLen are calculated, never allow maxKeyLen to be less than >>>>>>> minKeyLen. >>>>>>> >>>>>>> I.e. change the part: >>>>>>> ?????????? // auto-adjust default keysize in case it's out-of-range >>>>>>> ?????????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>>>>> ?????????????? keySize = minKeyLen; >>>>>>> ?????????? } >>>>>>> ?????????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>>>>> ?????????????? keySize = maxKeyLen; >>>>>>> ?????????? } >>>>>>> >>>>>>> To include something like: >>>>>>> ?????????? // auto-adjust default keysize in case it's out-of-range >>>>>>> ?????????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>>>>> ?????????????? keySize = minKeyLen; >>>>>>> ?????????? } >>>>>>> ?????????? if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >>>>>>> ?????????????? maxKeyLen = minKeyLen; >>>>>>> ?????????? } >>>>>>> ?????????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>>>>> ?????????????? keySize = maxKeyLen; >>>>>>> ?????????? } >>>>>>> >>>>>>> 2. Allow to ignore checking of maxKeyLen by some means, i.e. >>>>>>> allow to >>>>>>> ignore checking against C_GetMechanismInfo if you know that the HSM >>>>>>> does >>>>>>> not provide sane values. I.e. an environment variable for example >>>>>>> reverting back to the old behavior when these were ignored. >>>>>>> >>>>>>> Regards, >>>>>>> Tomas Gustavsson >>>>>>> > From yogesh.dabhi91 at gmail.com Thu Mar 15 15:55:11 2018 From: yogesh.dabhi91 at gmail.com (Yogesh Dabhi) Date: Thu, 15 Mar 2018 21:25:11 +0530 Subject: Integration and Junit test cases for security Message-ID: Hi, I want to understand the Java security package. Is there any integration case or Unit cases for this package so i can run it at my end? Regards Yogesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Mar 15 18:18:40 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 15 Mar 2018 11:18:40 -0700 Subject: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints In-Reply-To: <276C3810-05FB-49CF-AAB1-C9C03975C9DF@oracle.com> References: <90250b7b-a546-7b49-7256-dda84e77521c@oracle.com> <276C3810-05FB-49CF-AAB1-C9C03975C9DF@oracle.com> Message-ID: <0f1c1b96-340a-b0f4-3f91-2fda9904e37b@oracle.com> On 3/13/18 1:06 AM, Weijun Wang wrote: > > >> On Mar 12, 2018, at 10:41 PM, Sean Mullan wrote: >> >> I would tend to think that we should only specify (or guarantee) that standard names are checked and used in the disabled algorithm properties. > > But this means first we must only set standard names in the properties. What if someone sets a non-standard one? Do we just accept it as a raw string and only reject an algorithm if it is also using the non-standard name? If non-std names just work right now, that's ok but I don't think we should make any requirements that it is supported. Right now the property says: # The "AlgorithmName" is the standard algorithm name of the disabled # algorithm. And I would not change that. --Sean From sean.mullan at oracle.com Thu Mar 15 18:46:40 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 15 Mar 2018 11:46:40 -0700 Subject: RFR 8171277: Elliptic Curves for Security in Crypto In-Reply-To: References: Message-ID: I reviewed the rest of the code and only have 2 other comments: * XECIterative.java 53: typo s/taks/takes * Convert.java Since these are static methods that could be useful to other regression tests, consider moving this to a test library location and using the jtreg @library label. However, I'm ok if you don't do this now - we can always do it later. --Sean On 3/12/18 3:03 PM, Sean Mullan wrote: > On 3/9/18 8:25 AM, Adam Petcher wrote: >> New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/ >> > >>> I think somewhere there should be a sentence or two on the difference >>> between XECKeys and ECKeys and when you would want to use each. This >>> is important enough that I think some detail should be in the javadoc >>> to help users distinguish them. Perhaps put it in the XEC class >>> description. Maybe more details can go in the JCA security guide. >> >> I added a sentence to the comments in XECKey, but I'm not sure how >> much we should say here. I don't know if we should get into >> mathematical details. Take a look at the new wording and let me know >> if I should add more information. > > Looks good. I would probably also put a similar sentence in the > XECPublicKey and XECPrivateKey classes just so it is not missed. > > All other changes look good. > > --Sean From ecki at zusammenkunft.net Fri Mar 16 03:44:02 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 16 Mar 2018 04:44:02 +0100 Subject: Integration and Junit test cases for security In-Reply-To: References: Message-ID: <5aab3d82.8d3f1c0a.8f702.6385@mx.google.com> Hello Yogesh, I am not sure it is a good method to learn from those test cases, I would start from here: https://docs.oracle.com/javase/tutorial/security/ But here you go, some of the openjdk included Tests for various security aspects: http://hg.openjdk.java.net/jdk/jdk/file/422615764e12/test/jdk/java/security http://hg.openjdk.java.net/jdk/jdk/file/422615764e12/test/jdk/javax/security/auth http://hg.openjdk.java.net/jdk/jdk/file/422615764e12/test/jdk/com/sun/crypto/provider (and some more) Gruss Bernd -- http://bernd.eckenfels.net Von: Yogesh Dabhi Gesendet: Donnerstag, 15. M?rz 2018 19:11 An: security-dev at openjdk.java.net Betreff: Integration and Junit test cases for security Hi, I want to understand the Java security package. Is there any integration case or Unit cases for this package so i can run it at my end? Regards Yogesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Fri Mar 16 19:49:52 2018 From: mbalao at redhat.com (Martin Balao) Date: Fri, 16 Mar 2018 16:49:52 -0300 Subject: RFR: 8165996:PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: References: Message-ID: Hi Sean, This is a simple patch that contains: 1) a fix on the SQL db prefix: it should be sql: instead of sql:/ to avoid path errors (triggered on a new NSS library version); 2) minor enhancement to specify a pkcs11.txt configuration file (as secmod.db was used before, for the legacy db); and, 3) some minor debugging enhancements to get error codes out of NSS. I'll be grateful if someone can have a look at it. This proposal fixes an existing bug, that can be verified with Oracle's internal tests. I'm CC' Max to this email, as he was the one who notified me about the bug. Kind regards, Martin.- On Wed, Mar 14, 2018 at 3:04 PM, Se?n Coffey wrote: > I'll have a look Martin, but it'll be better if we can get an NSS or > PKCS11 expert to take a look. Any takers ? Can you expand some bit on the > exact reason for your 8195607 changes ? Pointers to NSS changes etc. ? > > Regards, > Sean. > > On 14/03/18 16:11, Martin Balao wrote: > > Hi Sean, > > Thanks! > > Can you please review the fix [0] so we have it in? As far as I know, fix > makes Oracle internal tests pass. > > Kind regards, > Martin.- > > -- > [0] - http://mail.openjdk.java.net/pipermail/security-dev/2018- > February/016776.html > > On Wed, Mar 14, 2018 at 12:05 PM, Se?n Coffey > wrote: > >> Hi Martin, >> >> Thanks for the 8195607 pointer. I'll get this ported to jdk8u also. I >> didn't see that actual issue during testing but no harm to port it. Will >> submit a new webrev shortly. >> >> Regards, >> Sean. >> >> On 14/03/18 14:55, Martin Balao wrote: >> >> Hi Sean, >> >> Is this related to http://mail.openjdk.java.ne >> t/pipermail/security-dev/2018-February/016776.html ? >> >> Kind regards, >> Martin.- >> >> On Wed, Mar 14, 2018 at 11:48 AM, Se?n Coffey >> wrote: >> >>> Looking to backport this fix to jdk8u-dev. Contributed to JDK Project >>> by Martin Balao. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8165996 >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8165996.8u/webrev/ >>> >>> The test/jdk/sun/security/pkcs11/PKCS11Test.java edits didn't seem >>> applicable to jdk8u. >>> >>> Also, I edited sun/security/pkcs11/Secmod/TestNssDbSqlite.java to >>> exclude test where NSS Provider >>> didn't register. (line 66). In particular, I saw this while running >>> 32bit JDK tests on 64 bit Linux. >>> >>> -- >>> Regards, >>> Sean. >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasadarao.koppula at oracle.com Tue Mar 20 10:16:28 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Tue, 20 Mar 2018 03:16:28 -0700 (PDT) Subject: [11] RFR: 8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days. Message-ID: Could you please review the changes Webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8187218 The tests was contributed by Weijun Wang. Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Tue Mar 20 14:50:55 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 20 Mar 2018 10:50:55 -0400 Subject: RFR 8181594: Efficient and constant-time modular arithmetic In-Reply-To: References: <7bd6c1ae-4173-4384-fc57-66d1b185ba56@oracle.com> <9021dd99-4ac1-f7a1-fc91-ab0a9cf1685b@oracle.com> Message-ID: <72822337-a8db-1807-6600-8b4cf628bb83@oracle.com> Latest webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.02/ Comments inline below. In addition, I also changed the name of IntegerModuloP_Base to IntegerModuloP, and IntegerModuloP to ImmutableIntegerModuloP. On 3/11/2018 12:04 PM, Xuelei Fan wrote: > On 2/26/2018 10:39 AM, Adam Petcher wrote: >> >> On 2/23/2018 12:46 PM, Xuelei Fan wrote: >> >>> ArrayUtil.java: >>> =============== >>> I'm not very sure how widely this utilities will be used in the >>> future. Looks like only BigIntegerModuloP uses this classes.? I may >>> prefer to define private methods for byte array swap in >>> BigIntegerModuloP. >> >> It is also used by XDHPublicKeyImpl (in the XDH code review). XDH >> public keys are represented as BigInteger, and I use the array >> reverse method to convert encoded keys to BigInteger. >> > If it is not widely used by other classes, please have these methods > in the class where is get called.?? The sun.security.util is exported > to other modules as well, we may not want to add stuff into this > package unless it is really necessary. Okay. I put these methods in BigIntegerModuloP and removed the ArrayUtil class. This array reverse code will be duplicated where it is used by XDH public keys (in the other code review). > >>> >>> MutableIntegerModuloP.java >>> ========================== >>> void conditionalSwapWith(MutableIntegerModuloP b, int swap); >>> As the 'swap' parameter can only be 0 or 1, could it be a boolean >>> parameter? >> >> I couldn't come up with a way to implement this without branching >> when the swap parameter is boolean. See >> IntegerPolynomial.conditionalSwap to see how this is implemented in >> arithmetic with an int swap argument. If you (or anyone) can think of >> a way to do this with boolean, let me know. >> >> I added a sentence to the comment above conditionalSwapWith that >> describes why it is an int instead of a boolean. >> > I did not get the point about the need to avoid branching.? Can you > have more details? The goal is to avoid things like if(secret){...}, in order to prevent the secrets from leaking into side channels (mostly timing and cache). The way this method is used by XDH, the swap parameter is a single bit of the private key. By storing this bit as an integer, and then doing the swap using only integer arithmetic, we can avoid branching which may leak the bits of the key. > >>> >>> Except the conditionalSwapWith() method, I did not get the points >>> why we need a mutable version.? Would you please have more >>> description of this requirement? >> >> The comment above the class definition has this sentence: >> >> "This interface can be used to improve performance and avoid the >> allocation of a large number of temporary objects." >> >> Do you need more information than this in the comments? The >> performance motivation is so that a.add(b).multiply(c)... can be done >> without allocating a new buffer for each operation. For example, >> without mutable field elements, an X25519 point multiplication would >> allocate around 4,300 temporary arrays totaling 350,000 bytes. If I >> remember correctly, switching the X25519 implementation to mutable >> field elements reduced the point multiplication time by about half. >> > I see your point.? The benefits is obviously. > > OK, why you need the immutable version then? Sounds like the mutable > version interface is sufficient, including performance. If an > immutable version is really needed, we can have the implementation > making the decision.? Accordingly, the conditionalSwapWith() can be > defined as optional method, if it is not required to be implemented in > immutable implementation. > > It's confusing to me that the immutable and mutable and the base > versions/interfaces mixed together.? It would be nice if we can > simplify the interface a little bit. > > For internal APIs, sometimes we don't want the same quality level as > public APIs.? I think this set of class will be widely used by new EC > curves, ChaCha20/Poly1305, or more in the future.? It would be nice if > we could do it good at the beginning. The mutable version adds the conditional swap as well as mutable versions of many of the basic operations. The XDH implementation uses both the mutable and immutable versions. The immutable version allows me to simplify the client code because I don't have to worry about whether some value has been modified. For example, the XDH code keeps a representation of 0, 1, and the constant that defines the curve as immutable values. So I prefer to have both. It complicates this API a bit, but it allows simpler and more robust code in the client of this API. > >>> >>> >>> IntegerModuloP_Base.java >>> ======================== >>> default byte[] addModPowerTwo(IntegerModuloP_Base b, int len) >>> void addModPowerTwo(IntegerModuloP_Base b, byte[] result); >>> >>> For the first sign of the method names, I thought it is to calculate >>> as "(this + b) ^ 2 mod m". >> >> To be precise, it calculates "((this % p) + (b % p)) % 2^m" (where p >> is the prime that defines the field, and m is the desired length, in >> bits). Note that the addition here is normal integer addition (not >> addition in GF(p)). >> >> This operation is not used in XDH, but it is used in Poly1305 to add >> the AES encryption of a nonce to a field element. So you can get more >> information about this operation by reading the Poly1305 paper/RFC. >> > I was not meant to say the function of the method.? I meant that the > method name is a little bit misleading, not very straightforward to me. > >>> Besides, what's the benefits of the two methods?? Could we just use: >>> ????? this.add(b).asByteArray() >> >> No, because that would calculate "((this + b) mod p) mod 2^m". The >> value of (this + b) can be larger than p, so this would not produce >> the desired result. >> ?>> >>> I guess, but not very sure, it is for constant time calculation. If >>> the function is required, could it be renamed as: >>> >>> ????? // the result is inside of the size range >>> ????? IntegerModuloP addModSize(IntegerModuloP_Base b, int size) >>> Or >>> ????? // the result is wrapped if outside of the size range >>> ????? IntegerModuloP addOnWrap(IntegerModuloP_Base b, int size) >>> >>> and the use may look like: >>> ????? this.addModSize(b, size).asByteArray() >>> >> >> Any attempt to perform the addition in IntegerModuloP and then pull >> out the byte array will not work. > Does it mean if I perform a addition, and cannot get the byte array in > the following step? > ???? that = this.add(b); > ???? byte[] bs = that.asByteArray();?????????? // does not work? > or > ???? byte[] bs = that.asByteArray(length);??? // does not work? > or > ???? byte[] bs = that.asByteArray(byteArray); // does not work? > >> This class can only represent field elements, so the sum would be in >> the field, which is not what we want. >> > I did not get the point.? If getting an add result, the add is done > (sum in the field).? Did you have an example that pulling out the byte > array will not work? Say we are in the field of integers modulo 269, and the final result of some computation will be stored in a single byte. In this example, we discard information when we truncate to the byte array. This may seem strange, but it is exactly what Poly1305 does. Now say we want to add x with itself, and x has the value 260. // x.add(x) has value 251 byte[] result = new byte[1]; x.add(x).asByteArray(result); // result has value 251 x.addModPowerTwo(x, result) // result has value 8 The difference between the two statements above is that the first one does a reduction mod 269 after the addition (and before converting to a byte array), while the second one does not. I can't split addModPowerTwo into two method calls without also adding another type for integers modulo a possibly-non-prime, and I didn't think it was worth the effort. I don't have a problem with renaming the method if you think this will make it more clear. Let me know which name you prefer. The name addModSize is probably okay, although technically we are reducing mod 2^size, so the name might be slightly misleading. Maybe something a little less precise like addToSize? From xuelei.fan at oracle.com Tue Mar 20 15:22:47 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 20 Mar 2018 08:22:47 -0700 Subject: RFR 8181594: Efficient and constant-time modular arithmetic In-Reply-To: <72822337-a8db-1807-6600-8b4cf628bb83@oracle.com> References: <7bd6c1ae-4173-4384-fc57-66d1b185ba56@oracle.com> <9021dd99-4ac1-f7a1-fc91-ab0a9cf1685b@oracle.com> <72822337-a8db-1807-6600-8b4cf628bb83@oracle.com> Message-ID: <241c0fc0-51cc-6e8b-b78a-7f2e6d33fdc8@oracle.com> I have no other comments. Thanks, Xuelei On 3/20/2018 7:50 AM, Adam Petcher wrote: > Latest webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.02/ > > Comments inline below. > > In addition, I also changed the name of IntegerModuloP_Base to > IntegerModuloP, and IntegerModuloP to ImmutableIntegerModuloP. > > > On 3/11/2018 12:04 PM, Xuelei Fan wrote: >> On 2/26/2018 10:39 AM, Adam Petcher wrote: >>> >>> On 2/23/2018 12:46 PM, Xuelei Fan wrote: >>> >>>> ArrayUtil.java: >>>> =============== >>>> I'm not very sure how widely this utilities will be used in the >>>> future. Looks like only BigIntegerModuloP uses this classes.? I may >>>> prefer to define private methods for byte array swap in >>>> BigIntegerModuloP. >>> >>> It is also used by XDHPublicKeyImpl (in the XDH code review). XDH >>> public keys are represented as BigInteger, and I use the array >>> reverse method to convert encoded keys to BigInteger. >>> >> If it is not widely used by other classes, please have these methods >> in the class where is get called.?? The sun.security.util is exported >> to other modules as well, we may not want to add stuff into this >> package unless it is really necessary. > > Okay. I put these methods in BigIntegerModuloP and removed the ArrayUtil > class. This array reverse code will be duplicated where it is used by > XDH public keys (in the other code review). > >> >>>> >>>> MutableIntegerModuloP.java >>>> ========================== >>>> void conditionalSwapWith(MutableIntegerModuloP b, int swap); >>>> As the 'swap' parameter can only be 0 or 1, could it be a boolean >>>> parameter? >>> >>> I couldn't come up with a way to implement this without branching >>> when the swap parameter is boolean. See >>> IntegerPolynomial.conditionalSwap to see how this is implemented in >>> arithmetic with an int swap argument. If you (or anyone) can think of >>> a way to do this with boolean, let me know. >>> >>> I added a sentence to the comment above conditionalSwapWith that >>> describes why it is an int instead of a boolean. >>> >> I did not get the point about the need to avoid branching.? Can you >> have more details? > > The goal is to avoid things like if(secret){...}, in order to prevent > the secrets from leaking into side channels (mostly timing and cache). > The way this method is used by XDH, the swap parameter is a single bit > of the private key. By storing this bit as an integer, and then doing > the swap using only integer arithmetic, we can avoid branching which may > leak the bits of the key. > >> >>>> >>>> Except the conditionalSwapWith() method, I did not get the points >>>> why we need a mutable version.? Would you please have more >>>> description of this requirement? >>> >>> The comment above the class definition has this sentence: >>> >>> "This interface can be used to improve performance and avoid the >>> allocation of a large number of temporary objects." >>> >>> Do you need more information than this in the comments? The >>> performance motivation is so that a.add(b).multiply(c)... can be done >>> without allocating a new buffer for each operation. For example, >>> without mutable field elements, an X25519 point multiplication would >>> allocate around 4,300 temporary arrays totaling 350,000 bytes. If I >>> remember correctly, switching the X25519 implementation to mutable >>> field elements reduced the point multiplication time by about half. >>> >> I see your point.? The benefits is obviously. >> >> OK, why you need the immutable version then? Sounds like the mutable >> version interface is sufficient, including performance. If an >> immutable version is really needed, we can have the implementation >> making the decision.? Accordingly, the conditionalSwapWith() can be >> defined as optional method, if it is not required to be implemented in >> immutable implementation. >> >> It's confusing to me that the immutable and mutable and the base >> versions/interfaces mixed together.? It would be nice if we can >> simplify the interface a little bit. >> >> For internal APIs, sometimes we don't want the same quality level as >> public APIs.? I think this set of class will be widely used by new EC >> curves, ChaCha20/Poly1305, or more in the future.? It would be nice if >> we could do it good at the beginning. > > The mutable version adds the conditional swap as well as mutable > versions of many of the basic operations. The XDH implementation uses > both the mutable and immutable versions. The immutable version allows me > to simplify the client code because I don't have to worry about whether > some value has been modified. For example, the XDH code keeps a > representation of 0, 1, and the constant that defines the curve as > immutable values. > > So I prefer to have both. It complicates this API a bit, but it allows > simpler and more robust code in the client of this API. > >> >>>> >>>> >>>> IntegerModuloP_Base.java >>>> ======================== >>>> default byte[] addModPowerTwo(IntegerModuloP_Base b, int len) >>>> void addModPowerTwo(IntegerModuloP_Base b, byte[] result); >>>> >>>> For the first sign of the method names, I thought it is to calculate >>>> as "(this + b) ^ 2 mod m". >>> >>> To be precise, it calculates "((this % p) + (b % p)) % 2^m" (where p >>> is the prime that defines the field, and m is the desired length, in >>> bits). Note that the addition here is normal integer addition (not >>> addition in GF(p)). >>> >>> This operation is not used in XDH, but it is used in Poly1305 to add >>> the AES encryption of a nonce to a field element. So you can get more >>> information about this operation by reading the Poly1305 paper/RFC. >>> >> I was not meant to say the function of the method.? I meant that the >> method name is a little bit misleading, not very straightforward to me. >> >>>> Besides, what's the benefits of the two methods?? Could we just use: >>>> ????? this.add(b).asByteArray() >>> >>> No, because that would calculate "((this + b) mod p) mod 2^m". The >>> value of (this + b) can be larger than p, so this would not produce >>> the desired result. >>> ?>> >>>> I guess, but not very sure, it is for constant time calculation. If >>>> the function is required, could it be renamed as: >>>> >>>> ????? // the result is inside of the size range >>>> ????? IntegerModuloP addModSize(IntegerModuloP_Base b, int size) >>>> Or >>>> ????? // the result is wrapped if outside of the size range >>>> ????? IntegerModuloP addOnWrap(IntegerModuloP_Base b, int size) >>>> >>>> and the use may look like: >>>> ????? this.addModSize(b, size).asByteArray() >>>> >>> >>> Any attempt to perform the addition in IntegerModuloP and then pull >>> out the byte array will not work. >> Does it mean if I perform a addition, and cannot get the byte array in >> the following step? >> ???? that = this.add(b); >> ???? byte[] bs = that.asByteArray();?????????? // does not work? >> or >> ???? byte[] bs = that.asByteArray(length);??? // does not work? >> or >> ???? byte[] bs = that.asByteArray(byteArray); // does not work? >> >>> This class can only represent field elements, so the sum would be in >>> the field, which is not what we want. >>> >> I did not get the point.? If getting an add result, the add is done >> (sum in the field).? Did you have an example that pulling out the byte >> array will not work? > > Say we are in the field of integers modulo 269, and the final result of > some computation will be stored in a single byte. In this example, we > discard information when we truncate to the byte array. This may seem > strange, but it is exactly what Poly1305 does. Now say we want to add x > with itself, and x has the value 260. > > // x.add(x) has value 251 > byte[] result = new byte[1]; > x.add(x).asByteArray(result); // result has value 251 > x.addModPowerTwo(x, result) // result has value 8 > > The difference between the two statements above is that the first one > does a reduction mod 269 after the addition (and before converting to a > byte array), while the second one does not. I can't split addModPowerTwo > into two method calls without also adding another type for integers > modulo a possibly-non-prime, and I didn't think it was worth the effort. > > I don't have a problem with renaming the method if you think this will > make it more clear. Let me know which name you prefer. The name > addModSize is probably okay, although technically we are reducing mod > 2^size, so the name might be slightly misleading. Maybe something a > little less precise like addToSize? > From adam.petcher at oracle.com Tue Mar 20 16:29:52 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 20 Mar 2018 12:29:52 -0400 Subject: RFR 8171277: Elliptic Curves for Security in Crypto In-Reply-To: References: Message-ID: Latest webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.02/ This webrev incorporates the changes from the field arithmetic code (in my other code review), as well as changes from Sean's comments. On 3/15/2018 2:46 PM, Sean Mullan wrote: > I reviewed the rest of the code and only have 2 other comments: > > * XECIterative.java > > 53: typo s/taks/takes > > * Convert.java > > Since these are static methods that could be useful to other > regression tests, consider moving this to a test library location and > using the jtreg @library label. However, I'm ok if you don't do this > now - we can always do it later. > > --Sean > > On 3/12/18 3:03 PM, Sean Mullan wrote: >> On 3/9/18 8:25 AM, Adam Petcher wrote: >>> New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/ >>> >> >>>> I think somewhere there should be a sentence or two on the >>>> difference between XECKeys and ECKeys and when you would want to >>>> use each. This is important enough that I think some detail should >>>> be in the javadoc to help users distinguish them. Perhaps put it in >>>> the XEC class description. Maybe more details can go in the JCA >>>> security guide. >>> >>> I added a sentence to the comments in XECKey, but I'm not sure how >>> much we should say here. I don't know if we should get into >>> mathematical details. Take a look at the new wording and let me know >>> if I should add more information. >> >> Looks good. I would probably also put a similar sentence in the >> XECPublicKey and XECPrivateKey classes just so it is not missed. >> >> All other changes look good. >> >> --Sean From sean.mullan at oracle.com Wed Mar 21 20:31:40 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 21 Mar 2018 16:31:40 -0400 Subject: RFR 8186228: sun/security/krb5/auto/KdcPolicy.java fails with "java.lang.Exception: Does not match. Output is c30000c30000c30000" In-Reply-To: <9469B6B1-8C8D-4116-8B2C-51988D27A2DD@oracle.com> References: <9469B6B1-8C8D-4116-8B2C-51988D27A2DD@oracle.com> Message-ID: <6f9d32dd-a871-c2a9-46b6-0ca295115b08@oracle.com> Looks ok to me. --Sean On 3/12/18 2:42 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8186228/webrev.00/ > > Even a timeout of 30 seconds could happen, maybe because the UDP packet is lost. The change covers all possible output where each request has 3 chances of retry: > > without pre-auth with pre-auth > ---------------- --------------- > OK OK > OK ERR OK > OK ERR ERR OK > OK ERR ERR ERR (failure) > > ERR OK OK > .... > ERR ERR OK ERR ERR OK > ERR ERR OK ERR ERR ERR (failure) > > ERR ERR ERR (failure) > > Thanks > Max > > From xuelei.fan at oracle.com Thu Mar 22 15:08:19 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Mar 2018 08:08:19 -0700 Subject: Draft JEP: TLS 1.3 Message-ID: <09e6e2b5-9365-652b-9a9a-97b9a1b28f31@oracle.com> This draft JEP contains a proposal to extend the SunJSSE provider to support the Transport Layer Security (TLS) Protocol Version 1.3 [1]. For more details, please see: https://bugs.openjdk.java.net/browse/JDK-8145252 Xuelei [1]: https://tools.ietf.org/html/draft-ietf-tls-tls13-28 From sean.mullan at oracle.com Thu Mar 22 15:52:29 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 22 Mar 2018 11:52:29 -0400 Subject: Draft JEP: TLS 1.3 In-Reply-To: <09e6e2b5-9365-652b-9a9a-97b9a1b28f31@oracle.com> References: <09e6e2b5-9365-652b-9a9a-97b9a1b28f31@oracle.com> Message-ID: <87a8a03b-3134-aaf7-477c-ba3b33e01c0a@oracle.com> On 3/22/18 11:08 AM, Xuelei Fan wrote: > This draft JEP contains a proposal to extend the SunJSSE provider to > support the Transport Layer Security (TLS) Protocol Version 1.3 [1]. > > For more details, please see: > https://bugs.openjdk.java.net/browse/JDK-8145252 See also http://openjdk.java.net/jeps/8145252 for a more readable format of the JEP. --Sean From mark.reinhold at oracle.com Thu Mar 22 21:19:21 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 22 Mar 2018 14:19:21 -0700 (PDT) Subject: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms Message-ID: <20180322211921.266111955BA@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/329 - Mark From lussnig at suche.org Thu Mar 22 22:26:54 2018 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Thu, 22 Mar 2018 23:26:54 +0100 Subject: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms In-Reply-To: <20180322211921.266111955BA@eggemoggin.niobe.net> References: <20180322211921.266111955BA@eggemoggin.niobe.net> Message-ID: Hi, is there any reason that the cipher and and the tls inclusion is split into two separate jep? And the second question is why is there no way for user to add new cipher suites that can be used in the tls protocol? Since i extend jdk8 with chacha for tls i know that it would be no big issue to add an API that allow to add new CipherSuites this would be an great improvement if the TLS-Protocol and the CIPHER-Implementation is more loose coupled. Also an plugin system for TLS-Hello Extensions would be great. Gru? Thomas On 3/22/2018 10:19 PM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/329 > > - Mark From weijun.wang at oracle.com Fri Mar 23 03:04:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 23 Mar 2018 11:04:33 +0800 Subject: RFR 8200152: KerberosString should use UTF-8 by default Message-ID: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> Please take a review of the code change and CSR at CSR: https://bugs.openjdk.java.net/browse/JDK-8200153 webrev: http://cr.openjdk.java.net/~weijun/8200152/webrev.00/ Thanks Max From magnus.ihse.bursie at oracle.com Fri Mar 23 13:56:34 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 14:56:34 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries Message-ID: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so we had to resort to using mapfiles (also known as linker scripts). This is no longer the case. Now all compilers we use support symbol visibility directives, in one form or another. We should start using this. Since this has been the only way to control symbol visibility on Windows, for most of the shared code, we already have proper JNIEXPORT decorations in place. If we fix the remaining platform-specific files to have proper JNIEXPORT tagging, then we can finally get rid of mapfiles. This fix removed mapfiles for all JDK libraries. It does not touch hotspot libraries nor JDK executables; they will have to wait for a future fix -- this was complex enough. This change will not have any impact on macosx, since we do not use mapfiles there, but instead export all symbols. (This is not a good idea, but I'll address that separately.) This change will also have a minimal impact on Windows. The only reason Windows is impacted at all, is that some changes needed by Solaris and Linux were simpler to fix for all platforms. I have strived for this change to have no impact on the actual generated code. Unfortunately, this was not possible to fully achieve. I do not believe that these changes will have any actual impact on the product, though. I will present the differences more in detail further down. Those who are not interested can probably skip that. The patch has passed tier1 testing and is currently running tier2 and tier3. Since the running code is more or less (see caveat below) unmodified, I don't expect any testing issues. Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 Details on changes: Most of the source code changes are (unsurprisingly) in java.base and java.desktop. Remaining changes are in jdk.crypto.ucrypto, jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. Source code changes does almost to 100% consists in decorating an exported function with JNIEXPORT. I have also followed the long-standing convention of adding JNICALL. This is a no-op on non-Windows platforms, so for most of the changes this is purely cosmetic (and possibly adding in robustness, should the function ever be used on Windows in the future). I have also followed the stylistic convention of putting "JNIEXPORT JNICALL" on a separate line. For some functions, however, this might cause a change in calling convention on Windows. Since this can not apply to exported functions on Windows (otherwise they would already have had JNIEXPORT), I do not think this matters anything. A few libraries did not have a mapfile, on Linux and/or Solaris. This actually meant that all symbols were exported. It is highly unclear if this was known and intended by the original make rule writer. I have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove this flag and fix proper exported symbols in the future. I have run the complete build using COMPARE_BUILD, and made a thourough analysis of the differences for Linux and Solaris. All native libraries have symbol differences, but most of them are trivial and/or harmless. As a result, most libraries have disasm differences as well, but these too seem trivial and harmless. The differences in symbols that are common to all libraries include: ?* Internal symbols such as __bss_start, _edata, _end and _fini are now global. (They are imported as such from the compiler libraries/archives, and we have no linker script to override this behavior). ?* The versioning tag SUNWprivate_1.1 is not included, and thus neither the .gnu.version_d symbol. ?* There are a few differences in the symbol and/or mangling of some local functions. I'm not sure what's causing this, but it's unlikely to have any effect on the product. Another common source for change in symbols is due to previous platform differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ... }", but do_foo was not in the mapfile, the symbol was exported on Windows but not on Linux and Solaris. (Presumable since it was not needed there, even though it was compiled for those platforms as well.) Now, with the mapfiles gone, do_foo() will be exported on all platforms. And contrary, functions that are compiled on all platforms, and were exported in mapfiles, but now have gotten an JNIEXPORT decoration, will now be visible even on Windows. (This accounts for half of the noticed symbol differences on Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't think the mess in source code were worth the keeping of binary confidence with the old build. A third common source for change in symbols is due to exported functions "leaking" across library borders. For instance, some functions in java.desktop is compiled in both libawt_xawt and libawt_headless, but they were previously only included in the mapfile for one of these libraries. Now, since the visibility is determined by the source code itself, it gets exported in both libraries. A variant of this is when a library depends on another JDK library, and includes the header file from that other library, which in turn declares a function as JNIEXPORT. This will cause the including library to also export the function. This accounts for the other half of the changes on Windows. A typical example of this is that multiple libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have not listed the libjvm re-exports below.) Note that? Java_java_io_FileOutputStream_close0 in java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported, and can probably be removed. Here is a detailed table showing and accounting for all the remaining differences found on Linux and Solaris: java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is now also exported on unix platforms due to JNIEXPORT. java.base/jspawnlauncher: On solaris, we also include libjava/childproc.o, which now exports less functions than it used to (it used to export all functions, now it is compiled with visibility=hidden). java.base/java(w).exe: Is now also exporting the following symbols due to added JNIEXPORT in libjli on Windows: (Yes, executables can export symbols on Windows. Confusing, I know.) ?JLI_AddArgsFromEnvVar ?JLI_CmdToArgs ?JLI_GetAppArgIndex ?JLI_GetStdArgc ?JLI_GetStdArgs ?JLI_InitArgProcessing ?JLI_Launch ?JLI_List_add ?JLI_List_new ?JLI_ManifestIterate ?JLI_MemAlloc ?JLI_MemFree ?JLI_PreprocessArg ?JLI_ReportErrorMessage ?JLI_ReportErrorMessageSys ?JLI_ReportExceptionDescription ?JLI_ReportMessage ?JLI_SetTraceLauncher ?JLI_StringDup java.desktop:/libawt_xawt: The following symbols are now also exported on linux and solaris due to JNIEXPORT: ?awt_DrawingSurface_FreeDrawingSurfaceInfo ?awt_DrawingSurface_GetDrawingSurfaceInfo ?awt_DrawingSurface_Lock ?awt_DrawingSurface_Unlock ?awt_GetColor The following symbols are now also exported on linux and solaris due to JNIEXPORT (they were previously ?exported only in libawt): ?Java_sun_awt_DebugSettings_setCTracingOn__Z ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I ?Java_sun_awt_X11GraphicsConfig_getNumColors java.desktop:/libawt_headless: The following symbols are now also exported due to JNIEXPORT (they were previously ?exported only in libawt_xawt and/or libawt): ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable ?X11SurfaceData_GetOps java.desktop/libawt: The following symbols are now also exported on Windows, due to added JNIEXPORT: ?SurfaceData_InitOps ?mul8table ?div8table ?doDrawPath ?doFillPath ?g_CMpDataID ?initInverseGrayLut ?make_dither_arrays ?make_uns_ordered_dither_array ?path2DFloatCoordsID ?path2DNumTypesID ?path2DTypesID ?path2DWindingRuleID ?sg2dStrokeHintID ?std_img_oda_blue ?std_img_oda_green ?std_img_oda_red ?std_odas_computed ?sunHints_INTVAL_STROKE_PURE java.desktop/libawt on solaris: A number of "#pragma weak" directives was previously overridden by the mapfile. Now these directives are respected, so these symbols are now weak instead of local: ?ByteGrayToIntArgbPreConvert_F ?ByteGrayToIntArgbPreScaleConvert_F ?IntArgbBmToFourByteAbgrPreScaleXparOver_F ?IntArgbToIntRgbXorBlit_F ?IntBgrToIntBgrAlphaMaskBlit_F java.desktop/libawt on solaris: These are now also exported due to JNIEXPORT in libmlib_image. ?j2d_mlib_ImageCreate ?j2d_mlib_ImageCreateStruct ?j2d_mlib_ImageDelete java.desktop/libawt on solaris: This is now also exported due to JNIEXPORT: ?GrPrim_CompGetXorColor ?SurfaceData_GetOpsNoSetup ?SurfaceData_IntersectBoundsXYWH ?SurfaceData_SetOps ?Transform_GetInfo ?Transform_transform java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and solaris due to JNIEXPORT. libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport)) but no JNICALL, which I added as a part of converting to JNIEXPORT. The same goes for libmlib_image . jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris due to JNIEXPORT in libnio. java.instrument:/libinstrument: Agent_OnUnload is now also exported on linux and solaris platforms due to JNIEXPORT. JLI_ManifestIterate is now also exported on Windows, due to added JNIEXPORT in libjli. jdk.management/libmanagement_ext: Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on linux and solaris platforms due to JNIEXPORT. /Magnus From erik.joelsson at oracle.com Fri Mar 23 14:30:14 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Mar 2018 07:30:14 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> I have looked at the build changes and they look good. Will you file followups for each component team to look over their exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt laying around here. /Erik On 2018-03-23 06:56, Magnus Ihse Bursie wrote: > With modern compilers, we can use compiler directives (such as > _attribute__((visibility("default"))), or __declspec(dllexport)) to > control symbol visibility, directly in the source code. This has > historically not been present on all compilers, so we had to resort to > using mapfiles (also known as linker scripts). > > This is no longer the case. Now all compilers we use support symbol > visibility directives, in one form or another. We should start using > this. Since this has been the only way to control symbol visibility on > Windows, for most of the shared code, we already have proper JNIEXPORT > decorations in place. > > If we fix the remaining platform-specific files to have proper > JNIEXPORT tagging, then we can finally get rid of mapfiles. > > This fix removed mapfiles for all JDK libraries. It does not touch > hotspot libraries nor JDK executables; they will have to wait for a > future fix -- this was complex enough. This change will not have any > impact on macosx, since we do not use mapfiles there, but instead > export all symbols. (This is not a good idea, but I'll address that > separately.) This change will also have a minimal impact on Windows. > The only reason Windows is impacted at all, is that some changes > needed by Solaris and Linux were simpler to fix for all platforms. > > I have strived for this change to have no impact on the actual > generated code. Unfortunately, this was not possible to fully achieve. > I do not believe that these changes will have any actual impact on the > product, though. I will present the differences more in detail further > down. Those who are not interested can probably skip that. > > The patch has passed tier1 testing and is currently running tier2 and > tier3. Since the running code is more or less (see caveat below) > unmodified, I don't expect any testing issues. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 > > Details on changes: > Most of the source code changes are (unsurprisingly) in java.base and > java.desktop. Remaining changes are in jdk.crypto.ucrypto, > jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. > > Source code changes does almost to 100% consists in decorating an > exported function with JNIEXPORT. I have also followed the > long-standing convention of adding JNICALL. This is a no-op on > non-Windows platforms, so for most of the changes this is purely > cosmetic (and possibly adding in robustness, should the function ever > be used on Windows in the future). I have also followed the stylistic > convention of putting "JNIEXPORT JNICALL" on a separate > line. For some functions, however, this might cause a change in > calling convention on Windows. Since this can not apply to exported > functions on Windows (otherwise they would already have had > JNIEXPORT), I do not think this matters anything. > > A few libraries did not have a mapfile, on Linux and/or Solaris. This > actually meant that all symbols were exported. It is highly unclear if > this was known and intended by the original make rule writer. I have > emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these > libraries. Hopefully, we can remove this flag and fix proper exported > symbols in the future. > > I have run the complete build using COMPARE_BUILD, and made a > thourough analysis of the differences for Linux and Solaris. All > native libraries have symbol differences, but most of them are trivial > and/or harmless. As a result, most libraries have disasm differences > as well, but these too seem trivial and harmless. The differences in > symbols that are common to all libraries include: > ?* Internal symbols such as __bss_start, _edata, _end and _fini are > now global. (They are imported as such from the compiler > libraries/archives, and we have no linker script to override this > behavior). > ?* The versioning tag SUNWprivate_1.1 is not included, and thus > neither the .gnu.version_d symbol. > ?* There are a few differences in the symbol and/or mangling of some > local functions. I'm not sure what's causing this, > but it's unlikely to have any effect on the product. > > Another common source for change in symbols is due to previous > platform differences. For instance, if we had "JNIEXPORT int JNICALL > do_foo() { ... }", but do_foo was not in the mapfile, the symbol was > exported on Windows but not on Linux and Solaris. (Presumable since it > was not needed there, even though it was compiled for those platforms > as well.) Now, with the mapfiles gone, do_foo() will be exported on > all platforms. And contrary, functions that are compiled on all > platforms, and were exported in mapfiles, but now have gotten an > JNIEXPORT decoration, will now be visible even on Windows. (This > accounts for half of the noticed symbol differences on Windows.) I > could have made the JNIEXPORT conditional on OS, but I didn't think > the mess in source code were worth the keeping of binary confidence > with the old build. > > A third common source for change in symbols is due to exported > functions "leaking" across library borders. For instance, some > functions in java.desktop is compiled in both libawt_xawt and > libawt_headless, but they were previously only included in the mapfile > for one of these libraries. Now, since the visibility is determined by > the source code itself, it gets exported in both libraries. A variant > of this is when a library depends on another JDK library, and includes > the header file from that other library, which in turn declares a > function as JNIEXPORT. This will cause the including library to also > export the function. This accounts for the other half of the changes > on Windows. A typical example of this is that multiple libraries now > re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have > not listed the libjvm re-exports below.) > > Note that? Java_java_io_FileOutputStream_close0 in > java.base/unix/native/libjava/FileOutputStream_md.c is no longer > exported, > and can probably be removed. > > Here is a detailed table showing and accounting for all the remaining > differences found on Linux and Solaris: > java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is > now also exported on unix platforms due to JNIEXPORT. > > java.base/jspawnlauncher: On solaris, we also include > libjava/childproc.o, which > now exports less functions than it used to (it used to export all > functions, now it is compiled with visibility=hidden). > > java.base/java(w).exe: Is now also exporting the following symbols due > to added JNIEXPORT in libjli on Windows: > (Yes, executables can export symbols on Windows. Confusing, I know.) > ?JLI_AddArgsFromEnvVar > ?JLI_CmdToArgs > ?JLI_GetAppArgIndex > ?JLI_GetStdArgc > ?JLI_GetStdArgs > ?JLI_InitArgProcessing > ?JLI_Launch > ?JLI_List_add > ?JLI_List_new > ?JLI_ManifestIterate > ?JLI_MemAlloc > ?JLI_MemFree > ?JLI_PreprocessArg > ?JLI_ReportErrorMessage > ?JLI_ReportErrorMessageSys > ?JLI_ReportExceptionDescription > ?JLI_ReportMessage > ?JLI_SetTraceLauncher > ?JLI_StringDup > > java.desktop:/libawt_xawt: The following symbols are now also exported > on linux and solaris due to JNIEXPORT: > ?awt_DrawingSurface_FreeDrawingSurfaceInfo > ?awt_DrawingSurface_GetDrawingSurfaceInfo > ?awt_DrawingSurface_Lock > ?awt_DrawingSurface_Unlock > ?awt_GetColor > > The following symbols are now also exported on linux and solaris due > to JNIEXPORT (they were previously > ?exported only in libawt): > ?Java_sun_awt_DebugSettings_setCTracingOn__Z > ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 > ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I > ?Java_sun_awt_X11GraphicsConfig_getNumColors > > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > ?exported only in libawt_xawt and/or libawt): > ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo > ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities > ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask > ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable > ?X11SurfaceData_GetOps > > java.desktop/libawt: The following symbols are now also exported on > Windows, due to added > JNIEXPORT: > ?SurfaceData_InitOps > ?mul8table > ?div8table > ?doDrawPath > ?doFillPath > ?g_CMpDataID > ?initInverseGrayLut > ?make_dither_arrays > ?make_uns_ordered_dither_array > ?path2DFloatCoordsID > ?path2DNumTypesID > ?path2DTypesID > ?path2DWindingRuleID > ?sg2dStrokeHintID > ?std_img_oda_blue > ?std_img_oda_green > ?std_img_oda_red > ?std_odas_computed > ?sunHints_INTVAL_STROKE_PURE > > java.desktop/libawt on solaris: > A number of "#pragma weak" directives was previously overridden by the > mapfile. > Now these directives are respected, so these symbols are now weak > instead of local: > ?ByteGrayToIntArgbPreConvert_F > ?ByteGrayToIntArgbPreScaleConvert_F > ?IntArgbBmToFourByteAbgrPreScaleXparOver_F > ?IntArgbToIntRgbXorBlit_F > ?IntBgrToIntBgrAlphaMaskBlit_F > > java.desktop/libawt on solaris: These are now also exported due to > JNIEXPORT in libmlib_image. > ?j2d_mlib_ImageCreate > ?j2d_mlib_ImageCreateStruct > ?j2d_mlib_ImageDelete > > java.desktop/libawt on solaris: This is now also exported due to > JNIEXPORT: > ?GrPrim_CompGetXorColor > ?SurfaceData_GetOpsNoSetup > ?SurfaceData_IntersectBoundsXYWH > ?SurfaceData_SetOps > ?Transform_GetInfo > ?Transform_transform > > java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and > solaris due to JNIEXPORT. > libspashscreen also had JNIEXPORT (actually a pure > _declspec(dllexport)) but no JNICALL, which I added as > a part of converting to JNIEXPORT. The same goes for libmlib_image . > > jdk.sctp/libsctp: handleSocketError is now exported on linux and > solaris due to JNIEXPORT in libnio. > > java.instrument:/libinstrument: Agent_OnUnload is now also exported on > linux and solaris platforms due to JNIEXPORT. > JLI_ManifestIterate is now also exported on Windows, due to added > JNIEXPORT in libjli. > > jdk.management/libmanagement_ext: > Java_com_sun_management_internal_Flag_setDoubleValue is now also > exported on linux and solaris platforms due to JNIEXPORT. > > /Magnus > > From Alan.Bateman at oracle.com Fri Mar 23 14:45:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Mar 2018 14:45:09 +0000 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> On 23/03/2018 13:56, Magnus Ihse Bursie wrote: > With modern compilers, we can use compiler directives (such as > _attribute__((visibility("default"))), or __declspec(dllexport)) to > control symbol visibility, directly in the source code. This has > historically not been present on all compilers, so we had to resort to > using mapfiles (also known as linker scripts). > > This is no longer the case. Now all compilers we use support symbol > visibility directives, in one form or another. We should start using > this. Since this has been the only way to control symbol visibility on > Windows, for most of the shared code, we already have proper JNIEXPORT > decorations in place. > > If we fix the remaining platform-specific files to have proper > JNIEXPORT tagging, then we can finally get rid of mapfiles. This seems like a great cleanup as the mapfile have always been a pain to maintain. Also shines a light on some technical debt too. handleSocketError in libnio is a surprise, this should not be exported and should not have been in the map file.? I suspect the issue is that jdk.sctp is missing a function prototype from its header file (it has its own handleSocketError in SctpNet.c). NET_Wait in libnet is another one, I can't tell why this was listed in the map file. I'm also surprised with java.dll exporting handleRead, winHandleRead, and handleLSeek. I didn't see them mentioned in your mail so I'm curious what might be using those. -Alan From magnus.ihse.bursie at oracle.com Fri Mar 23 15:15:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 16:15:35 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> Message-ID: > 23 mars 2018 kl. 15:45 skrev Alan Bateman : > >> On 23/03/2018 13:56, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so we had to resort to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol visibility directives, in one form or another. We should start using this. Since this has been the only way to control symbol visibility on Windows, for most of the shared code, we already have proper JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper JNIEXPORT tagging, then we can finally get rid of mapfiles. > This seems like a great cleanup as the mapfile have always been a pain to maintain. Also shines a light on some technical debt too. Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports. > handleSocketError in libnio is a surprise, this should not be exported and should not have been in the map file. I suspect the issue is that jdk.sctp is missing a function prototype from its header file (it has its own handleSocketError in SctpNet.c). That might be so, yes. > NET_Wait in libnet is another one, I can't tell why this was listed in the map file. Neither can I. :-) Once again, my goal with this patch was to keep the produced binaries as similar to before with the mapfiles. I'll be happy to file follow-up bugs listing all suspicious symbol handling I've encountered, but I'd rather not change anything about that in this patch. > I'm also surprised with java.dll exporting handleRead, winHandleRead, and handleLSeek. I didn't see them mentioned in your mail so I'm curious what might be using those. They were previously exported using -export: on the command line for the Microsoft linker. This was the case for a couple other libraries as well. Yeah, I forgot to write about that, sorry. :( Been a lot to keep track of, and it went away when I cleaned up my notes. Can I consider this a review? /Magnus > > -Alan From Alan.Bateman at oracle.com Fri Mar 23 16:04:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Mar 2018 16:04:12 +0000 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> Message-ID: <810a6225-15af-6858-8bea-2c3122ac1c5d@oracle.com> On 23/03/2018 15:15, Magnus Ihse Bursie wrote: > : > Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports. The changes looks good to me and I think we should follow this up with a few JIRA issues (as you suggested) for the symbols that don't make sense to export. -Alan From mandy.chung at oracle.com Fri Mar 23 16:05:23 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 23 Mar 2018 09:05:23 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> Message-ID: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> This is a very good change and no more mapfile to maintain!! Please do file JBS issues for the component teams to clean up their exports. Mandy On 3/23/18 7:30 AM, Erik Joelsson wrote: > I have looked at the build changes and they look good. > > Will you file followups for each component team to look over their > exported symbols, at least for the libraries with > $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt > laying around here. > > /Erik > > > On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as >> _attribute__((visibility("default"))), or __declspec(dllexport)) to >> control symbol visibility, directly in the source code. This has >> historically not been present on all compilers, so we had to resort >> to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol >> visibility directives, in one form or another. We should start using >> this. Since this has been the only way to control symbol visibility >> on Windows, for most of the shared code, we already have proper >> JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper >> JNIEXPORT tagging, then we can finally get rid of mapfiles. >> >> This fix removed mapfiles for all JDK libraries. It does not touch >> hotspot libraries nor JDK executables; they will have to wait for a >> future fix -- this was complex enough. This change will not have any >> impact on macosx, since we do not use mapfiles there, but instead >> export all symbols. (This is not a good idea, but I'll address that >> separately.) This change will also have a minimal impact on Windows. >> The only reason Windows is impacted at all, is that some changes >> needed by Solaris and Linux were simpler to fix for all platforms. >> >> I have strived for this change to have no impact on the actual >> generated code. Unfortunately, this was not possible to fully >> achieve. I do not believe that these changes will have any actual >> impact on the product, though. I will present the differences more in >> detail further down. Those who are not interested can probably skip >> that. >> >> The patch has passed tier1 testing and is currently running tier2 and >> tier3. Since the running code is more or less (see caveat below) >> unmodified, I don't expect any testing issues. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >> >> Details on changes: >> Most of the source code changes are (unsurprisingly) in java.base and >> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >> >> Source code changes does almost to 100% consists in decorating an >> exported function with JNIEXPORT. I have also followed the >> long-standing convention of adding JNICALL. This is a no-op on >> non-Windows platforms, so for most of the changes this is purely >> cosmetic (and possibly adding in robustness, should the function ever >> be used on Windows in the future). I have also followed the stylistic >> convention of putting "JNIEXPORT JNICALL" on a separate >> line. For some functions, however, this might cause a change in >> calling convention on Windows. Since this can not apply to exported >> functions on Windows (otherwise they would already have had >> JNIEXPORT), I do not think this matters anything. >> >> A few libraries did not have a mapfile, on Linux and/or Solaris. This >> actually meant that all symbols were exported. It is highly unclear >> if this was known and intended by the original make rule writer. I >> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these >> libraries. Hopefully, we can remove this flag and fix proper exported >> symbols in the future. >> >> I have run the complete build using COMPARE_BUILD, and made a >> thourough analysis of the differences for Linux and Solaris. All >> native libraries have symbol differences, but most of them are >> trivial and/or harmless. As a result, most libraries have disasm >> differences as well, but these too seem trivial and harmless. The >> differences in symbols that are common to all libraries include: >> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >> now global. (They are imported as such from the compiler >> libraries/archives, and we have no linker script to override this >> behavior). >> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >> neither the .gnu.version_d symbol. >> ?* There are a few differences in the symbol and/or mangling of some >> local functions. I'm not sure what's causing this, >> but it's unlikely to have any effect on the product. >> >> Another common source for change in symbols is due to previous >> platform differences. For instance, if we had "JNIEXPORT int JNICALL >> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >> exported on Windows but not on Linux and Solaris. (Presumable since >> it was not needed there, even though it was compiled for those >> platforms as well.) Now, with the mapfiles gone, do_foo() will be >> exported on all platforms. And contrary, functions that are compiled >> on all platforms, and were exported in mapfiles, but now have gotten >> an JNIEXPORT decoration, will now be visible even on Windows. (This >> accounts for half of the noticed symbol differences on Windows.) I >> could have made the JNIEXPORT conditional on OS, but I didn't think >> the mess in source code were worth the keeping of binary confidence >> with the old build. >> >> A third common source for change in symbols is due to exported >> functions "leaking" across library borders. For instance, some >> functions in java.desktop is compiled in both libawt_xawt and >> libawt_headless, but they were previously only included in the >> mapfile for one of these libraries. Now, since the visibility is >> determined by the source code itself, it gets exported in both >> libraries. A variant of this is when a library depends on another JDK >> library, and includes the header file from that other library, which >> in turn declares a function as JNIEXPORT. This will cause the >> including library to also export the function. This accounts for the >> other half of the changes on Windows. A typical example of this is >> that multiple libraries now re-export hotspot symbols from libjvm.so, >> like jio_fprintf. (I have not listed the libjvm re-exports below.) >> >> Note that? Java_java_io_FileOutputStream_close0 in >> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >> exported, >> and can probably be removed. >> >> Here is a detailed table showing and accounting for all the remaining >> differences found on Linux and Solaris: >> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >> is now also exported on unix platforms due to JNIEXPORT. >> >> java.base/jspawnlauncher: On solaris, we also include >> libjava/childproc.o, which >> now exports less functions than it used to (it used to export all >> functions, now it is compiled with visibility=hidden). >> >> java.base/java(w).exe: Is now also exporting the following symbols >> due to added JNIEXPORT in libjli on Windows: >> (Yes, executables can export symbols on Windows. Confusing, I know.) >> ?JLI_AddArgsFromEnvVar >> ?JLI_CmdToArgs >> ?JLI_GetAppArgIndex >> ?JLI_GetStdArgc >> ?JLI_GetStdArgs >> ?JLI_InitArgProcessing >> ?JLI_Launch >> ?JLI_List_add >> ?JLI_List_new >> ?JLI_ManifestIterate >> ?JLI_MemAlloc >> ?JLI_MemFree >> ?JLI_PreprocessArg >> ?JLI_ReportErrorMessage >> ?JLI_ReportErrorMessageSys >> ?JLI_ReportExceptionDescription >> ?JLI_ReportMessage >> ?JLI_SetTraceLauncher >> ?JLI_StringDup >> >> java.desktop:/libawt_xawt: The following symbols are now also >> exported on linux and solaris due to JNIEXPORT: >> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >> ?awt_DrawingSurface_GetDrawingSurfaceInfo >> ?awt_DrawingSurface_Lock >> ?awt_DrawingSurface_Unlock >> ?awt_GetColor >> >> The following symbols are now also exported on linux and solaris due >> to JNIEXPORT (they were previously >> ?exported only in libawt): >> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >> ?Java_sun_awt_X11GraphicsConfig_getNumColors >> >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> ?exported only in libawt_xawt and/or libawt): >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >> ?X11SurfaceData_GetOps >> >> java.desktop/libawt: The following symbols are now also exported on >> Windows, due to added >> JNIEXPORT: >> ?SurfaceData_InitOps >> ?mul8table >> ?div8table >> ?doDrawPath >> ?doFillPath >> ?g_CMpDataID >> ?initInverseGrayLut >> ?make_dither_arrays >> ?make_uns_ordered_dither_array >> ?path2DFloatCoordsID >> ?path2DNumTypesID >> ?path2DTypesID >> ?path2DWindingRuleID >> ?sg2dStrokeHintID >> ?std_img_oda_blue >> ?std_img_oda_green >> ?std_img_oda_red >> ?std_odas_computed >> ?sunHints_INTVAL_STROKE_PURE >> >> java.desktop/libawt on solaris: >> A number of "#pragma weak" directives was previously overridden by >> the mapfile. >> Now these directives are respected, so these symbols are now weak >> instead of local: >> ?ByteGrayToIntArgbPreConvert_F >> ?ByteGrayToIntArgbPreScaleConvert_F >> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >> ?IntArgbToIntRgbXorBlit_F >> ?IntBgrToIntBgrAlphaMaskBlit_F >> >> java.desktop/libawt on solaris: These are now also exported due to >> JNIEXPORT in libmlib_image. >> ?j2d_mlib_ImageCreate >> ?j2d_mlib_ImageCreateStruct >> ?j2d_mlib_ImageDelete >> >> java.desktop/libawt on solaris: This is now also exported due to >> JNIEXPORT: >> ?GrPrim_CompGetXorColor >> ?SurfaceData_GetOpsNoSetup >> ?SurfaceData_IntersectBoundsXYWH >> ?SurfaceData_SetOps >> ?Transform_GetInfo >> ?Transform_transform >> >> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >> solaris due to JNIEXPORT. >> libspashscreen also had JNIEXPORT (actually a pure >> _declspec(dllexport)) but no JNICALL, which I added as >> a part of converting to JNIEXPORT. The same goes for libmlib_image . >> >> jdk.sctp/libsctp: handleSocketError is now exported on linux and >> solaris due to JNIEXPORT in libnio. >> >> java.instrument:/libinstrument: Agent_OnUnload is now also exported >> on linux and solaris platforms due to JNIEXPORT. >> JLI_ManifestIterate is now also exported on Windows, due to added >> JNIEXPORT in libjli. >> >> jdk.management/libmanagement_ext: >> Java_com_sun_management_internal_Flag_setDoubleValue is now also >> exported on linux and solaris platforms due to JNIEXPORT. >> >> /Magnus >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Fri Mar 23 16:58:58 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 23 Mar 2018 09:58:58 -0700 Subject: RFR 8178370 : [TEST_BUG] java/security/Signature/SignatureLength.java fails In-Reply-To: References: Message-ID: <8f7f9daa-45fd-b65f-2299-a86a4c40c9a1@oracle.com> Ping. Can I please have a review for this test fix? Thanks in advance! Ivan On 3/6/18 1:01 PM, Ivan Gerasimov wrote: > Hello! > > The regression test SignatureLength.java was seen to fail on some > Solaris systems. > > This is because signature verifier from SunPKCS11-Solaris provider > doesn't always throw SignatureException when the signature is of wrong > length, but can simply return false to indicate it is invalid. > > The test was also modified to try different combinations of providers > used to create key-pair generator, signer and verifier. > > The fixed test passes well on all platforms with JDK 11 and JDK 8u. > > Would you please help review it? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8178370 > WEBREV: http://cr.openjdk.java.net/~igerasim/8178370/00/webrev/ > > Thanks in advance! > -- With kind regards, Ivan Gerasimov From volker.simonis at gmail.com Fri Mar 23 17:24:24 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 23 Mar 2018 18:24:24 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> Message-ID: Hi Magnus, thanks for addressing this long standing issue! I haven't looked at the changes, but just want to share some general and historical notes: - Compiling with "-fvisibility=hidden" which hides all symbols expect the ones explicitly exported with "__attribute__((visibility("default")))" has been requested by SAP back in 2007 even before we had OpenJDK (see "Use -fvisibility=hidden for gcc compiles" https://bugs.openjdk.java.net/browse/JDK-6588413) and finally pushed into the OpenJKD around 2010. - "-fvisibility=hidden" gave us performance improvements of about 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and 0,5% (JVM98) on Linux/PPC64 because the compiler could use faster calls for non exported symbols. This improvement was only very small on x86 tough. - "-fvisibility=hidden"/"__attribute__((visibility("default")))" applies BEFORE using the map files in the linking step (i.e. hidden symbols can't be exported any more even if mentioned in the map file) - because of the performance improvements we got by using "-fvisibility=hidden" it was worth while using it even though we had the mapfiles at the end of the process. Then we had several mail threads (which you probably remember because you were involved :) where we discussed to either remove the map files completely or instead generate them automatically during the build: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12412 http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12628 The main arguments against removing the map files at that time were: 1. the danger to re-export all symbols of statically linked libraries (notably libstdc++ at that time) 2. loosing exports of compiler generated symbols like vtables which are required by the Serviceability Agent Point 1 is not a problem today, because I don't think we do any static linking any more. If we still do it under some circumstances, this problem should be re-evaluated. Point 2 is only relevant for HotSpot. But because of "8034065: GCC 4.3 and later doesn't export vtable symbols any more which seem to be needed by SA" (https://bugs.openjdk.java.net/browse/JDK-8034065), exporting such symbols trough a map files doesn't work any more anyway. So this isn't a problem either. So to cut a long story short - I think the time is ripe to get rid of the map files. Thumbs up from me (meant as moral support, not as a concrete review :) Regards, Volker On Fri, Mar 23, 2018 at 5:05 PM, mandy chung wrote: > This is a very good change and no more mapfile to maintain!! > > Please do file JBS issues for the component teams to clean up their exports. > > Mandy > > > On 3/23/18 7:30 AM, Erik Joelsson wrote: >> >> I have looked at the build changes and they look good. >> >> Will you file followups for each component team to look over their >> exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It >> sure looks like there is some technical debt laying around here. >> >> /Erik >> >> >> On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >>> >>> With modern compilers, we can use compiler directives (such as >>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control >>> symbol visibility, directly in the source code. This has historically not >>> been present on all compilers, so we had to resort to using mapfiles (also >>> known as linker scripts). >>> >>> This is no longer the case. Now all compilers we use support symbol >>> visibility directives, in one form or another. We should start using this. >>> Since this has been the only way to control symbol visibility on Windows, >>> for most of the shared code, we already have proper JNIEXPORT decorations in >>> place. >>> >>> If we fix the remaining platform-specific files to have proper JNIEXPORT >>> tagging, then we can finally get rid of mapfiles. >>> >>> This fix removed mapfiles for all JDK libraries. It does not touch >>> hotspot libraries nor JDK executables; they will have to wait for a future >>> fix -- this was complex enough. This change will not have any impact on >>> macosx, since we do not use mapfiles there, but instead export all symbols. >>> (This is not a good idea, but I'll address that separately.) This change >>> will also have a minimal impact on Windows. The only reason Windows is >>> impacted at all, is that some changes needed by Solaris and Linux were >>> simpler to fix for all platforms. >>> >>> I have strived for this change to have no impact on the actual generated >>> code. Unfortunately, this was not possible to fully achieve. I do not >>> believe that these changes will have any actual impact on the product, >>> though. I will present the differences more in detail further down. Those >>> who are not interested can probably skip that. >>> >>> The patch has passed tier1 testing and is currently running tier2 and >>> tier3. Since the running code is more or less (see caveat below) unmodified, >>> I don't expect any testing issues. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>> >>> Details on changes: >>> Most of the source code changes are (unsurprisingly) in java.base and >>> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>> >>> Source code changes does almost to 100% consists in decorating an >>> exported function with JNIEXPORT. I have also followed the long-standing >>> convention of adding JNICALL. This is a no-op on non-Windows platforms, so >>> for most of the changes this is purely cosmetic (and possibly adding in >>> robustness, should the function ever be used on Windows in the future). I >>> have also followed the stylistic convention of putting "JNIEXPORT >> type> JNICALL" on a separate line. For some functions, however, this might >>> cause a change in calling convention on Windows. Since this can not apply to >>> exported functions on Windows (otherwise they would already have had >>> JNIEXPORT), I do not think this matters anything. >>> >>> A few libraries did not have a mapfile, on Linux and/or Solaris. This >>> actually meant that all symbols were exported. It is highly unclear if this >>> was known and intended by the original make rule writer. I have emulated >>> this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, >>> we can remove this flag and fix proper exported symbols in the future. >>> >>> I have run the complete build using COMPARE_BUILD, and made a thourough >>> analysis of the differences for Linux and Solaris. All native libraries have >>> symbol differences, but most of them are trivial and/or harmless. As a >>> result, most libraries have disasm differences as well, but these too seem >>> trivial and harmless. The differences in symbols that are common to all >>> libraries include: >>> * Internal symbols such as __bss_start, _edata, _end and _fini are now >>> global. (They are imported as such from the compiler libraries/archives, and >>> we have no linker script to override this behavior). >>> * The versioning tag SUNWprivate_1.1 is not included, and thus neither >>> the .gnu.version_d symbol. >>> * There are a few differences in the symbol and/or mangling of some >>> local functions. I'm not sure what's causing this, >>> but it's unlikely to have any effect on the product. >>> >>> Another common source for change in symbols is due to previous platform >>> differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ... >>> }", but do_foo was not in the mapfile, the symbol was exported on Windows >>> but not on Linux and Solaris. (Presumable since it was not needed there, >>> even though it was compiled for those platforms as well.) Now, with the >>> mapfiles gone, do_foo() will be exported on all platforms. And contrary, >>> functions that are compiled on all platforms, and were exported in mapfiles, >>> but now have gotten an JNIEXPORT decoration, will now be visible even on >>> Windows. (This accounts for half of the noticed symbol differences on >>> Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't >>> think the mess in source code were worth the keeping of binary confidence >>> with the old build. >>> >>> A third common source for change in symbols is due to exported functions >>> "leaking" across library borders. For instance, some functions in >>> java.desktop is compiled in both libawt_xawt and libawt_headless, but they >>> were previously only included in the mapfile for one of these libraries. >>> Now, since the visibility is determined by the source code itself, it gets >>> exported in both libraries. A variant of this is when a library depends on >>> another JDK library, and includes the header file from that other library, >>> which in turn declares a function as JNIEXPORT. This will cause the >>> including library to also export the function. This accounts for the other >>> half of the changes on Windows. A typical example of this is that multiple >>> libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I >>> have not listed the libjvm re-exports below.) >>> >>> Note that Java_java_io_FileOutputStream_close0 in >>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported, >>> and can probably be removed. >>> >>> Here is a detailed table showing and accounting for all the remaining >>> differences found on Linux and Solaris: >>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is >>> now also exported on unix platforms due to JNIEXPORT. >>> >>> java.base/jspawnlauncher: On solaris, we also include >>> libjava/childproc.o, which >>> now exports less functions than it used to (it used to export all >>> functions, now it is compiled with visibility=hidden). >>> >>> java.base/java(w).exe: Is now also exporting the following symbols due to >>> added JNIEXPORT in libjli on Windows: >>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>> JLI_AddArgsFromEnvVar >>> JLI_CmdToArgs >>> JLI_GetAppArgIndex >>> JLI_GetStdArgc >>> JLI_GetStdArgs >>> JLI_InitArgProcessing >>> JLI_Launch >>> JLI_List_add >>> JLI_List_new >>> JLI_ManifestIterate >>> JLI_MemAlloc >>> JLI_MemFree >>> JLI_PreprocessArg >>> JLI_ReportErrorMessage >>> JLI_ReportErrorMessageSys >>> JLI_ReportExceptionDescription >>> JLI_ReportMessage >>> JLI_SetTraceLauncher >>> JLI_StringDup >>> >>> java.desktop:/libawt_xawt: The following symbols are now also exported on >>> linux and solaris due to JNIEXPORT: >>> awt_DrawingSurface_FreeDrawingSurfaceInfo >>> awt_DrawingSurface_GetDrawingSurfaceInfo >>> awt_DrawingSurface_Lock >>> awt_DrawingSurface_Unlock >>> awt_GetColor >>> >>> The following symbols are now also exported on linux and solaris due to >>> JNIEXPORT (they were previously >>> exported only in libawt): >>> Java_sun_awt_DebugSettings_setCTracingOn__Z >>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>> Java_sun_awt_X11GraphicsConfig_getNumColors >>> >>> java.desktop:/libawt_headless: The following symbols are now also >>> exported due to JNIEXPORT (they were previously >>> exported only in libawt_xawt and/or libawt): >>> Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>> Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>> Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>> Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>> X11SurfaceData_GetOps >>> >>> java.desktop/libawt: The following symbols are now also exported on >>> Windows, due to added >>> JNIEXPORT: >>> SurfaceData_InitOps >>> mul8table >>> div8table >>> doDrawPath >>> doFillPath >>> g_CMpDataID >>> initInverseGrayLut >>> make_dither_arrays >>> make_uns_ordered_dither_array >>> path2DFloatCoordsID >>> path2DNumTypesID >>> path2DTypesID >>> path2DWindingRuleID >>> sg2dStrokeHintID >>> std_img_oda_blue >>> std_img_oda_green >>> std_img_oda_red >>> std_odas_computed >>> sunHints_INTVAL_STROKE_PURE >>> >>> java.desktop/libawt on solaris: >>> A number of "#pragma weak" directives was previously overridden by the >>> mapfile. >>> Now these directives are respected, so these symbols are now weak instead >>> of local: >>> ByteGrayToIntArgbPreConvert_F >>> ByteGrayToIntArgbPreScaleConvert_F >>> IntArgbBmToFourByteAbgrPreScaleXparOver_F >>> IntArgbToIntRgbXorBlit_F >>> IntBgrToIntBgrAlphaMaskBlit_F >>> >>> java.desktop/libawt on solaris: These are now also exported due to >>> JNIEXPORT in libmlib_image. >>> j2d_mlib_ImageCreate >>> j2d_mlib_ImageCreateStruct >>> j2d_mlib_ImageDelete >>> >>> java.desktop/libawt on solaris: This is now also exported due to >>> JNIEXPORT: >>> GrPrim_CompGetXorColor >>> SurfaceData_GetOpsNoSetup >>> SurfaceData_IntersectBoundsXYWH >>> SurfaceData_SetOps >>> Transform_GetInfo >>> Transform_transform >>> >>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >>> solaris due to JNIEXPORT. >>> libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport)) >>> but no JNICALL, which I added as >>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>> >>> jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris >>> due to JNIEXPORT in libnio. >>> >>> java.instrument:/libinstrument: Agent_OnUnload is now also exported on >>> linux and solaris platforms due to JNIEXPORT. >>> JLI_ManifestIterate is now also exported on Windows, due to added >>> JNIEXPORT in libjli. >>> >>> jdk.management/libmanagement_ext: >>> Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on >>> linux and solaris platforms due to JNIEXPORT. >>> >>> /Magnus >>> >>> >> > From philip.race at oracle.com Fri Mar 23 17:33:55 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Mar 2018 10:33:55 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> There are a lot of changes in the desktop libraries. Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those since only tier3 has any UI tests and it barely uses anything that's touched here. So since testing seems to be wise, then I think you should do a jtreg desktop group run on Linux & Windows. You can probably skip Mac since it is unaffected and I think Linux will cover Solaris here. You should also do some headless testing. It could take some time to review this properly and decide what changes are OK, what changes are something we should clean up later, and what changes are something that ought to be addressed now .. I think I'd be mainly concerned that something fails due to a missing symbol, or that for newly exported symbols if we ended up with duplicate symbols as a result. The results of a test run will add confidence here. BTW I don't think you are right that java.desktop:/libawt_headless: The following symbols are now also exported due to JNIEXPORT (they were previously .. X11SurfaceData_GetOps It looks to me like it was previously exported. -phil. On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: > With modern compilers, we can use compiler directives (such as > _attribute__((visibility("default"))), or __declspec(dllexport)) to > control symbol visibility, directly in the source code. This has > historically not been present on all compilers, so we had to resort to > using mapfiles (also known as linker scripts). > > This is no longer the case. Now all compilers we use support symbol > visibility directives, in one form or another. We should start using > this. Since this has been the only way to control symbol visibility on > Windows, for most of the shared code, we already have proper JNIEXPORT > decorations in place. > > If we fix the remaining platform-specific files to have proper > JNIEXPORT tagging, then we can finally get rid of mapfiles. > > This fix removed mapfiles for all JDK libraries. It does not touch > hotspot libraries nor JDK executables; they will have to wait for a > future fix -- this was complex enough. This change will not have any > impact on macosx, since we do not use mapfiles there, but instead > export all symbols. (This is not a good idea, but I'll address that > separately.) This change will also have a minimal impact on Windows. > The only reason Windows is impacted at all, is that some changes > needed by Solaris and Linux were simpler to fix for all platforms. > > I have strived for this change to have no impact on the actual > generated code. Unfortunately, this was not possible to fully achieve. > I do not believe that these changes will have any actual impact on the > product, though. I will present the differences more in detail further > down. Those who are not interested can probably skip that. > > The patch has passed tier1 testing and is currently running tier2 and > tier3. Since the running code is more or less (see caveat below) > unmodified, I don't expect any testing issues. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 > > Details on changes: > Most of the source code changes are (unsurprisingly) in java.base and > java.desktop. Remaining changes are in jdk.crypto.ucrypto, > jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. > > Source code changes does almost to 100% consists in decorating an > exported function with JNIEXPORT. I have also followed the > long-standing convention of adding JNICALL. This is a no-op on > non-Windows platforms, so for most of the changes this is purely > cosmetic (and possibly adding in robustness, should the function ever > be used on Windows in the future). I have also followed the stylistic > convention of putting "JNIEXPORT JNICALL" on a separate > line. For some functions, however, this might cause a change in > calling convention on Windows. Since this can not apply to exported > functions on Windows (otherwise they would already have had > JNIEXPORT), I do not think this matters anything. > > A few libraries did not have a mapfile, on Linux and/or Solaris. This > actually meant that all symbols were exported. It is highly unclear if > this was known and intended by the original make rule writer. I have > emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these > libraries. Hopefully, we can remove this flag and fix proper exported > symbols in the future. > > I have run the complete build using COMPARE_BUILD, and made a > thourough analysis of the differences for Linux and Solaris. All > native libraries have symbol differences, but most of them are trivial > and/or harmless. As a result, most libraries have disasm differences > as well, but these too seem trivial and harmless. The differences in > symbols that are common to all libraries include: > * Internal symbols such as __bss_start, _edata, _end and _fini are > now global. (They are imported as such from the compiler > libraries/archives, and we have no linker script to override this > behavior). > * The versioning tag SUNWprivate_1.1 is not included, and thus > neither the .gnu.version_d symbol. > * There are a few differences in the symbol and/or mangling of some > local functions. I'm not sure what's causing this, > but it's unlikely to have any effect on the product. > > Another common source for change in symbols is due to previous > platform differences. For instance, if we had "JNIEXPORT int JNICALL > do_foo() { ... }", but do_foo was not in the mapfile, the symbol was > exported on Windows but not on Linux and Solaris. (Presumable since it > was not needed there, even though it was compiled for those platforms > as well.) Now, with the mapfiles gone, do_foo() will be exported on > all platforms. And contrary, functions that are compiled on all > platforms, and were exported in mapfiles, but now have gotten an > JNIEXPORT decoration, will now be visible even on Windows. (This > accounts for half of the noticed symbol differences on Windows.) I > could have made the JNIEXPORT conditional on OS, but I didn't think > the mess in source code were worth the keeping of binary confidence > with the old build. > > A third common source for change in symbols is due to exported > functions "leaking" across library borders. For instance, some > functions in java.desktop is compiled in both libawt_xawt and > libawt_headless, but they were previously only included in the mapfile > for one of these libraries. Now, since the visibility is determined by > the source code itself, it gets exported in both libraries. A variant > of this is when a library depends on another JDK library, and includes > the header file from that other library, which in turn declares a > function as JNIEXPORT. This will cause the including library to also > export the function. This accounts for the other half of the changes > on Windows. A typical example of this is that multiple libraries now > re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have > not listed the libjvm re-exports below.) > > Note that Java_java_io_FileOutputStream_close0 in > java.base/unix/native/libjava/FileOutputStream_md.c is no longer > exported, > and can probably be removed. > > Here is a detailed table showing and accounting for all the remaining > differences found on Linux and Solaris: > java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is > now also exported on unix platforms due to JNIEXPORT. > > java.base/jspawnlauncher: On solaris, we also include > libjava/childproc.o, which > now exports less functions than it used to (it used to export all > functions, now it is compiled with visibility=hidden). > > java.base/java(w).exe: Is now also exporting the following symbols due > to added JNIEXPORT in libjli on Windows: > (Yes, executables can export symbols on Windows. Confusing, I know.) > JLI_AddArgsFromEnvVar > JLI_CmdToArgs > JLI_GetAppArgIndex > JLI_GetStdArgc > JLI_GetStdArgs > JLI_InitArgProcessing > JLI_Launch > JLI_List_add > JLI_List_new > JLI_ManifestIterate > JLI_MemAlloc > JLI_MemFree > JLI_PreprocessArg > JLI_ReportErrorMessage > JLI_ReportErrorMessageSys > JLI_ReportExceptionDescription > JLI_ReportMessage > JLI_SetTraceLauncher > JLI_StringDup > > java.desktop:/libawt_xawt: The following symbols are now also exported > on linux and solaris due to JNIEXPORT: > awt_DrawingSurface_FreeDrawingSurfaceInfo > awt_DrawingSurface_GetDrawingSurfaceInfo > awt_DrawingSurface_Lock > awt_DrawingSurface_Unlock > awt_GetColor > > The following symbols are now also exported on linux and solaris due > to JNIEXPORT (they were previously > exported only in libawt): > Java_sun_awt_DebugSettings_setCTracingOn__Z > Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 > Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I > Java_sun_awt_X11GraphicsConfig_getNumColors > > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > exported only in libawt_xawt and/or libawt): > Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo > Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities > Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask > Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable > X11SurfaceData_GetOps > > java.desktop/libawt: The following symbols are now also exported on > Windows, due to added > JNIEXPORT: > SurfaceData_InitOps > mul8table > div8table > doDrawPath > doFillPath > g_CMpDataID > initInverseGrayLut > make_dither_arrays > make_uns_ordered_dither_array > path2DFloatCoordsID > path2DNumTypesID > path2DTypesID > path2DWindingRuleID > sg2dStrokeHintID > std_img_oda_blue > std_img_oda_green > std_img_oda_red > std_odas_computed > sunHints_INTVAL_STROKE_PURE > > java.desktop/libawt on solaris: > A number of "#pragma weak" directives was previously overridden by the > mapfile. > Now these directives are respected, so these symbols are now weak > instead of local: > ByteGrayToIntArgbPreConvert_F > ByteGrayToIntArgbPreScaleConvert_F > IntArgbBmToFourByteAbgrPreScaleXparOver_F > IntArgbToIntRgbXorBlit_F > IntBgrToIntBgrAlphaMaskBlit_F > > java.desktop/libawt on solaris: These are now also exported due to > JNIEXPORT in libmlib_image. > j2d_mlib_ImageCreate > j2d_mlib_ImageCreateStruct > j2d_mlib_ImageDelete > > java.desktop/libawt on solaris: This is now also exported due to > JNIEXPORT: > GrPrim_CompGetXorColor > SurfaceData_GetOpsNoSetup > SurfaceData_IntersectBoundsXYWH > SurfaceData_SetOps > Transform_GetInfo > Transform_transform > > java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and > solaris due to JNIEXPORT. > libspashscreen also had JNIEXPORT (actually a pure > _declspec(dllexport)) but no JNICALL, which I added as > a part of converting to JNIEXPORT. The same goes for libmlib_image . > > jdk.sctp/libsctp: handleSocketError is now exported on linux and > solaris due to JNIEXPORT in libnio. > > java.instrument:/libinstrument: Agent_OnUnload is now also exported on > linux and solaris platforms due to JNIEXPORT. > JLI_ManifestIterate is now also exported on Windows, due to added > JNIEXPORT in libjli. > > jdk.management/libmanagement_ext: > Java_com_sun_management_internal_Flag_setDoubleValue is now also > exported on linux and solaris platforms due to JNIEXPORT. > > /Magnus > > From philip.race at oracle.com Fri Mar 23 18:01:34 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Mar 2018 11:01:34 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> Message-ID: <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html The variable definitions here are now misaligned. ..and added 2d-dev since many of these native changes are in 2d. -phil. On 03/23/2018 10:33 AM, Phil Race wrote: > There are a lot of changes in the desktop libraries. > Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those > since > only tier3 has any UI tests and it barely uses anything that's touched > here. > So since testing seems to be wise, then I think you should do a > jtreg desktop group run on Linux & Windows. > You can probably skip Mac since it is unaffected and I think Linux > will cover Solaris here. > You should also do some headless testing. > > It could take some time to review this properly and decide what > changes are OK, > what changes are something we should clean up later, and what changes > are something > that ought to be addressed now .. > > I think I'd be mainly concerned that something fails due to a missing > symbol, or > that for newly exported symbols if we ended up with duplicate symbols > as a result. > > The results of a test run will add confidence here. > > BTW I don't think you are right that > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > .. > X11SurfaceData_GetOps > > It looks to me like it was previously exported. > > > -phil. > > > > On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as >> _attribute__((visibility("default"))), or __declspec(dllexport)) to >> control symbol visibility, directly in the source code. This has >> historically not been present on all compilers, so we had to resort >> to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol >> visibility directives, in one form or another. We should start using >> this. Since this has been the only way to control symbol visibility >> on Windows, for most of the shared code, we already have proper >> JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper >> JNIEXPORT tagging, then we can finally get rid of mapfiles. >> >> This fix removed mapfiles for all JDK libraries. It does not touch >> hotspot libraries nor JDK executables; they will have to wait for a >> future fix -- this was complex enough. This change will not have any >> impact on macosx, since we do not use mapfiles there, but instead >> export all symbols. (This is not a good idea, but I'll address that >> separately.) This change will also have a minimal impact on Windows. >> The only reason Windows is impacted at all, is that some changes >> needed by Solaris and Linux were simpler to fix for all platforms. >> >> I have strived for this change to have no impact on the actual >> generated code. Unfortunately, this was not possible to fully >> achieve. I do not believe that these changes will have any actual >> impact on the product, though. I will present the differences more in >> detail further down. Those who are not interested can probably skip >> that. >> >> The patch has passed tier1 testing and is currently running tier2 and >> tier3. Since the running code is more or less (see caveat below) >> unmodified, I don't expect any testing issues. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >> >> Details on changes: >> Most of the source code changes are (unsurprisingly) in java.base and >> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >> >> Source code changes does almost to 100% consists in decorating an >> exported function with JNIEXPORT. I have also followed the >> long-standing convention of adding JNICALL. This is a no-op on >> non-Windows platforms, so for most of the changes this is purely >> cosmetic (and possibly adding in robustness, should the function ever >> be used on Windows in the future). I have also followed the stylistic >> convention of putting "JNIEXPORT JNICALL" on a separate >> line. For some functions, however, this might cause a change in >> calling convention on Windows. Since this can not apply to exported >> functions on Windows (otherwise they would already have had >> JNIEXPORT), I do not think this matters anything. >> >> A few libraries did not have a mapfile, on Linux and/or Solaris. This >> actually meant that all symbols were exported. It is highly unclear >> if this was known and intended by the original make rule writer. I >> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these >> libraries. Hopefully, we can remove this flag and fix proper exported >> symbols in the future. >> >> I have run the complete build using COMPARE_BUILD, and made a >> thourough analysis of the differences for Linux and Solaris. All >> native libraries have symbol differences, but most of them are >> trivial and/or harmless. As a result, most libraries have disasm >> differences as well, but these too seem trivial and harmless. The >> differences in symbols that are common to all libraries include: >> * Internal symbols such as __bss_start, _edata, _end and _fini are >> now global. (They are imported as such from the compiler >> libraries/archives, and we have no linker script to override this >> behavior). >> * The versioning tag SUNWprivate_1.1 is not included, and thus >> neither the .gnu.version_d symbol. >> * There are a few differences in the symbol and/or mangling of some >> local functions. I'm not sure what's causing this, >> but it's unlikely to have any effect on the product. >> >> Another common source for change in symbols is due to previous >> platform differences. For instance, if we had "JNIEXPORT int JNICALL >> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >> exported on Windows but not on Linux and Solaris. (Presumable since >> it was not needed there, even though it was compiled for those >> platforms as well.) Now, with the mapfiles gone, do_foo() will be >> exported on all platforms. And contrary, functions that are compiled >> on all platforms, and were exported in mapfiles, but now have gotten >> an JNIEXPORT decoration, will now be visible even on Windows. (This >> accounts for half of the noticed symbol differences on Windows.) I >> could have made the JNIEXPORT conditional on OS, but I didn't think >> the mess in source code were worth the keeping of binary confidence >> with the old build. >> >> A third common source for change in symbols is due to exported >> functions "leaking" across library borders. For instance, some >> functions in java.desktop is compiled in both libawt_xawt and >> libawt_headless, but they were previously only included in the >> mapfile for one of these libraries. Now, since the visibility is >> determined by the source code itself, it gets exported in both >> libraries. A variant of this is when a library depends on another JDK >> library, and includes the header file from that other library, which >> in turn declares a function as JNIEXPORT. This will cause the >> including library to also export the function. This accounts for the >> other half of the changes on Windows. A typical example of this is >> that multiple libraries now re-export hotspot symbols from libjvm.so, >> like jio_fprintf. (I have not listed the libjvm re-exports below.) >> >> Note that Java_java_io_FileOutputStream_close0 in >> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >> exported, >> and can probably be removed. >> >> Here is a detailed table showing and accounting for all the remaining >> differences found on Linux and Solaris: >> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >> is now also exported on unix platforms due to JNIEXPORT. >> >> java.base/jspawnlauncher: On solaris, we also include >> libjava/childproc.o, which >> now exports less functions than it used to (it used to export all >> functions, now it is compiled with visibility=hidden). >> >> java.base/java(w).exe: Is now also exporting the following symbols >> due to added JNIEXPORT in libjli on Windows: >> (Yes, executables can export symbols on Windows. Confusing, I know.) >> JLI_AddArgsFromEnvVar >> JLI_CmdToArgs >> JLI_GetAppArgIndex >> JLI_GetStdArgc >> JLI_GetStdArgs >> JLI_InitArgProcessing >> JLI_Launch >> JLI_List_add >> JLI_List_new >> JLI_ManifestIterate >> JLI_MemAlloc >> JLI_MemFree >> JLI_PreprocessArg >> JLI_ReportErrorMessage >> JLI_ReportErrorMessageSys >> JLI_ReportExceptionDescription >> JLI_ReportMessage >> JLI_SetTraceLauncher >> JLI_StringDup >> >> java.desktop:/libawt_xawt: The following symbols are now also >> exported on linux and solaris due to JNIEXPORT: >> awt_DrawingSurface_FreeDrawingSurfaceInfo >> awt_DrawingSurface_GetDrawingSurfaceInfo >> awt_DrawingSurface_Lock >> awt_DrawingSurface_Unlock >> awt_GetColor >> >> The following symbols are now also exported on linux and solaris due >> to JNIEXPORT (they were previously >> exported only in libawt): >> Java_sun_awt_DebugSettings_setCTracingOn__Z >> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >> Java_sun_awt_X11GraphicsConfig_getNumColors >> >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> exported only in libawt_xawt and/or libawt): >> Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >> Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >> Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >> Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >> X11SurfaceData_GetOps >> >> java.desktop/libawt: The following symbols are now also exported on >> Windows, due to added >> JNIEXPORT: >> SurfaceData_InitOps >> mul8table >> div8table >> doDrawPath >> doFillPath >> g_CMpDataID >> initInverseGrayLut >> make_dither_arrays >> make_uns_ordered_dither_array >> path2DFloatCoordsID >> path2DNumTypesID >> path2DTypesID >> path2DWindingRuleID >> sg2dStrokeHintID >> std_img_oda_blue >> std_img_oda_green >> std_img_oda_red >> std_odas_computed >> sunHints_INTVAL_STROKE_PURE >> >> java.desktop/libawt on solaris: >> A number of "#pragma weak" directives was previously overridden by >> the mapfile. >> Now these directives are respected, so these symbols are now weak >> instead of local: >> ByteGrayToIntArgbPreConvert_F >> ByteGrayToIntArgbPreScaleConvert_F >> IntArgbBmToFourByteAbgrPreScaleXparOver_F >> IntArgbToIntRgbXorBlit_F >> IntBgrToIntBgrAlphaMaskBlit_F >> >> java.desktop/libawt on solaris: These are now also exported due to >> JNIEXPORT in libmlib_image. >> j2d_mlib_ImageCreate >> j2d_mlib_ImageCreateStruct >> j2d_mlib_ImageDelete >> >> java.desktop/libawt on solaris: This is now also exported due to >> JNIEXPORT: >> GrPrim_CompGetXorColor >> SurfaceData_GetOpsNoSetup >> SurfaceData_IntersectBoundsXYWH >> SurfaceData_SetOps >> Transform_GetInfo >> Transform_transform >> >> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >> solaris due to JNIEXPORT. >> libspashscreen also had JNIEXPORT (actually a pure >> _declspec(dllexport)) but no JNICALL, which I added as >> a part of converting to JNIEXPORT. The same goes for libmlib_image . >> >> jdk.sctp/libsctp: handleSocketError is now exported on linux and >> solaris due to JNIEXPORT in libnio. >> >> java.instrument:/libinstrument: Agent_OnUnload is now also exported >> on linux and solaris platforms due to JNIEXPORT. >> JLI_ManifestIterate is now also exported on Windows, due to added >> JNIEXPORT in libjli. >> >> jdk.management/libmanagement_ext: >> Java_com_sun_management_internal_Flag_setDoubleValue is now also >> exported on linux and solaris platforms due to JNIEXPORT. >> >> /Magnus >> >> > From adam.petcher at oracle.com Fri Mar 23 19:35:54 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 23 Mar 2018 15:35:54 -0400 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: <602b4435-88c5-30c6-d1ab-de057a5b7fca@oracle.com> Note: I am not a Reviewer. This is not a Review. I took a look at some of the files that I was working in during my extension development. I just have a few minor comments: TransportContext.java, line 428: It's not clear why the outbound direction is closed here. Consider adding more comments to describe what is going on. SessionId.java, lines 54: need to clone()? SessionId.java, lines 81-87: you could do Arrays.hashCode(sessionId) SSLExtension.java, line 441: The word "trad" is used here and in other places in the file. Should this be "trade"? KeyShareExtension.java, lines 264-265: I think you can remove the comment, and the code is fine as it is. The problem of large ClientHello messages should be addressed when we add support for HelloRetryRequest. On 2/22/2018 3:29 PM, Xuelei Fan wrote: > Updated to use package private HKDF implementation. > > webrev (based on JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 > > webrev (including JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > Thanks, > Xuelei > > On 2/20/2018 11:57 AM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 full handshake >> implementation.? I appreciate it if I could have feedback before >> March 9, 2018. >> >> In the "JDK-8185576: New handshake implementation" [1] code review >> around, I was trying to re-org the TLS handshaking implementation in the >> SunJSSE provider.? If you had reviewed that part, you can start from >> the following webrev that based on the update of JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >> >> If you would like start from earlier, here is the webrev that >> contains the handshaking implementation re-org in JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> >> This changeset only implements the full handshake of TLS 1.3, rather >> then a fully implementation of the latest TLS 1.3 draft [2]. >> >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite.? I may >> not add them back if no objections. >> >> 2. OCSP stapling. >> This feature will be added back later. >> >> Resumption and key update, and more features may be added later. >> >> Thanks & Regards, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >> >> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From magnus.ihse.bursie at oracle.com Fri Mar 23 20:36:29 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 21:36:29 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com> Message-ID: <2db2ec37-b561-3f93-623b-14ddbc615381@oracle.com> On 2018-03-23 19:01, Phil Race wrote: > > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html > > > The variable definitions here are now misaligned. No, they are not. That's just an artifact of webrev, which filters out whitespace changes in the diff view. :-( To see the proper changes, including whitespace, you need to download the patch file. I've gone to great pains to mimick the existing style in the source codes I've made changes to. /Magnus > > ..and added 2d-dev since many of these native changes are in 2d. > > -phil. > > On 03/23/2018 10:33 AM, Phil Race wrote: >> There are a lot of changes in the desktop libraries. >> Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those >> since >> only tier3 has any UI tests and it barely uses anything that's >> touched here. >> So since testing seems to be wise, then I think you should do a >> jtreg desktop group run on Linux & Windows. >> You can probably skip Mac since it is unaffected and I think Linux >> will cover Solaris here. >> You should also do some headless testing. >> >> It could take some time to review this properly and decide what >> changes are OK, >> what changes are something we should clean up later, and what changes >> are something >> that ought to be addressed now .. >> >> I think I'd be mainly concerned that something fails due to a missing >> symbol, or >> that for newly exported symbols if we ended up with duplicate symbols >> as a result. >> >> The results of a test run will add confidence here. >> >> BTW I don't think you are right that >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> .. >> ?X11SurfaceData_GetOps >> >> It looks to me like it was previously exported. >> >> >> -phil. >> >> >> >> On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: >>> With modern compilers, we can use compiler directives (such as >>> _attribute__((visibility("default"))), or __declspec(dllexport)) to >>> control symbol visibility, directly in the source code. This has >>> historically not been present on all compilers, so we had to resort >>> to using mapfiles (also known as linker scripts). >>> >>> This is no longer the case. Now all compilers we use support symbol >>> visibility directives, in one form or another. We should start using >>> this. Since this has been the only way to control symbol visibility >>> on Windows, for most of the shared code, we already have proper >>> JNIEXPORT decorations in place. >>> >>> If we fix the remaining platform-specific files to have proper >>> JNIEXPORT tagging, then we can finally get rid of mapfiles. >>> >>> This fix removed mapfiles for all JDK libraries. It does not touch >>> hotspot libraries nor JDK executables; they will have to wait for a >>> future fix -- this was complex enough. This change will not have any >>> impact on macosx, since we do not use mapfiles there, but instead >>> export all symbols. (This is not a good idea, but I'll address that >>> separately.) This change will also have a minimal impact on Windows. >>> The only reason Windows is impacted at all, is that some changes >>> needed by Solaris and Linux were simpler to fix for all platforms. >>> >>> I have strived for this change to have no impact on the actual >>> generated code. Unfortunately, this was not possible to fully >>> achieve. I do not believe that these changes will have any actual >>> impact on the product, though. I will present the differences more >>> in detail further down. Those who are not interested can probably >>> skip that. >>> >>> The patch has passed tier1 testing and is currently running tier2 >>> and tier3. Since the running code is more or less (see caveat below) >>> unmodified, I don't expect any testing issues. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>> >>> Details on changes: >>> Most of the source code changes are (unsurprisingly) in java.base >>> and java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>> >>> Source code changes does almost to 100% consists in decorating an >>> exported function with JNIEXPORT. I have also followed the >>> long-standing convention of adding JNICALL. This is a no-op on >>> non-Windows platforms, so for most of the changes this is purely >>> cosmetic (and possibly adding in robustness, should the function >>> ever be used on Windows in the future). I have also followed the >>> stylistic convention of putting "JNIEXPORT JNICALL" on >>> a separate line. For some functions, however, this might cause a >>> change in calling convention on Windows. Since this can not apply to >>> exported functions on Windows (otherwise they would already have had >>> JNIEXPORT), I do not think this matters anything. >>> >>> A few libraries did not have a mapfile, on Linux and/or Solaris. >>> This actually meant that all symbols were exported. It is highly >>> unclear if this was known and intended by the original make rule >>> writer. I have emulated this by adding the flag >>> $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove >>> this flag and fix proper exported symbols in the future. >>> >>> I have run the complete build using COMPARE_BUILD, and made a >>> thourough analysis of the differences for Linux and Solaris. All >>> native libraries have symbol differences, but most of them are >>> trivial and/or harmless. As a result, most libraries have disasm >>> differences as well, but these too seem trivial and harmless. The >>> differences in symbols that are common to all libraries include: >>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >>> now global. (They are imported as such from the compiler >>> libraries/archives, and we have no linker script to override this >>> behavior). >>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >>> neither the .gnu.version_d symbol. >>> ?* There are a few differences in the symbol and/or mangling of some >>> local functions. I'm not sure what's causing this, >>> but it's unlikely to have any effect on the product. >>> >>> Another common source for change in symbols is due to previous >>> platform differences. For instance, if we had "JNIEXPORT int JNICALL >>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >>> exported on Windows but not on Linux and Solaris. (Presumable since >>> it was not needed there, even though it was compiled for those >>> platforms as well.) Now, with the mapfiles gone, do_foo() will be >>> exported on all platforms. And contrary, functions that are compiled >>> on all platforms, and were exported in mapfiles, but now have gotten >>> an JNIEXPORT decoration, will now be visible even on Windows. (This >>> accounts for half of the noticed symbol differences on Windows.) I >>> could have made the JNIEXPORT conditional on OS, but I didn't think >>> the mess in source code were worth the keeping of binary confidence >>> with the old build. >>> >>> A third common source for change in symbols is due to exported >>> functions "leaking" across library borders. For instance, some >>> functions in java.desktop is compiled in both libawt_xawt and >>> libawt_headless, but they were previously only included in the >>> mapfile for one of these libraries. Now, since the visibility is >>> determined by the source code itself, it gets exported in both >>> libraries. A variant of this is when a library depends on another >>> JDK library, and includes the header file from that other library, >>> which in turn declares a function as JNIEXPORT. This will cause the >>> including library to also export the function. This accounts for the >>> other half of the changes on Windows. A typical example of this is >>> that multiple libraries now re-export hotspot symbols from >>> libjvm.so, like jio_fprintf. (I have not listed the libjvm >>> re-exports below.) >>> >>> Note that? Java_java_io_FileOutputStream_close0 in >>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >>> exported, >>> and can probably be removed. >>> >>> Here is a detailed table showing and accounting for all the >>> remaining differences found on Linux and Solaris: >>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >>> is now also exported on unix platforms due to JNIEXPORT. >>> >>> java.base/jspawnlauncher: On solaris, we also include >>> libjava/childproc.o, which >>> now exports less functions than it used to (it used to export all >>> functions, now it is compiled with visibility=hidden). >>> >>> java.base/java(w).exe: Is now also exporting the following symbols >>> due to added JNIEXPORT in libjli on Windows: >>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>> ?JLI_AddArgsFromEnvVar >>> ?JLI_CmdToArgs >>> ?JLI_GetAppArgIndex >>> ?JLI_GetStdArgc >>> ?JLI_GetStdArgs >>> ?JLI_InitArgProcessing >>> ?JLI_Launch >>> ?JLI_List_add >>> ?JLI_List_new >>> ?JLI_ManifestIterate >>> ?JLI_MemAlloc >>> ?JLI_MemFree >>> ?JLI_PreprocessArg >>> ?JLI_ReportErrorMessage >>> ?JLI_ReportErrorMessageSys >>> ?JLI_ReportExceptionDescription >>> ?JLI_ReportMessage >>> ?JLI_SetTraceLauncher >>> ?JLI_StringDup >>> >>> java.desktop:/libawt_xawt: The following symbols are now also >>> exported on linux and solaris due to JNIEXPORT: >>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >>> ?awt_DrawingSurface_GetDrawingSurfaceInfo >>> ?awt_DrawingSurface_Lock >>> ?awt_DrawingSurface_Unlock >>> ?awt_GetColor >>> >>> The following symbols are now also exported on linux and solaris due >>> to JNIEXPORT (they were previously >>> ?exported only in libawt): >>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>> ?Java_sun_awt_X11GraphicsConfig_getNumColors >>> >>> java.desktop:/libawt_headless: The following symbols are now also >>> exported due to JNIEXPORT (they were previously >>> ?exported only in libawt_xawt and/or libawt): >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>> ?X11SurfaceData_GetOps >>> >>> java.desktop/libawt: The following symbols are now also exported on >>> Windows, due to added >>> JNIEXPORT: >>> ?SurfaceData_InitOps >>> ?mul8table >>> ?div8table >>> ?doDrawPath >>> ?doFillPath >>> ?g_CMpDataID >>> ?initInverseGrayLut >>> ?make_dither_arrays >>> ?make_uns_ordered_dither_array >>> ?path2DFloatCoordsID >>> ?path2DNumTypesID >>> ?path2DTypesID >>> ?path2DWindingRuleID >>> ?sg2dStrokeHintID >>> ?std_img_oda_blue >>> ?std_img_oda_green >>> ?std_img_oda_red >>> ?std_odas_computed >>> ?sunHints_INTVAL_STROKE_PURE >>> >>> java.desktop/libawt on solaris: >>> A number of "#pragma weak" directives was previously overridden by >>> the mapfile. >>> Now these directives are respected, so these symbols are now weak >>> instead of local: >>> ?ByteGrayToIntArgbPreConvert_F >>> ?ByteGrayToIntArgbPreScaleConvert_F >>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >>> ?IntArgbToIntRgbXorBlit_F >>> ?IntBgrToIntBgrAlphaMaskBlit_F >>> >>> java.desktop/libawt on solaris: These are now also exported due to >>> JNIEXPORT in libmlib_image. >>> ?j2d_mlib_ImageCreate >>> ?j2d_mlib_ImageCreateStruct >>> ?j2d_mlib_ImageDelete >>> >>> java.desktop/libawt on solaris: This is now also exported due to >>> JNIEXPORT: >>> ?GrPrim_CompGetXorColor >>> ?SurfaceData_GetOpsNoSetup >>> ?SurfaceData_IntersectBoundsXYWH >>> ?SurfaceData_SetOps >>> ?Transform_GetInfo >>> ?Transform_transform >>> >>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux >>> and solaris due to JNIEXPORT. >>> libspashscreen also had JNIEXPORT (actually a pure >>> _declspec(dllexport)) but no JNICALL, which I added as >>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>> >>> jdk.sctp/libsctp: handleSocketError is now exported on linux and >>> solaris due to JNIEXPORT in libnio. >>> >>> java.instrument:/libinstrument: Agent_OnUnload is now also exported >>> on linux and solaris platforms due to JNIEXPORT. >>> JLI_ManifestIterate is now also exported on Windows, due to added >>> JNIEXPORT in libjli. >>> >>> jdk.management/libmanagement_ext: >>> Java_com_sun_management_internal_Flag_setDoubleValue is now also >>> exported on linux and solaris platforms due to JNIEXPORT. >>> >>> /Magnus >>> >>> >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 21:08:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 22:08:35 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> Message-ID: On 2018-03-23 18:33, Phil Race wrote: > There are a lot of changes in the desktop libraries. Well, yes and no. While there are multiple touched files, the resulting native shared libraries that are built have very minimal changes in them. (That's the view point from the build guy, you know :)) > Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those > since > only tier3 has any UI tests and it barely uses anything that's touched > here. > So since testing seems to be wise, then I think you should do a > jtreg desktop group run on Linux & Windows. There is next to *no* difference for java.desktop on Windows. The only, very subtle, difference, is that awt.dll now exports 18 more functions (totalling 800, instead of 782). I can't even begin to imagine how anything could fail due to this additional exporting. Not even the disassembly of the machine code of awt.dll is different from before, not a single byte. So I don't buy it that I need to do extensive client testing on Windows. > You can probably skip Mac since it is unaffected and I think Linux > will cover Solaris here. > You should also do some headless testing. I agree that it seems prudent to do some Linux/Solaris testing, since changes there are more wide spread. Could you please point me to some guidance on how to run these tests? (You can do it off list) > It could take some time to review this properly and decide what > changes are OK, > what changes are something we should clean up later, and what changes > are something > that ought to be addressed now .. As I said, I am going to file follow-up bugs for suspicious handling of exported symbols. These follow-up bugs will be separated per component team, unlike this fix, which by necessity addresses all JDK libraries at once. So you will get plenty of time to consider ways of cleaning up any exports handling that you do not like. It would be a pity if this entire checkin was delayed since the client team could not accept the changes needed in client libraries. :-( And frankly, I believe the java.desktop libs needs some serious refactoring to get to grip with the exported symbols situation. The major cause of problems is, I believe, rooted in a non-optimal split of functionality between libawt, libawt_xawt and libawt_headless. This is not likely something that can be addressed in this change. > I think I'd be mainly concerned that something fails due to a missing > symbol, or > that for newly exported symbols if we ended up with duplicate symbols > as a result. Once again, I've run the COMPARE_BUILD script on this patch. Let me explain a bit more in detail what it does, since that might be known only to us in the build team. This script analyses the build result, the jmods, the lib*.so files, etc. The basic idea here is that a change in the build system, which does not produce a change in the build result, is "transparent" to the product. There is e.g. no reason to run any further testing, since we're in effect testing the same bits. For many changes in the build system, we hold this as the gold standard. For this particular change, to achieve this kind of fidelity would have come with a too high price in code complexity, so I have allowed certain small deviations. These are really minimal, and should in most cases be undetectable by the product. The changes in Linux and Solaris that have occured, is those that I listed in my review mail. Basically, for some libraries, additional symbols are exported. I could fix this, but only at the expense of more complex code. While it's a good thing to minimize the functions exported, a handful extra symbols is not a disaster. (We have more important issues to address in our native libraries.) For the AWT libraries, most of the duplicates are coming from the source code that are shared between libraries, in java.desktop/share/native/common. This means that the same function is compiled into -- and now also exported from -- multiple libraries. This is not a big deal. Even if we were to link with two libraries defining the same symbol, the dynamic linker will arbitrarily chose one of them, but since they are identical, it does not matter. (It's another thing if they implement different functions, as you noted yourself in the bugs about linking with awt_xawt vs doing a runtime linking to awt_headless). Also, I guarantee you that in no way are there missing symbols in the refactored build. I've checked, double-checked and triple-checked that. > The results of a test run will add confidence here. > > BTW I don't think you are right that > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > .. > ?X11SurfaceData_GetOps > > It looks to me like it was previously exported. You are correct, it was previously exported in libawt_headless. I meant that it is now also exported for libawt_xawt due to the JNIEXPORT. Sorry for mixing this up. /Magnus > > > -phil. > > > > On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as >> _attribute__((visibility("default"))), or __declspec(dllexport)) to >> control symbol visibility, directly in the source code. This has >> historically not been present on all compilers, so we had to resort >> to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol >> visibility directives, in one form or another. We should start using >> this. Since this has been the only way to control symbol visibility >> on Windows, for most of the shared code, we already have proper >> JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper >> JNIEXPORT tagging, then we can finally get rid of mapfiles. >> >> This fix removed mapfiles for all JDK libraries. It does not touch >> hotspot libraries nor JDK executables; they will have to wait for a >> future fix -- this was complex enough. This change will not have any >> impact on macosx, since we do not use mapfiles there, but instead >> export all symbols. (This is not a good idea, but I'll address that >> separately.) This change will also have a minimal impact on Windows. >> The only reason Windows is impacted at all, is that some changes >> needed by Solaris and Linux were simpler to fix for all platforms. >> >> I have strived for this change to have no impact on the actual >> generated code. Unfortunately, this was not possible to fully >> achieve. I do not believe that these changes will have any actual >> impact on the product, though. I will present the differences more in >> detail further down. Those who are not interested can probably skip >> that. >> >> The patch has passed tier1 testing and is currently running tier2 and >> tier3. Since the running code is more or less (see caveat below) >> unmodified, I don't expect any testing issues. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >> >> Details on changes: >> Most of the source code changes are (unsurprisingly) in java.base and >> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >> >> Source code changes does almost to 100% consists in decorating an >> exported function with JNIEXPORT. I have also followed the >> long-standing convention of adding JNICALL. This is a no-op on >> non-Windows platforms, so for most of the changes this is purely >> cosmetic (and possibly adding in robustness, should the function ever >> be used on Windows in the future). I have also followed the stylistic >> convention of putting "JNIEXPORT JNICALL" on a separate >> line. For some functions, however, this might cause a change in >> calling convention on Windows. Since this can not apply to exported >> functions on Windows (otherwise they would already have had >> JNIEXPORT), I do not think this matters anything. >> >> A few libraries did not have a mapfile, on Linux and/or Solaris. This >> actually meant that all symbols were exported. It is highly unclear >> if this was known and intended by the original make rule writer. I >> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these >> libraries. Hopefully, we can remove this flag and fix proper exported >> symbols in the future. >> >> I have run the complete build using COMPARE_BUILD, and made a >> thourough analysis of the differences for Linux and Solaris. All >> native libraries have symbol differences, but most of them are >> trivial and/or harmless. As a result, most libraries have disasm >> differences as well, but these too seem trivial and harmless. The >> differences in symbols that are common to all libraries include: >> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >> now global. (They are imported as such from the compiler >> libraries/archives, and we have no linker script to override this >> behavior). >> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >> neither the .gnu.version_d symbol. >> ?* There are a few differences in the symbol and/or mangling of some >> local functions. I'm not sure what's causing this, >> but it's unlikely to have any effect on the product. >> >> Another common source for change in symbols is due to previous >> platform differences. For instance, if we had "JNIEXPORT int JNICALL >> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >> exported on Windows but not on Linux and Solaris. (Presumable since >> it was not needed there, even though it was compiled for those >> platforms as well.) Now, with the mapfiles gone, do_foo() will be >> exported on all platforms. And contrary, functions that are compiled >> on all platforms, and were exported in mapfiles, but now have gotten >> an JNIEXPORT decoration, will now be visible even on Windows. (This >> accounts for half of the noticed symbol differences on Windows.) I >> could have made the JNIEXPORT conditional on OS, but I didn't think >> the mess in source code were worth the keeping of binary confidence >> with the old build. >> >> A third common source for change in symbols is due to exported >> functions "leaking" across library borders. For instance, some >> functions in java.desktop is compiled in both libawt_xawt and >> libawt_headless, but they were previously only included in the >> mapfile for one of these libraries. Now, since the visibility is >> determined by the source code itself, it gets exported in both >> libraries. A variant of this is when a library depends on another JDK >> library, and includes the header file from that other library, which >> in turn declares a function as JNIEXPORT. This will cause the >> including library to also export the function. This accounts for the >> other half of the changes on Windows. A typical example of this is >> that multiple libraries now re-export hotspot symbols from libjvm.so, >> like jio_fprintf. (I have not listed the libjvm re-exports below.) >> >> Note that? Java_java_io_FileOutputStream_close0 in >> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >> exported, >> and can probably be removed. >> >> Here is a detailed table showing and accounting for all the remaining >> differences found on Linux and Solaris: >> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >> is now also exported on unix platforms due to JNIEXPORT. >> >> java.base/jspawnlauncher: On solaris, we also include >> libjava/childproc.o, which >> now exports less functions than it used to (it used to export all >> functions, now it is compiled with visibility=hidden). >> >> java.base/java(w).exe: Is now also exporting the following symbols >> due to added JNIEXPORT in libjli on Windows: >> (Yes, executables can export symbols on Windows. Confusing, I know.) >> ?JLI_AddArgsFromEnvVar >> ?JLI_CmdToArgs >> ?JLI_GetAppArgIndex >> ?JLI_GetStdArgc >> ?JLI_GetStdArgs >> ?JLI_InitArgProcessing >> ?JLI_Launch >> ?JLI_List_add >> ?JLI_List_new >> ?JLI_ManifestIterate >> ?JLI_MemAlloc >> ?JLI_MemFree >> ?JLI_PreprocessArg >> ?JLI_ReportErrorMessage >> ?JLI_ReportErrorMessageSys >> ?JLI_ReportExceptionDescription >> ?JLI_ReportMessage >> ?JLI_SetTraceLauncher >> ?JLI_StringDup >> >> java.desktop:/libawt_xawt: The following symbols are now also >> exported on linux and solaris due to JNIEXPORT: >> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >> ?awt_DrawingSurface_GetDrawingSurfaceInfo >> ?awt_DrawingSurface_Lock >> ?awt_DrawingSurface_Unlock >> ?awt_GetColor >> >> The following symbols are now also exported on linux and solaris due >> to JNIEXPORT (they were previously >> ?exported only in libawt): >> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >> ?Java_sun_awt_X11GraphicsConfig_getNumColors >> >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> ?exported only in libawt_xawt and/or libawt): >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >> ?X11SurfaceData_GetOps >> >> java.desktop/libawt: The following symbols are now also exported on >> Windows, due to added >> JNIEXPORT: >> ?SurfaceData_InitOps >> ?mul8table >> ?div8table >> ?doDrawPath >> ?doFillPath >> ?g_CMpDataID >> ?initInverseGrayLut >> ?make_dither_arrays >> ?make_uns_ordered_dither_array >> ?path2DFloatCoordsID >> ?path2DNumTypesID >> ?path2DTypesID >> ?path2DWindingRuleID >> ?sg2dStrokeHintID >> ?std_img_oda_blue >> ?std_img_oda_green >> ?std_img_oda_red >> ?std_odas_computed >> ?sunHints_INTVAL_STROKE_PURE >> >> java.desktop/libawt on solaris: >> A number of "#pragma weak" directives was previously overridden by >> the mapfile. >> Now these directives are respected, so these symbols are now weak >> instead of local: >> ?ByteGrayToIntArgbPreConvert_F >> ?ByteGrayToIntArgbPreScaleConvert_F >> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >> ?IntArgbToIntRgbXorBlit_F >> ?IntBgrToIntBgrAlphaMaskBlit_F >> >> java.desktop/libawt on solaris: These are now also exported due to >> JNIEXPORT in libmlib_image. >> ?j2d_mlib_ImageCreate >> ?j2d_mlib_ImageCreateStruct >> ?j2d_mlib_ImageDelete >> >> java.desktop/libawt on solaris: This is now also exported due to >> JNIEXPORT: >> ?GrPrim_CompGetXorColor >> ?SurfaceData_GetOpsNoSetup >> ?SurfaceData_IntersectBoundsXYWH >> ?SurfaceData_SetOps >> ?Transform_GetInfo >> ?Transform_transform >> >> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >> solaris due to JNIEXPORT. >> libspashscreen also had JNIEXPORT (actually a pure >> _declspec(dllexport)) but no JNICALL, which I added as >> a part of converting to JNIEXPORT. The same goes for libmlib_image . >> >> jdk.sctp/libsctp: handleSocketError is now exported on linux and >> solaris due to JNIEXPORT in libnio. >> >> java.instrument:/libinstrument: Agent_OnUnload is now also exported >> on linux and solaris platforms due to JNIEXPORT. >> JLI_ManifestIterate is now also exported on Windows, due to added >> JNIEXPORT in libjli. >> >> jdk.management/libmanagement_ext: >> Java_com_sun_management_internal_Flag_setDoubleValue is now also >> exported on linux and solaris platforms due to JNIEXPORT. >> >> /Magnus >> >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 21:31:36 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 22:31:36 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> Message-ID: <278836b5-b49b-2409-f1b5-e05fdc0d2b30@oracle.com> On 2018-03-23 18:24, Volker Simonis wrote: > Hi Magnus, > > thanks for addressing this long standing issue! I haven't looked at > the changes, but just want to share some general and historical notes: > > - Compiling with "-fvisibility=hidden" which hides all symbols expect > the ones explicitly exported with > "__attribute__((visibility("default")))" has been requested by SAP > back in 2007 even before we had OpenJDK (see "Use -fvisibility=hidden > for gcc compiles" https://bugs.openjdk.java.net/browse/JDK-6588413) > and finally pushed into the OpenJKD around 2010. > - "-fvisibility=hidden" gave us performance improvements of about 5% > (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and 0,5% > (JVM98) on Linux/PPC64 because the compiler could use faster calls for > non exported symbols. This improvement was only very small on x86 > tough. That's a nice side effect! Although my main purpose here is maintainability, gaining performance is nothing I say no to. :) > - "-fvisibility=hidden"/"__attribute__((visibility("default")))" > applies BEFORE using the map files in the linking step (i.e. hidden > symbols can't be exported any more even if mentioned in the map file) > - because of the performance improvements we got by using > "-fvisibility=hidden" it was worth while using it even though we had > the mapfiles at the end of the process. > > Then we had several mail threads (which you probably remember because > you were involved :) where we discussed to either remove the map files > completely or instead generate them automatically during the build: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12412 > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12628 > > The main arguments against removing the map files at that time were: > > 1. the danger to re-export all symbols of statically linked libraries > (notably libstdc++ at that time) > 2. loosing exports of compiler generated symbols like vtables which > are required by the Serviceability Agent > > Point 1 is not a problem today, because I don't think we do any static > linking any more. If we still do it under some circumstances, this > problem should be re-evaluated. Well, we do static linking with libstdc++ on linux, in certain circumstances. See "--with-stdc++lib=,,". Fortunately, this is not a problem. The linker can be told not to include symbols from statically linked libraries, which is exactly what I do with LDFLAGS_JDKLIB += -Wl,--exclude-libs,ALL. The corresponding feature does not exist for the solstudio linker, but fortunately we do not use statically linked libraries there. > Point 2 is only relevant for HotSpot. But because of "8034065: GCC 4.3 > and later doesn't export vtable symbols any more which seem to be > needed by SA" (https://bugs.openjdk.java.net/browse/JDK-8034065), > exporting such symbols trough a map files doesn't work any more > anyway. So this isn't a problem either. In any case, that's a question for another day. :) There were reasons I left Hotspot out of this fix, and the question about the SA agent is one of them. :) As you say, I think they do not apply anymore, but I'll return to consider Hotspot later on. > So to cut a long story short - I think the time is ripe to get rid of > the map files. Thumbs up from me (meant as moral support, not as a > concrete review :) Thanks for the kind words! /Magnus > > Regards, > Volker > > On Fri, Mar 23, 2018 at 5:05 PM, mandy chung wrote: >> This is a very good change and no more mapfile to maintain!! >> >> Please do file JBS issues for the component teams to clean up their exports. >> >> Mandy >> >> >> On 3/23/18 7:30 AM, Erik Joelsson wrote: >>> I have looked at the build changes and they look good. >>> >>> Will you file followups for each component team to look over their >>> exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It >>> sure looks like there is some technical debt laying around here. >>> >>> /Erik >>> >>> >>> On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >>>> With modern compilers, we can use compiler directives (such as >>>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control >>>> symbol visibility, directly in the source code. This has historically not >>>> been present on all compilers, so we had to resort to using mapfiles (also >>>> known as linker scripts). >>>> >>>> This is no longer the case. Now all compilers we use support symbol >>>> visibility directives, in one form or another. We should start using this. >>>> Since this has been the only way to control symbol visibility on Windows, >>>> for most of the shared code, we already have proper JNIEXPORT decorations in >>>> place. >>>> >>>> If we fix the remaining platform-specific files to have proper JNIEXPORT >>>> tagging, then we can finally get rid of mapfiles. >>>> >>>> This fix removed mapfiles for all JDK libraries. It does not touch >>>> hotspot libraries nor JDK executables; they will have to wait for a future >>>> fix -- this was complex enough. This change will not have any impact on >>>> macosx, since we do not use mapfiles there, but instead export all symbols. >>>> (This is not a good idea, but I'll address that separately.) This change >>>> will also have a minimal impact on Windows. The only reason Windows is >>>> impacted at all, is that some changes needed by Solaris and Linux were >>>> simpler to fix for all platforms. >>>> >>>> I have strived for this change to have no impact on the actual generated >>>> code. Unfortunately, this was not possible to fully achieve. I do not >>>> believe that these changes will have any actual impact on the product, >>>> though. I will present the differences more in detail further down. Those >>>> who are not interested can probably skip that. >>>> >>>> The patch has passed tier1 testing and is currently running tier2 and >>>> tier3. Since the running code is more or less (see caveat below) unmodified, >>>> I don't expect any testing issues. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>>> >>>> Details on changes: >>>> Most of the source code changes are (unsurprisingly) in java.base and >>>> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>>> >>>> Source code changes does almost to 100% consists in decorating an >>>> exported function with JNIEXPORT. I have also followed the long-standing >>>> convention of adding JNICALL. This is a no-op on non-Windows platforms, so >>>> for most of the changes this is purely cosmetic (and possibly adding in >>>> robustness, should the function ever be used on Windows in the future). I >>>> have also followed the stylistic convention of putting "JNIEXPORT >>> type> JNICALL" on a separate line. For some functions, however, this might >>>> cause a change in calling convention on Windows. Since this can not apply to >>>> exported functions on Windows (otherwise they would already have had >>>> JNIEXPORT), I do not think this matters anything. >>>> >>>> A few libraries did not have a mapfile, on Linux and/or Solaris. This >>>> actually meant that all symbols were exported. It is highly unclear if this >>>> was known and intended by the original make rule writer. I have emulated >>>> this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, >>>> we can remove this flag and fix proper exported symbols in the future. >>>> >>>> I have run the complete build using COMPARE_BUILD, and made a thourough >>>> analysis of the differences for Linux and Solaris. All native libraries have >>>> symbol differences, but most of them are trivial and/or harmless. As a >>>> result, most libraries have disasm differences as well, but these too seem >>>> trivial and harmless. The differences in symbols that are common to all >>>> libraries include: >>>> * Internal symbols such as __bss_start, _edata, _end and _fini are now >>>> global. (They are imported as such from the compiler libraries/archives, and >>>> we have no linker script to override this behavior). >>>> * The versioning tag SUNWprivate_1.1 is not included, and thus neither >>>> the .gnu.version_d symbol. >>>> * There are a few differences in the symbol and/or mangling of some >>>> local functions. I'm not sure what's causing this, >>>> but it's unlikely to have any effect on the product. >>>> >>>> Another common source for change in symbols is due to previous platform >>>> differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ... >>>> }", but do_foo was not in the mapfile, the symbol was exported on Windows >>>> but not on Linux and Solaris. (Presumable since it was not needed there, >>>> even though it was compiled for those platforms as well.) Now, with the >>>> mapfiles gone, do_foo() will be exported on all platforms. And contrary, >>>> functions that are compiled on all platforms, and were exported in mapfiles, >>>> but now have gotten an JNIEXPORT decoration, will now be visible even on >>>> Windows. (This accounts for half of the noticed symbol differences on >>>> Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't >>>> think the mess in source code were worth the keeping of binary confidence >>>> with the old build. >>>> >>>> A third common source for change in symbols is due to exported functions >>>> "leaking" across library borders. For instance, some functions in >>>> java.desktop is compiled in both libawt_xawt and libawt_headless, but they >>>> were previously only included in the mapfile for one of these libraries. >>>> Now, since the visibility is determined by the source code itself, it gets >>>> exported in both libraries. A variant of this is when a library depends on >>>> another JDK library, and includes the header file from that other library, >>>> which in turn declares a function as JNIEXPORT. This will cause the >>>> including library to also export the function. This accounts for the other >>>> half of the changes on Windows. A typical example of this is that multiple >>>> libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I >>>> have not listed the libjvm re-exports below.) >>>> >>>> Note that Java_java_io_FileOutputStream_close0 in >>>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported, >>>> and can probably be removed. >>>> >>>> Here is a detailed table showing and accounting for all the remaining >>>> differences found on Linux and Solaris: >>>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is >>>> now also exported on unix platforms due to JNIEXPORT. >>>> >>>> java.base/jspawnlauncher: On solaris, we also include >>>> libjava/childproc.o, which >>>> now exports less functions than it used to (it used to export all >>>> functions, now it is compiled with visibility=hidden). >>>> >>>> java.base/java(w).exe: Is now also exporting the following symbols due to >>>> added JNIEXPORT in libjli on Windows: >>>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>>> JLI_AddArgsFromEnvVar >>>> JLI_CmdToArgs >>>> JLI_GetAppArgIndex >>>> JLI_GetStdArgc >>>> JLI_GetStdArgs >>>> JLI_InitArgProcessing >>>> JLI_Launch >>>> JLI_List_add >>>> JLI_List_new >>>> JLI_ManifestIterate >>>> JLI_MemAlloc >>>> JLI_MemFree >>>> JLI_PreprocessArg >>>> JLI_ReportErrorMessage >>>> JLI_ReportErrorMessageSys >>>> JLI_ReportExceptionDescription >>>> JLI_ReportMessage >>>> JLI_SetTraceLauncher >>>> JLI_StringDup >>>> >>>> java.desktop:/libawt_xawt: The following symbols are now also exported on >>>> linux and solaris due to JNIEXPORT: >>>> awt_DrawingSurface_FreeDrawingSurfaceInfo >>>> awt_DrawingSurface_GetDrawingSurfaceInfo >>>> awt_DrawingSurface_Lock >>>> awt_DrawingSurface_Unlock >>>> awt_GetColor >>>> >>>> The following symbols are now also exported on linux and solaris due to >>>> JNIEXPORT (they were previously >>>> exported only in libawt): >>>> Java_sun_awt_DebugSettings_setCTracingOn__Z >>>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>>> Java_sun_awt_X11GraphicsConfig_getNumColors >>>> >>>> java.desktop:/libawt_headless: The following symbols are now also >>>> exported due to JNIEXPORT (they were previously >>>> exported only in libawt_xawt and/or libawt): >>>> Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>>> Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>>> Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>>> Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>>> X11SurfaceData_GetOps >>>> >>>> java.desktop/libawt: The following symbols are now also exported on >>>> Windows, due to added >>>> JNIEXPORT: >>>> SurfaceData_InitOps >>>> mul8table >>>> div8table >>>> doDrawPath >>>> doFillPath >>>> g_CMpDataID >>>> initInverseGrayLut >>>> make_dither_arrays >>>> make_uns_ordered_dither_array >>>> path2DFloatCoordsID >>>> path2DNumTypesID >>>> path2DTypesID >>>> path2DWindingRuleID >>>> sg2dStrokeHintID >>>> std_img_oda_blue >>>> std_img_oda_green >>>> std_img_oda_red >>>> std_odas_computed >>>> sunHints_INTVAL_STROKE_PURE >>>> >>>> java.desktop/libawt on solaris: >>>> A number of "#pragma weak" directives was previously overridden by the >>>> mapfile. >>>> Now these directives are respected, so these symbols are now weak instead >>>> of local: >>>> ByteGrayToIntArgbPreConvert_F >>>> ByteGrayToIntArgbPreScaleConvert_F >>>> IntArgbBmToFourByteAbgrPreScaleXparOver_F >>>> IntArgbToIntRgbXorBlit_F >>>> IntBgrToIntBgrAlphaMaskBlit_F >>>> >>>> java.desktop/libawt on solaris: These are now also exported due to >>>> JNIEXPORT in libmlib_image. >>>> j2d_mlib_ImageCreate >>>> j2d_mlib_ImageCreateStruct >>>> j2d_mlib_ImageDelete >>>> >>>> java.desktop/libawt on solaris: This is now also exported due to >>>> JNIEXPORT: >>>> GrPrim_CompGetXorColor >>>> SurfaceData_GetOpsNoSetup >>>> SurfaceData_IntersectBoundsXYWH >>>> SurfaceData_SetOps >>>> Transform_GetInfo >>>> Transform_transform >>>> >>>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >>>> solaris due to JNIEXPORT. >>>> libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport)) >>>> but no JNICALL, which I added as >>>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>>> >>>> jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris >>>> due to JNIEXPORT in libnio. >>>> >>>> java.instrument:/libinstrument: Agent_OnUnload is now also exported on >>>> linux and solaris platforms due to JNIEXPORT. >>>> JLI_ManifestIterate is now also exported on Windows, due to added >>>> JNIEXPORT in libjli. >>>> >>>> jdk.management/libmanagement_ext: >>>> Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on >>>> linux and solaris platforms due to JNIEXPORT. >>>> >>>> /Magnus >>>> >>>> From magnus.ihse.bursie at oracle.com Fri Mar 23 22:03:59 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 23:03:59 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> Message-ID: <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> On 2018-03-23 17:05, mandy chung wrote: > This is a very good change and no more mapfile to maintain!! Thank you! > > Please do file JBS issues for the component teams to clean up their > exports. I have now filed: https://bugs.openjdk.java.net/browse/JDK-8200191 -- for java.base https://bugs.openjdk.java.net/browse/JDK-8200192 -- for java.desktop https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth /Magnus > > Mandy > > On 3/23/18 7:30 AM, Erik Joelsson wrote: >> I have looked at the build changes and they look good. >> >> Will you file followups for each component team to look over their >> exported symbols, at least for the libraries with >> $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical >> debt laying around here. >> >> /Erik >> >> >> On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >>> With modern compilers, we can use compiler directives (such as >>> _attribute__((visibility("default"))), or __declspec(dllexport)) to >>> control symbol visibility, directly in the source code. This has >>> historically not been present on all compilers, so we had to resort >>> to using mapfiles (also known as linker scripts). >>> >>> This is no longer the case. Now all compilers we use support symbol >>> visibility directives, in one form or another. We should start using >>> this. Since this has been the only way to control symbol visibility >>> on Windows, for most of the shared code, we already have proper >>> JNIEXPORT decorations in place. >>> >>> If we fix the remaining platform-specific files to have proper >>> JNIEXPORT tagging, then we can finally get rid of mapfiles. >>> >>> This fix removed mapfiles for all JDK libraries. It does not touch >>> hotspot libraries nor JDK executables; they will have to wait for a >>> future fix -- this was complex enough. This change will not have any >>> impact on macosx, since we do not use mapfiles there, but instead >>> export all symbols. (This is not a good idea, but I'll address that >>> separately.) This change will also have a minimal impact on Windows. >>> The only reason Windows is impacted at all, is that some changes >>> needed by Solaris and Linux were simpler to fix for all platforms. >>> >>> I have strived for this change to have no impact on the actual >>> generated code. Unfortunately, this was not possible to fully >>> achieve. I do not believe that these changes will have any actual >>> impact on the product, though. I will present the differences more >>> in detail further down. Those who are not interested can probably >>> skip that. >>> >>> The patch has passed tier1 testing and is currently running tier2 >>> and tier3. Since the running code is more or less (see caveat below) >>> unmodified, I don't expect any testing issues. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>> >>> Details on changes: >>> Most of the source code changes are (unsurprisingly) in java.base >>> and java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>> >>> Source code changes does almost to 100% consists in decorating an >>> exported function with JNIEXPORT. I have also followed the >>> long-standing convention of adding JNICALL. This is a no-op on >>> non-Windows platforms, so for most of the changes this is purely >>> cosmetic (and possibly adding in robustness, should the function >>> ever be used on Windows in the future). I have also followed the >>> stylistic convention of putting "JNIEXPORT JNICALL" on >>> a separate line. For some functions, however, this might cause a >>> change in calling convention on Windows. Since this can not apply to >>> exported functions on Windows (otherwise they would already have had >>> JNIEXPORT), I do not think this matters anything. >>> >>> A few libraries did not have a mapfile, on Linux and/or Solaris. >>> This actually meant that all symbols were exported. It is highly >>> unclear if this was known and intended by the original make rule >>> writer. I have emulated this by adding the flag >>> $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove >>> this flag and fix proper exported symbols in the future. >>> >>> I have run the complete build using COMPARE_BUILD, and made a >>> thourough analysis of the differences for Linux and Solaris. All >>> native libraries have symbol differences, but most of them are >>> trivial and/or harmless. As a result, most libraries have disasm >>> differences as well, but these too seem trivial and harmless. The >>> differences in symbols that are common to all libraries include: >>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >>> now global. (They are imported as such from the compiler >>> libraries/archives, and we have no linker script to override this >>> behavior). >>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >>> neither the .gnu.version_d symbol. >>> ?* There are a few differences in the symbol and/or mangling of some >>> local functions. I'm not sure what's causing this, >>> but it's unlikely to have any effect on the product. >>> >>> Another common source for change in symbols is due to previous >>> platform differences. For instance, if we had "JNIEXPORT int JNICALL >>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >>> exported on Windows but not on Linux and Solaris. (Presumable since >>> it was not needed there, even though it was compiled for those >>> platforms as well.) Now, with the mapfiles gone, do_foo() will be >>> exported on all platforms. And contrary, functions that are compiled >>> on all platforms, and were exported in mapfiles, but now have gotten >>> an JNIEXPORT decoration, will now be visible even on Windows. (This >>> accounts for half of the noticed symbol differences on Windows.) I >>> could have made the JNIEXPORT conditional on OS, but I didn't think >>> the mess in source code were worth the keeping of binary confidence >>> with the old build. >>> >>> A third common source for change in symbols is due to exported >>> functions "leaking" across library borders. For instance, some >>> functions in java.desktop is compiled in both libawt_xawt and >>> libawt_headless, but they were previously only included in the >>> mapfile for one of these libraries. Now, since the visibility is >>> determined by the source code itself, it gets exported in both >>> libraries. A variant of this is when a library depends on another >>> JDK library, and includes the header file from that other library, >>> which in turn declares a function as JNIEXPORT. This will cause the >>> including library to also export the function. This accounts for the >>> other half of the changes on Windows. A typical example of this is >>> that multiple libraries now re-export hotspot symbols from >>> libjvm.so, like jio_fprintf. (I have not listed the libjvm >>> re-exports below.) >>> >>> Note that? Java_java_io_FileOutputStream_close0 in >>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >>> exported, >>> and can probably be removed. >>> >>> Here is a detailed table showing and accounting for all the >>> remaining differences found on Linux and Solaris: >>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >>> is now also exported on unix platforms due to JNIEXPORT. >>> >>> java.base/jspawnlauncher: On solaris, we also include >>> libjava/childproc.o, which >>> now exports less functions than it used to (it used to export all >>> functions, now it is compiled with visibility=hidden). >>> >>> java.base/java(w).exe: Is now also exporting the following symbols >>> due to added JNIEXPORT in libjli on Windows: >>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>> ?JLI_AddArgsFromEnvVar >>> ?JLI_CmdToArgs >>> ?JLI_GetAppArgIndex >>> ?JLI_GetStdArgc >>> ?JLI_GetStdArgs >>> ?JLI_InitArgProcessing >>> ?JLI_Launch >>> ?JLI_List_add >>> ?JLI_List_new >>> ?JLI_ManifestIterate >>> ?JLI_MemAlloc >>> ?JLI_MemFree >>> ?JLI_PreprocessArg >>> ?JLI_ReportErrorMessage >>> ?JLI_ReportErrorMessageSys >>> ?JLI_ReportExceptionDescription >>> ?JLI_ReportMessage >>> ?JLI_SetTraceLauncher >>> ?JLI_StringDup >>> >>> java.desktop:/libawt_xawt: The following symbols are now also >>> exported on linux and solaris due to JNIEXPORT: >>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >>> ?awt_DrawingSurface_GetDrawingSurfaceInfo >>> ?awt_DrawingSurface_Lock >>> ?awt_DrawingSurface_Unlock >>> ?awt_GetColor >>> >>> The following symbols are now also exported on linux and solaris due >>> to JNIEXPORT (they were previously >>> ?exported only in libawt): >>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>> ?Java_sun_awt_X11GraphicsConfig_getNumColors >>> >>> java.desktop:/libawt_headless: The following symbols are now also >>> exported due to JNIEXPORT (they were previously >>> ?exported only in libawt_xawt and/or libawt): >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>> ?X11SurfaceData_GetOps >>> >>> java.desktop/libawt: The following symbols are now also exported on >>> Windows, due to added >>> JNIEXPORT: >>> ?SurfaceData_InitOps >>> ?mul8table >>> ?div8table >>> ?doDrawPath >>> ?doFillPath >>> ?g_CMpDataID >>> ?initInverseGrayLut >>> ?make_dither_arrays >>> ?make_uns_ordered_dither_array >>> ?path2DFloatCoordsID >>> ?path2DNumTypesID >>> ?path2DTypesID >>> ?path2DWindingRuleID >>> ?sg2dStrokeHintID >>> ?std_img_oda_blue >>> ?std_img_oda_green >>> ?std_img_oda_red >>> ?std_odas_computed >>> ?sunHints_INTVAL_STROKE_PURE >>> >>> java.desktop/libawt on solaris: >>> A number of "#pragma weak" directives was previously overridden by >>> the mapfile. >>> Now these directives are respected, so these symbols are now weak >>> instead of local: >>> ?ByteGrayToIntArgbPreConvert_F >>> ?ByteGrayToIntArgbPreScaleConvert_F >>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >>> ?IntArgbToIntRgbXorBlit_F >>> ?IntBgrToIntBgrAlphaMaskBlit_F >>> >>> java.desktop/libawt on solaris: These are now also exported due to >>> JNIEXPORT in libmlib_image. >>> ?j2d_mlib_ImageCreate >>> ?j2d_mlib_ImageCreateStruct >>> ?j2d_mlib_ImageDelete >>> >>> java.desktop/libawt on solaris: This is now also exported due to >>> JNIEXPORT: >>> ?GrPrim_CompGetXorColor >>> ?SurfaceData_GetOpsNoSetup >>> ?SurfaceData_IntersectBoundsXYWH >>> ?SurfaceData_SetOps >>> ?Transform_GetInfo >>> ?Transform_transform >>> >>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux >>> and solaris due to JNIEXPORT. >>> libspashscreen also had JNIEXPORT (actually a pure >>> _declspec(dllexport)) but no JNICALL, which I added as >>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>> >>> jdk.sctp/libsctp: handleSocketError is now exported on linux and >>> solaris due to JNIEXPORT in libnio. >>> >>> java.instrument:/libinstrument: Agent_OnUnload is now also exported >>> on linux and solaris platforms due to JNIEXPORT. >>> JLI_ManifestIterate is now also exported on Windows, due to added >>> JNIEXPORT in libjli. >>> >>> jdk.management/libmanagement_ext: >>> Java_com_sun_management_internal_Flag_setDoubleValue is now also >>> exported on linux and solaris platforms due to JNIEXPORT. >>> >>> /Magnus >>> >>> >> > From jamil.j.nimeh at oracle.com Fri Mar 23 22:32:00 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 23 Mar 2018 15:32:00 -0700 Subject: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms In-Reply-To: References: <20180322211921.266111955BA@eggemoggin.niobe.net> Message-ID: Hi Thomas, The TLS cipher suites have been decoupled from the ChaCha20/Poly1305 JEP because of the changes in the new handshake design [1] for our JSSE provider.? From a programmatic/schedule perspective, it made more sense to get the algorithms in ahead of the TLS cipher suites and then add the cipher suites once the handshaking code is a bit farther along in its implementation. With respect to a pluggable interface for TLS cipher suites and hello extensions, this is an area we have done some investigation on in the past, but haven't seriously pursued it due to other features taking a higher priority in each release.? It is certainly a topic that we can discuss on the alias in terms of how one would go about doing it. It appears that you've signed an OCA (Oracle Contributor Agreement) but I would probably start with discussions on designing APIs for plugging in extensions and/or cipher suites before we start looking at code.? Your thoughts on the design for these features would be welcome. [1] http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01/ --Jamil On 3/22/2018 3:26 PM, Thomas Lu?nig wrote: > Hi, > > is there any reason that the cipher and and the tls inclusion is split > into two separate jep? > And the second question is why is there no way for user to add new > cipher suites that can > be used in the tls protocol? Since i extend jdk8 with chacha for tls i > know that it would be > no big issue to add an API that allow to add new CipherSuites this > would be an great improvement > if the TLS-Protocol and the CIPHER-Implementation is more loose coupled. > Also an plugin system for TLS-Hello Extensions would be great. > > Gru? Thomas > > On 3/22/2018 10:19 PM, mark.reinhold at oracle.com wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/329 >> >> - Mark From sibabrata.sahoo at oracle.com Mon Mar 26 16:38:35 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 26 Mar 2018 09:38:35 -0700 (PDT) Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 Message-ID: Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8184359 Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.00/ All the Test files uses KeyAgreement, KeyPairGenerator, Several KeySpecs from SunJCE library to Test DiffieHellman, ECDH and XDH with curve25519 and curve448 algorithms. Each Test files try to address several cases and the purpose of each has been commented in their own files. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Mar 26 19:08:26 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 26 Mar 2018 12:08:26 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations Message-ID: Hello all, This is a request for review for the ChaCha20 and ChaCha20-Poly1305 cipher implementations. Links to the webrev and the JEP which outlines the characteristics and behavior of the ciphers are listed below. http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ http://openjdk.java.net/jeps/329 Thanks, --Jamil From jamil.j.nimeh at oracle.com Mon Mar 26 20:49:38 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 26 Mar 2018 13:49:38 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <708677fc-9cdd-a145-6794-283cab51c84e@suche.org> References: <708677fc-9cdd-a145-6794-283cab51c84e@suche.org> Message-ID: Hi Thomas, thanks for the feedback 1. Were there guidelines?? Not really, though I looked at other parameter definitions in com.sun.crypto.provider and tried to follow along the same lines that they do.? One thing that should be changed is the LINE_SEP assignment shouldn't be an explicit getProperty call.? I noticed most are doing System.lineSeparator() so I'll change my implementation to match that.? None of these params appear to stringify as json, so I'll probably keep things consistent with the other parameter output. 2. You make a fair point with respect to a null SecureRandom.? I can make that spec change. 3. Let me think on this one - I shied away from ChaCha20ParameterSpec for AEAD mode only because you have this nonce field that is set but gets ignored.? But making ChaCha20ParameterSpec an IvParameterSpec potentially runs into the same issue were it used for a ChaCha20-Poly1305 cipher.? If I had to choose between the two I think I'd go with allowing ChaCha20ParameterSpec to be used with CC20-P1305 rather than making it a subclass of IvParameterSpec.? Doing the former helps from a type safety perspective that you couldn't use a ChaCha20ParameterSpec with other Ciphers that require an IvParameterSpec.? I know I had some discussions early on in the design where we talked about this, I need to refresh my memory as to why we didn't allow it. --Jamil On 3/26/2018 12:45 PM, Thomas Lu?nig wrote: > > Hi Jamil, > > 1) where there any guidelines about how the engineToString should be > formatted ? > I ask because i wondering why we need two new lines with access to the > System property. > If it is represented as single line json no need to line break would > be needed. > > Gru? Thomas > > > /** * Creates a formatted string describing the parameters. * * > @return a string representation of the ChaCha20 parameters. */ > @Override protected String engineToString() { String LINE_SEP = > System.getProperty("line.separator"); HexDumpEncoder encoder = new > HexDumpEncoder(); StringBuilder sb = new StringBuilder(LINE_SEP + > "nonce:" + LINE_SEP + "[" + encoder.encodeBuffer(nonce) + "]"); return > sb.toString(); } > 2) I do not think it is an good idea to say no secureRandom=null will cause IV to be null. > I see here the risk of weak implementations. I would suggest to throw an Exception to > enforce secure usages. If someone really want an insecure IV he can provide am SecureRandom > implementation retuning 0 only or an matching IV. > > ?* @param random a {@code SecureRandom} implementation. If {@code null} > * is used for the random object, then a nonce consisting of all > * zero bytes will be used. Otherwise a random nonce will be > * used. > > 3) If ChaCha20ParameterSpec would extends IvParameterSpec if would be valid for booth modes in engineInit. > Even if the counter is not needed. > As an alternative i would allow ChaCha20ParameterSpec also for AEAD mode. > > Grup Thomas > On 3/26/2018 9:08 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >> cipher implementations.? Links to the webrev and the JEP which >> outlines the characteristics and behavior of the ciphers are listed >> below. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >> http://openjdk.java.net/jeps/329 >> >> Thanks, >> --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Mar 26 22:23:07 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 26 Mar 2018 15:23:07 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: References: <708677fc-9cdd-a145-6794-283cab51c84e@suche.org> Message-ID: <227a01af-7a56-0354-41ad-08cdb9c8cbd2@oracle.com> Another thought on #2: Another way we could go with this is to create a new SecureRandom() or use JceSecurity.RANDOM when the random parameter is null. That would make init(op, key, random) and init(op, key) behave the same when random is null. You would always get a random nonce in these two forms. I may go that direction since there's an established behavior for when no SecureRandom is provided through Cipher.init(int, Key). --Jamil On 03/26/2018 01:49 PM, Jamil Nimeh wrote: > Hi Thomas, thanks for the feedback > > 1. Were there guidelines? Not really, though I looked at other > parameter definitions in com.sun.crypto.provider and tried to > follow along the same lines that they do. One thing that should > be changed is the LINE_SEP assignment shouldn't be an explicit > getProperty call. I noticed most are doing System.lineSeparator() > so I'll change my implementation to match that. None of these > params appear to stringify as json, so I'll probably keep things > consistent with the other parameter output. > 2. You make a fair point with respect to a null SecureRandom. I can > make that spec change. > 3. Let me think on this one - I shied away from ChaCha20ParameterSpec > for AEAD mode only because you have this nonce field that is set > but gets ignored. But making ChaCha20ParameterSpec an > IvParameterSpec potentially runs into the same issue were it used > for a ChaCha20-Poly1305 cipher. If I had to choose between the two > I think I'd go with allowing ChaCha20ParameterSpec to be used with > CC20-P1305 rather than making it a subclass of IvParameterSpec. > Doing the former helps from a type safety perspective that you > couldn't use a ChaCha20ParameterSpec with other Ciphers that > require an IvParameterSpec. I know I had some discussions early > on in the design where we talked about this, I need to refresh my > memory as to why we didn't allow it. > > --Jamil > > > On 3/26/2018 12:45 PM, Thomas Lu?nig wrote: >> >> Hi Jamil, >> >> 1) where there any guidelines about how the engineToString should be >> formatted ? >> I ask because i wondering why we need two new lines with access to >> the System property. >> If it is represented as single line json no need to line break would >> be needed. >> >> Gru? Thomas >> >> >> /** * Creates a formatted string describing the parameters. * * >> @return a string representation of the ChaCha20 parameters. */ >> @Override protected String engineToString() { String LINE_SEP = >> System.getProperty("line.separator"); HexDumpEncoder encoder = new >> HexDumpEncoder(); StringBuilder sb = new StringBuilder(LINE_SEP + >> "nonce:" + LINE_SEP + "[" + encoder.encodeBuffer(nonce) + "]"); >> return sb.toString(); } >> 2) I do not think it is an good idea to say no secureRandom=null will cause IV to be null. >> I see here the risk of weak implementations. I would suggest to throw an Exception to >> enforce secure usages. If someone really want an insecure IV he can provide am SecureRandom >> implementation retuning 0 only or an matching IV. >> >> * @param random a {@code SecureRandom} implementation. If {@code null} >> * is used for the random object, then a nonce consisting of all >> * zero bytes will be used. Otherwise a random nonce will be >> * used. >> >> 3) If ChaCha20ParameterSpec would extends IvParameterSpec if would be valid for booth modes in engineInit. >> Even if the counter is not needed. >> As an alternative i would allow ChaCha20ParameterSpec also for AEAD mode. >> >> Grup Thomas >> On 3/26/2018 9:08 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >>> cipher implementations. Links to the webrev and the JEP which >>> outlines the characteristics and behavior of the ciphers are listed >>> below. >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >>> http://openjdk.java.net/jeps/329 >>> >>> Thanks, >>> --Jamil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lussnig at suche.org Mon Mar 26 19:45:05 2018 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 26 Mar 2018 21:45:05 +0200 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: References: Message-ID: <708677fc-9cdd-a145-6794-283cab51c84e@suche.org> Hi Jamil, 1) where there any guidelines about how the engineToString should be formatted ? I ask because i wondering why we need two new lines with access to the System property. If it is represented as single line json no need to line break would be needed. Gru? Thomas /** * Creates a formatted string describing the parameters. * * @return a string representation of the ChaCha20 parameters. */ @Override protected String engineToString() { String LINE_SEP = System.getProperty("line.separator"); HexDumpEncoder encoder = new HexDumpEncoder(); StringBuilder sb = new StringBuilder(LINE_SEP + "nonce:" + LINE_SEP + "[" + encoder.encodeBuffer(nonce) + "]"); return sb.toString(); } 2) I do not think it is an good idea to say no secureRandom=null will cause IV to be null. I see here the risk of weak implementations. I would suggest to throw an Exception to enforce secure usages. If someone really want an insecure IV he can provide am SecureRandom implementation retuning 0 only or an matching IV. ?* @param random a {@code SecureRandom} implementation. If {@code null} * is used for the random object, then a nonce consisting of all * zero bytes will be used. Otherwise a random nonce will be * used. 3) If ChaCha20ParameterSpec would extends IvParameterSpec if would be valid for booth modes in engineInit. Even if the counter is not needed. As an alternative i would allow ChaCha20ParameterSpec also for AEAD mode. Grup Thomas On 3/26/2018 9:08 PM, Jamil Nimeh wrote: > Hello all, > > This is a request for review for the ChaCha20 and ChaCha20-Poly1305 > cipher implementations.? Links to the webrev and the JEP which > outlines the characteristics and behavior of the ciphers are listed > below. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ > http://openjdk.java.net/jeps/329 > > Thanks, > --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From lussnig at suche.org Mon Mar 26 22:43:15 2018 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 27 Mar 2018 00:43:15 +0200 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <227a01af-7a56-0354-41ad-08cdb9c8cbd2@oracle.com> References: <708677fc-9cdd-a145-6794-283cab51c84e@suche.org> <227a01af-7a56-0354-41ad-08cdb9c8cbd2@oracle.com> Message-ID: <3953a8b1-b98c-78a8-235c-154920203150@suche.org> Hi, this choice is even better than the current version. Because than the default system wide secure random provider is used. Gru? Thomas On 3/27/2018 12:23 AM, Jamil Nimeh wrote: > > Another thought on #2: Another way we could go with this is to create > a new SecureRandom() or use JceSecurity.RANDOM when the random > parameter is null.? That would make init(op, key, random) and init(op, > key) behave the same when random is null.? You would always get a > random nonce in these two forms.? I may go that direction since > there's an established behavior for when no SecureRandom is provided > through Cipher.init(int, Key). > > --Jamil From weijun.wang at oracle.com Tue Mar 27 07:51:38 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 27 Mar 2018 15:51:38 +0800 Subject: RFR 8180570: Refactor sun/security/mscapi shell tests to plain java tests In-Reply-To: <865D5A85-8CA2-40EA-8EA4-841F2B5FC756@oracle.com> References: <3B74A4FA-D273-448C-8294-B2093AC48EAB@oracle.com> <865D5A85-8CA2-40EA-8EA4-841F2B5FC756@oracle.com> Message-ID: Ping again. > On Mar 8, 2018, at 8:37 PM, Weijun Wang wrote: > > > >> On Mar 8, 2018, at 6:13 PM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8180570/webrev.00 > > Updated in place. > >> >> Several notes: >> >> 1. The original KeyStoreCompatibilityMode.sh does not check the exit value of each command. I assume it should. >> >> 2. I don't really understand what SystemDrive is for in RSAEncryptDecrypt.sh. Maybe about running the test from \\remote\share? I also cannot find JDK-6449799. >> >> 3. SecurityTools::getProcessBuilder is modified a little. On my Windows machine without cygwin (major reason why I want to work on this RFE), setting -Djava.security.egd=file:/dev/./urandom causes an error. >> >> 4. nonUniqueAliases/NonUniqueAliases.sh is not touched. It has an @ignore. > > This one is also updated. I tried it on a Windows Server 2016 with certutil.exe and it succeeds. > > --Max > >> >> Thanks >> Max >> > From artem.smotrakov at gmail.com Tue Mar 27 08:03:30 2018 From: artem.smotrakov at gmail.com (Artem Smotrakov) Date: Tue, 27 Mar 2018 10:03:30 +0200 Subject: RFR 8180570: Refactor sun/security/mscapi shell tests to plain java tests In-Reply-To: References: <3B74A4FA-D273-448C-8294-B2093AC48EAB@oracle.com> <865D5A85-8CA2-40EA-8EA4-841F2B5FC756@oracle.com> Message-ID: Hi Max, KeytoolChangeAlias.java: - maybe better to run ks.deleteEntry("13579") in a finally block - should it delete "246810" as well? Otherwise looks good to me :) Artem 2018-03-27 9:51 GMT+02:00 Weijun Wang : > Ping again. > > > On Mar 8, 2018, at 8:37 PM, Weijun Wang wrote: > > > > > > > >> On Mar 8, 2018, at 6:13 PM, Weijun Wang wrote: > >> > >> Please take a review at > >> > >> http://cr.openjdk.java.net/~weijun/8180570/webrev.00 > > > > Updated in place. > > > >> > >> Several notes: > >> > >> 1. The original KeyStoreCompatibilityMode.sh does not check the exit > value of each command. I assume it should. > >> > >> 2. I don't really understand what SystemDrive is for in > RSAEncryptDecrypt.sh. Maybe about running the test from \\remote\share? I > also cannot find JDK-6449799. > >> > >> 3. SecurityTools::getProcessBuilder is modified a little. On my > Windows machine without cygwin (major reason why I want to work on this > RFE), setting -Djava.security.egd=file:/dev/./urandom causes an error. > >> > >> 4. nonUniqueAliases/NonUniqueAliases.sh is not touched. It has an > @ignore. > > > > This one is also updated. I tried it on a Windows Server 2016 with > certutil.exe and it succeeds. > > > > --Max > > > >> > >> Thanks > >> Max > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Mar 27 08:09:49 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 27 Mar 2018 16:09:49 +0800 Subject: RFR 8180570: Refactor sun/security/mscapi shell tests to plain java tests In-Reply-To: References: <3B74A4FA-D273-448C-8294-B2093AC48EAB@oracle.com> <865D5A85-8CA2-40EA-8EA4-841F2B5FC756@oracle.com> Message-ID: <250FB04A-F9F3-43C0-B447-49CA19DB311E@oracle.com> Hi Artem Long time no see. I checked and you're still a reviewer. Great. Thanks for the good suggestions. On the other hand, MSCAPI keystore is a little strange in alias names, could be duplicated, could have key with a cert. I'll try out on a real machine. --Max > On Mar 27, 2018, at 4:03 PM, Artem Smotrakov wrote: > > Hi Max, > > KeytoolChangeAlias.java: > - maybe better to run ks.deleteEntry("13579") in a finally block > - should it delete "246810" as well? > > Otherwise looks good to me :) > > Artem > > > > 2018-03-27 9:51 GMT+02:00 Weijun Wang : > Ping again. > > > On Mar 8, 2018, at 8:37 PM, Weijun Wang wrote: > > > > > > > >> On Mar 8, 2018, at 6:13 PM, Weijun Wang wrote: > >> > >> Please take a review at > >> > >> http://cr.openjdk.java.net/~weijun/8180570/webrev.00 > > > > Updated in place. > > > >> > >> Several notes: > >> > >> 1. The original KeyStoreCompatibilityMode.sh does not check the exit value of each command. I assume it should. > >> > >> 2. I don't really understand what SystemDrive is for in RSAEncryptDecrypt.sh. Maybe about running the test from \\remote\share? I also cannot find JDK-6449799. > >> > >> 3. SecurityTools::getProcessBuilder is modified a little. On my Windows machine without cygwin (major reason why I want to work on this RFE), setting -Djava.security.egd=file:/dev/./urandom causes an error. > >> > >> 4. nonUniqueAliases/NonUniqueAliases.sh is not touched. It has an @ignore. > > > > This one is also updated. I tried it on a Windows Server 2016 with certutil.exe and it succeeds. > > > > --Max > > > >> > >> Thanks > >> Max > >> > > > > From Alan.Bateman at oracle.com Tue Mar 27 13:06:00 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Mar 2018 14:06:00 +0100 Subject: -Djava.security.manager=problems for service providers In-Reply-To: <5ABA3F87.50804@zeus.net.au> References: <5ABA3F87.50804@zeus.net.au> Message-ID: <1453efcd-4ebd-9942-34b5-fdb480977283@oracle.com> Moving this to security-dev. From the stack trace, it looks like you are using JDK 8 or older. There are several changes in JDK 9 and newer in the PolicyFile code to how it loads its resources that may help with the issues you are seeing. -Alan On 27/03/2018 13:56, Peter Firmstone wrote: > Not sure if this is the right place to mention this. > > Anyone notice that specifying a custom security manager at jvm start > up causes issues with service providers loading??? If using the sun > PolicyFile implementation, the policy doesn't load due to the provider > failure, I have a custom policy implementation that will allow the jvm > to run in this state, and other providers are also not loading, such > as the logger and JCE. > > Note that it doesn't occur if the security manager is set > programmatically in the main method at start up, only if it's set via > command line option. > > Examples of providers not loading: > > ???? [java] java.lang.NullPointerException > ???? [java] Can't load log handler "java.util.logging.ConsoleHandler" > ???? [java] java.lang.NullPointerException > ???? [java] java.lang.NullPointerException > ???? [java]???? at > java.util.logging.LogManager$5.run(LogManager.java:965) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) > ???? [java]???? at > java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) > ???? [java]???? at > java.util.logging.LogManager.access$1500(LogManager.java:145) > ???? [java]???? at > java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) > ???? [java]???? at java.util.logging.Logger.getHandlers(Logger.java:1777) > ???? [java]???? at java.util.logging.Logger.log(Logger.java:735) > ???? [java]???? at java.util.logging.Logger.doLog(Logger.java:765) > ???? [java]???? at java.util.logging.Logger.log(Logger.java:788) > ???? [java]???? at > org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) > ???? [java]???? at > org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) > ???? [java]???? at > org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) > ???? [java]???? at > org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) > ???? [java]???? at > org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) > ???? [java]???? at > org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) > ???? [java]???? at > org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) > ???? [java]???? at > org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) > ???? [java]???? at > org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) > ???? [java]???? at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > ???? [java]???? at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > ???? [java]???? at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > ???? [java]???? at > java.lang.reflect.Constructor.newInstance(Constructor.java:423) > ???? [java]???? at java.lang.Class.newInstance(Class.java:442) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:93) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) > ???? [java]???? at > java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > ???? [java]???? at > java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > > > ???? [java] Error occurred during initialization of VM > ???? [java] java.lang.ExceptionInInitializerError > ???? [java]???? at > java.util.ResourceBundle.getLoader(ResourceBundle.java:482) > ???? [java]???? at > java.util.ResourceBundle.getBundle(ResourceBundle.java:783) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) > ???? [java]???? at > sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:626) > ???? [java]???? at > sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:439) > ???? [java]???? at > sun.security.provider.PolicyFile.(PolicyFile.java:297) > ???? [java]???? at java.security.Policy.getPolicyNoCheck(Policy.java:196) > ???? [java]???? at java.security.Policy.getPolicy(Policy.java:154) > ???? [java]???? at net.jini.security.Security$7.run(Security.java:1054) > ???? [java]???? at net.jini.security.Security$7.run(Security.java:1052) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > net.jini.security.Security.getPolicy(Security.java:1052) > ???? [java]???? at > net.jini.security.Security.getContext(Security.java:506) > ???? [java]???? at > org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) > ???? [java]???? at > org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) > ???? [java]???? at > org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) > ???? [java]???? at > org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) > ???? [java]???? at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > ???? [java]???? at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > ???? [java]???? at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > ???? [java]???? at > java.lang.reflect.Constructor.newInstance(Constructor.java:423) > ???? [java]???? at java.lang.Class.newInstance(Class.java:442) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:93) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) > ???? [java]???? at > java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > ???? [java]???? at > java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > ???? [java] Caused by: java.lang.NullPointerException > ???? [java]???? at > java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) > ???? [java]???? at > java.util.ResourceBundle.getLoader(ResourceBundle.java:482) > ???? [java]???? at > java.util.ResourceBundle.getBundle(ResourceBundle.java:783) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) > ???? [java]???? at > sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:626) > ???? [java]???? at > sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:439) > ???? [java]???? at > sun.security.provider.PolicyFile.(PolicyFile.java:297) > ???? [java]???? at java.security.Policy.getPolicyNoCheck(Policy.java:196) > ???? [java]???? at java.security.Policy.getPolicy(Policy.java:154) > ???? [java]???? at net.jini.security.Security$7.run(Security.java:1054) > ???? [java]???? at net.jini.security.Security$7.run(Security.java:1052) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > net.jini.security.Security.getPolicy(Security.java:1052) > ???? [java]???? at > net.jini.security.Security.getContext(Security.java:506) > ???? [java] Unexpected exception: > ???? [java]???? at > org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) > ???? [java]???? at > org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) > ???? [java]???? at > org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) > ???? [java]???? at > org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) > ???? [java]???? at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > ???? [java]???? at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > ???? [java]???? at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > ???? [java]???? at > java.lang.reflect.Constructor.newInstance(Constructor.java:423) > ???? [java]???? at java.lang.Class.newInstance(Class.java:442) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:93) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) > ???? [java]???? at > java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > ???? [java]???? at > java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > > > > ???? [java] java.lang.ExceptionInInitializerError > ???? [java]???? at > javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) > ???? [java]???? at > javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) > ???? [java]???? at > javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) > ???? [java]???? at > sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) > ???? [java]???? at > sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) > ???? [java]???? at > sun.security.ssl.CipherSuite.(CipherSuite.java:614) > ???? [java]???? at > sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) > ???? [java]???? at > sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) > ???? [java]???? at > sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) > ???? [java]???? at java.lang.Class.forName0(Native Method) > ???? [java]???? at java.lang.Class.forName(Class.java:264) > ???? [java]???? at > java.security.Provider$Service.getImplClass(Provider.java:1634) > ???? [java]???? at > java.security.Provider$Service.newInstance(Provider.java:1592) > ???? [java]???? at > sun.security.jca.GetInstance.getInstance(GetInstance.java:236) > ???? [java]???? at > sun.security.jca.GetInstance.getInstance(GetInstance.java:164) > ???? [java]???? at > javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) > ???? [java]???? at > net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) > ???? [java]???? at > net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) > ???? [java]???? at > net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) > ???? [java]???? at > net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) > ???? [java]???? at > net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) > ???? [java]???? at > net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) > ???? [java]???? at > net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) > ???? [java]???? at > net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) > ???? [java]???? at > net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) > ???? [java]???? at com.sun.proxy.$Proxy2.registerGroup(Unknown Source) > ???? [java]???? at > org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) > ???? [java]???? at > org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) > ???? [java]???? at > org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) > ???? [java]???? at > org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) > ???? [java]???? at > org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) > ???? [java]???? at > org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) > ???? [java]???? at > org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) > ???? [java]???? at > org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) > ???? [java]???? at > org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) > ???? [java]???? at > org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) > ???? [java]???? at > org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) > ???? [java]???? at > org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) > ???? [java]???? at > org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) > ???? [java]???? at > org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > javax.security.auth.Subject.doAsPrivileged(Subject.java:483) > ???? [java]???? at > org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) > ???? [java]???? at > org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) > ???? [java] Caused by: java.lang.SecurityException: Can not initialize > cryptographic mechanism > ???? [java]???? at javax.crypto.JceSecurity.(JceSecurity.java:93) > ???? [java]???? ... 44 more > ???? [java] Caused by: java.lang.SecurityException: Cannot locate > policy or framework files! > ???? [java]???? at > javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) > ???? [java]???? at > javax.crypto.JceSecurity.access$000(JceSecurity.java:50) > ???? [java]???? at javax.crypto.JceSecurity$1.run(JceSecurity.java:85) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at javax.crypto.JceSecurity.(JceSecurity.java:82) From daniel.fuchs at oracle.com Tue Mar 27 14:09:04 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 27 Mar 2018 15:09:04 +0100 Subject: -Djava.security.manager=problems for service providers In-Reply-To: <1453efcd-4ebd-9942-34b5-fdb480977283@oracle.com> References: <5ABA3F87.50804@zeus.net.au> <1453efcd-4ebd-9942-34b5-fdb480977283@oracle.com> Message-ID: <7772a0bc-018a-2cd2-43ce-e7a414fdf08c@oracle.com> Hi, On 27/03/2018 14:06, Alan Bateman wrote: > Moving this to security-dev. > > From the stack trace, it looks like you are using JDK 8 or older. There > are several changes in JDK 9 and newer in the PolicyFile code to how it > loads its resources that may help with the issues you are seeing. > > -Alan [snip] > [java] at java.util.logging.Logger.log(Logger.java:788) > [java] at org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) In what logging is concerned, it's probably not a good idea to use java.util.logging in a Policy/SecurityManager implementation supplied on the command line as java.util.logging uses doPrivileged and checks for permissions. For the record the line that throws in the first stack trace seems to be this one at LogManager.java:965 Class clz = ClassLoader.getSystemClassLoader().loadClass(word); The exception is caught and printed on System.err at line 981 allowing the caller to proceed - so it's not what is causing the ExceptionInInitializerError, but it shows that ClassLoader.getSystemClassLoader() is probably returning null at this point, and it looks like it is the same issue you're seeing at ResourceBundle.java:502 later on, which prevents the CombinerSecurityManager to initialize. Hopes this helps, -- daniel > > On 27/03/2018 13:56, Peter Firmstone wrote: >> Not sure if this is the right place to mention this. >> >> Anyone notice that specifying a custom security manager at jvm start >> up causes issues with service providers loading??? If using the sun >> PolicyFile implementation, the policy doesn't load due to the provider >> failure, I have a custom policy implementation that will allow the jvm >> to run in this state, and other providers are also not loading, such >> as the logger and JCE. >> >> Note that it doesn't occur if the security manager is set >> programmatically in the main method at start up, only if it's set via >> command line option. >> >> Examples of providers not loading: >> >> ???? [java] java.lang.NullPointerException >> ???? [java] Can't load log handler "java.util.logging.ConsoleHandler" >> ???? [java] java.lang.NullPointerException >> ???? [java] java.lang.NullPointerException >> ???? [java]???? at >> java.util.logging.LogManager$5.run(LogManager.java:965) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) >> ???? [java]???? at >> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) >> >> ???? [java]???? at >> java.util.logging.LogManager.access$1500(LogManager.java:145) >> ???? [java]???? at >> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) >> >> ???? [java]???? at java.util.logging.Logger.getHandlers(Logger.java:1777) >> ???? [java]???? at java.util.logging.Logger.log(Logger.java:735) >> ???? [java]???? at java.util.logging.Logger.doLog(Logger.java:765) >> ???? [java]???? at java.util.logging.Logger.log(Logger.java:788) >> ???? [java]???? at >> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >> >> ???? [java]???? at >> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) >> >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) >> >> ???? [java]???? at >> org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) >> >> ???? [java]???? at >> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) >> >> ???? [java]???? at >> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) >> >> ???? [java]???? at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) >> >> ???? [java]???? at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) >> >> ???? [java]???? at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> >> ???? [java]???? at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) >> >> ???? [java]???? at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> ???? [java]???? at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> >> ???? [java]???? at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> >> ???? [java]???? at >> java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> ???? [java]???? at java.lang.Class.newInstance(Class.java:442) >> ???? [java]???? at sun.misc.Launcher.(Launcher.java:93) >> ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) >> ???? [java]???? at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> ???? [java]???? at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> >> >> ???? [java] Error occurred during initialization of VM >> ???? [java] java.lang.ExceptionInInitializerError >> ???? [java]???? at >> java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> ???? [java]???? at >> java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> ???? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> ???? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> ???? [java]???? at >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> ???? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> ???? [java]???? at >> sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> ???? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> ???? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> ???? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> ???? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> ???? [java]???? at >> sun.security.provider.PolicyFile.(PolicyFile.java:297) >> ???? [java]???? at java.security.Policy.getPolicyNoCheck(Policy.java:196) >> ???? [java]???? at java.security.Policy.getPolicy(Policy.java:154) >> ???? [java]???? at net.jini.security.Security$7.run(Security.java:1054) >> ???? [java]???? at net.jini.security.Security$7.run(Security.java:1052) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> net.jini.security.Security.getPolicy(Security.java:1052) >> ???? [java]???? at >> net.jini.security.Security.getContext(Security.java:506) >> ???? [java]???? at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >> >> ???? [java]???? at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >> >> ???? [java]???? at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> >> ???? [java]???? at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >> >> ???? [java]???? at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> ???? [java]???? at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> >> ???? [java]???? at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> >> ???? [java]???? at >> java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> ???? [java]???? at java.lang.Class.newInstance(Class.java:442) >> ???? [java]???? at sun.misc.Launcher.(Launcher.java:93) >> ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) >> ???? [java]???? at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> ???? [java]???? at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> ???? [java] Caused by: java.lang.NullPointerException >> ???? [java]???? at >> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >> ???? [java]???? at >> java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> ???? [java]???? at >> java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> ???? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> ???? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> ???? [java]???? at >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> ???? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> ???? [java]???? at >> sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> ???? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> ???? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> ???? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> ???? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> ???? [java]???? at >> sun.security.provider.PolicyFile.(PolicyFile.java:297) >> ???? [java]???? at java.security.Policy.getPolicyNoCheck(Policy.java:196) >> ???? [java]???? at java.security.Policy.getPolicy(Policy.java:154) >> ???? [java]???? at net.jini.security.Security$7.run(Security.java:1054) >> ???? [java]???? at net.jini.security.Security$7.run(Security.java:1052) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> net.jini.security.Security.getPolicy(Security.java:1052) >> ???? [java]???? at >> net.jini.security.Security.getContext(Security.java:506) >> ???? [java] Unexpected exception: >> ???? [java]???? at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >> >> ???? [java]???? at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >> >> ???? [java]???? at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> >> ???? [java]???? at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >> >> ???? [java]???? at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> ???? [java]???? at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> >> ???? [java]???? at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> >> ???? [java]???? at >> java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> ???? [java]???? at java.lang.Class.newInstance(Class.java:442) >> ???? [java]???? at sun.misc.Launcher.(Launcher.java:93) >> ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) >> ???? [java]???? at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> ???? [java]???? at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> >> >> >> ???? [java] java.lang.ExceptionInInitializerError >> ???? [java]???? at >> javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) >> ???? [java]???? at >> javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) >> ???? [java]???? at >> javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) >> ???? [java]???? at >> sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) >> ???? [java]???? at >> sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) >> ???? [java]???? at >> sun.security.ssl.CipherSuite.(CipherSuite.java:614) >> ???? [java]???? at >> sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) >> >> ???? [java]???? at >> sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) >> ???? [java]???? at >> sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) >> >> ???? [java]???? at java.lang.Class.forName0(Native Method) >> ???? [java]???? at java.lang.Class.forName(Class.java:264) >> ???? [java]???? at >> java.security.Provider$Service.getImplClass(Provider.java:1634) >> ???? [java]???? at >> java.security.Provider$Service.newInstance(Provider.java:1592) >> ???? [java]???? at >> sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >> ???? [java]???? at >> sun.security.jca.GetInstance.getInstance(GetInstance.java:164) >> ???? [java]???? at >> javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) >> ???? [java]???? at >> net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) >> ???? [java]???? at >> net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) >> ???? [java]???? at >> net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) >> >> ???? [java]???? at >> net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) >> >> ???? [java]???? at >> net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) >> ???? [java]???? at >> net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) >> ???? [java]???? at >> net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) >> ???? [java]???? at >> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) >> >> ???? [java]???? at >> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) >> >> ???? [java]???? at com.sun.proxy.$Proxy2.registerGroup(Unknown Source) >> ???? [java]???? at >> org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) >> >> ???? [java]???? at >> org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) >> >> ???? [java]???? at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >> >> ???? [java]???? at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >> >> ???? [java]???? at >> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) >> >> ???? [java]???? at >> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) >> >> ???? [java]???? at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >> >> ???? [java]???? at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >> >> ???? [java]???? at >> org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) >> >> ???? [java]???? at >> org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) >> >> ???? [java]???? at >> org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) >> >> ???? [java]???? at >> org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) >> ???? [java]???? at >> org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) >> ???? [java]???? at >> org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at >> javax.security.auth.Subject.doAsPrivileged(Subject.java:483) >> ???? [java]???? at >> org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) >> >> ???? [java]???? at >> org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) >> ???? [java] Caused by: java.lang.SecurityException: Can not initialize >> cryptographic mechanism >> ???? [java]???? at javax.crypto.JceSecurity.(JceSecurity.java:93) >> ???? [java]???? ... 44 more >> ???? [java] Caused by: java.lang.SecurityException: Cannot locate >> policy or framework files! >> ???? [java]???? at >> javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) >> ???? [java]???? at >> javax.crypto.JceSecurity.access$000(JceSecurity.java:50) >> ???? [java]???? at javax.crypto.JceSecurity$1.run(JceSecurity.java:85) >> ???? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ???? [java]???? at javax.crypto.JceSecurity.(JceSecurity.java:82) > From adam.petcher at oracle.com Tue Mar 27 15:12:17 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 27 Mar 2018 11:12:17 -0400 Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: References: Message-ID: <561659bf-8204-1773-07fd-ecb7e1fb8825@oracle.com> I have a couple of minor comments. I am not a Reviewer, so someone else will still need to look at this. KeySizeTest: You can use the byteArrayToHexString that is in Convert in the test lib. See TestXDH.java for an example of how this method is imported and used. MultiThreadTest: In testKeyAgreement, you may want to generate two key pairs, do two key agreement operations, and then compare the results. Then this test could catch arithmetic errors caused by caching and precomputation. On 3/26/2018 12:38 PM, Sibabrata Sahoo wrote: > > Hi, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184359 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.00/ > > > All the Test files uses KeyAgreement, KeyPairGenerator, Several > KeySpecs from SunJCE library to Test DiffieHellman, ECDH and XDH with > curve25519 and curve448 algorithms. Each Test files try to address > several cases and the purpose of each has been commented in their own > files. > > Thanks, > > Siba > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Mar 27 15:15:59 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 27 Mar 2018 11:15:59 -0400 Subject: [11] RFR: 8193032: Remove terminally deprecated SecurityManager APIs Message-ID: Please remove this change to remove several SecurityManager methods that have been marked for removal since Java SE 9: checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess, and checkMemberAccess. These methods no longer have any benefit, and removing them will follow through on the the plan to remove them. We believe the compatibility risk is fairly low - we have only found a very small number of custom SecurityManager implementations that are overriding the methods and using @Override or calling the methods directly that will need to change their code. See the CSR for more info. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8193032/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8200185 Thanks, Sean From Alan.Bateman at oracle.com Tue Mar 27 15:26:19 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Mar 2018 16:26:19 +0100 Subject: [11] RFR: 8193032: Remove terminally deprecated SecurityManager APIs In-Reply-To: References: Message-ID: <452c3dc8-fb8e-2e67-05eb-96d5ec34175a@oracle.com> On 27/03/2018 16:15, Sean Mullan wrote: > Please remove this change to remove several SecurityManager methods > that have been marked for removal since Java SE 9: > checkTopLevelWindow, checkSystemClipboardAccess, > checkAwtEventQueueAccess, and checkMemberAccess. These methods no > longer have any benefit, and removing them will follow through on the > the plan to remove them. Right, these method were degraded to check AllPermission and I don't recall anyone screaming. This gives some confidence that they aren't widely used. So I think looks good. -Alan From sean.mullan at oracle.com Tue Mar 27 15:28:44 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 27 Mar 2018 11:28:44 -0400 Subject: [11] RFR: 8193032: Remove terminally deprecated SecurityManager APIs In-Reply-To: <452c3dc8-fb8e-2e67-05eb-96d5ec34175a@oracle.com> References: <452c3dc8-fb8e-2e67-05eb-96d5ec34175a@oracle.com> Message-ID: <6a4f26e9-06c1-b5cf-3585-3e8079530ad3@oracle.com> On 3/27/18 11:26 AM, Alan Bateman wrote: > On 27/03/2018 16:15, Sean Mullan wrote: >> Please remove this change to remove several SecurityManager methods >> that have been marked for removal since Java SE 9: >> checkTopLevelWindow, checkSystemClipboardAccess, >> checkAwtEventQueueAccess, and checkMemberAccess. These methods no >> longer have any benefit, and removing them will follow through on the >> the plan to remove them. > Right, these method were degraded to check AllPermission and I don't > recall anyone screaming. This gives some confidence that they aren't > widely used. So I think looks good. Thanks, and I obviously meant to say "Please *review* this change" above :) --Sean From adam.petcher at oracle.com Tue Mar 27 20:23:20 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 27 Mar 2018 16:23:20 -0400 Subject: RFR 8171277: Elliptic Curves for Security in Crypto (part 2) Message-ID: <5096fafb-a513-796d-652b-a712d4a7a7b2@oracle.com> After the last code review[1] on this topic completed, it was suggested that I add some more "spec enforcement" to the XDH service. The code hasn't been integrated yet, so I'm doing this as a follow-on review under the same ticket. The latest webrev contains only the diff from the end of the last review. JBS: https://bugs.openjdk.java.net/browse/JDK-8171277 Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.03/ (note: you can look at webrev.02 to see the code at the end of the last review). For XDH, we are adding the algorithm names "X25519" and "X448", because these names are more widely known than "XDH". This leaves us with the problem of whether things like this should be allowed: var kpg = KeyPairGenerator.getInstance("X448"); kpg.initialize(new NamedParameterSpec("X25519")); To promote good code hygiene, the implementation in SunEC will reject all confusing combinations like this in all XDH services. Programmers can still use the "XDH" algorithm name to get a service that allows all supported parameters and key sizes. [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-March/016915.html From mandy.chung at oracle.com Tue Mar 27 22:12:03 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 28 Mar 2018 06:12:03 +0800 Subject: [11] RFR: 8193032: Remove terminally deprecated SecurityManager APIs In-Reply-To: References: Message-ID: <0f734830-1fef-caa2-59b0-d64ffccc8212@oracle.com> On 3/27/18 11:15 PM, Sean Mullan wrote: > Please remove this change to remove several SecurityManager methods > that have been marked for removal since Java SE 9: > checkTopLevelWindow, checkSystemClipboardAccess, > checkAwtEventQueueAccess, and checkMemberAccess. These methods no > longer have any benefit, and removing them will follow through on the > the plan to remove them. > > We believe the compatibility risk is fairly low - we have only found a > very small number of custom SecurityManager implementations that are > overriding the methods and using @Override or calling the methods > directly that will need to change their code. See the CSR for more info. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8193032/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8200185 This looks good to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Mar 27 23:52:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 28 Mar 2018 07:52:40 +0800 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> Message-ID: > On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie wrote: > > https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth There is only one function to export and it already has JNIEXPORT, so you can just remove the new $(LIBJAAS_CFLAGS) [1]. Are you going to update your webrev? Thanks Max [1] http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html From valerie.peng at oracle.com Wed Mar 28 01:40:35 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 27 Mar 2018 18:40:35 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" Message-ID: Hi Brad, Can you please help review the changes for RSA-PSS support? I also added some minor enhancement which add 2 more digest algorithms for OAEP padding. There are quite some changes involved. The main changes are in the SunRsaSign provider, i.e. sun.security.rsa packages. I reused existing RSAKeyFactory, RSAKeyPairGenerator, and the RSA KeyImpl classes as much as possible. However, given that RSA-PSS signatures requires parameters, I put its implementation in a separate class, i.e. RSAPSSSignature.java. RFE: https://bugs.openjdk.java.net/browse/JDK-8146293 Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/ Existing and new regression tests have been run and result looks fine. Thanks, Valerie From jini at zeus.net.au Wed Mar 28 01:50:08 2018 From: jini at zeus.net.au (Peter) Date: Wed, 28 Mar 2018 11:50:08 +1000 Subject: -Djava.security.manager=problems for service providers Message-ID: <5ABAF4D0.209@zeus.net.au> Thanks Daniel, Ah yes, I see what's happening and why this only occurs when using -Djava.security.manager= sun.misc.Launcher calls the security manager constructor from within its constructor, which creates a recursive call back to the static method Launcher.getLauncher(), which returns the uninitialized static launcher field. CombinerSecurityManager checks during construction that the policy has been instantiated and it also instantiates a Logger. It could safely lose the logger, but the policy must be fully instantiated before the security manager is in force, otherwise it creates recursive calls in the security manager implementation. The simplest fix would be to move the instantiation of SecurityManager to a static initializer in Launcher that occurs after the construction of Launcher and setting of the static launcher field. This didn't become a problem until recently upgrading to the latest Java 8 JDK, so not sure of the history here. Regards Peter. More comments inline below: > Hi, > > On 27/03/2018 14:06, Alan Bateman wrote: > >/ Moving this to security-dev. > />/ > />/ From the stack trace, it looks like you are using JDK 8 or older. There > />/ are several changes in JDK 9 and newer in the PolicyFile code to how it > />/ loads its resources that may help with the issues you are seeing. > />/ > />/ -Alan > / > [snip] > > >/ [java] at java.util.logging.Logger.log(Logger.java:788) > />/ [java] at org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) > / > In what logging is concerned, it's probably not a good idea to > use java.util.logging in a Policy/SecurityManager implementation > supplied on the command line as java.util.logging uses > doPrivileged and checks for permissions. Work arounds for that problem: * Delegate logging to an executor. * Use a thread local variable to detect trusted recursive calls. * Only log messages during startup, when the policy or security manager isn't active. > For the record the line that throws in the first stack trace > seems to be this one at LogManager.java:965 > > Class clz = ClassLoader.getSystemClassLoader().loadClass(word); > > The exception is caught and printed on System.err at line 981 > allowing the caller to proceed - so it's not what is > causing the ExceptionInInitializerError, but it shows that > ClassLoader.getSystemClassLoader() is probably returning null > at this point, and it looks like it is the same issue you're > seeing at ResourceBundle.java:502 later on, which prevents the > CombinerSecurityManager to initialize. > > > Hopes this helps, > > -- daniel > > > >/ > />/ On 27/03/2018 13:56, Peter Firmstone wrote: > />>/ Not sure if this is the right place to mention this. > />>/ > />>/ Anyone notice that specifying a custom security manager at jvm start > />>/ up causes issues with service providers loading? If using the sun > />>/ PolicyFile implementation, the policy doesn't load due to the provider > />>/ failure, I have a custom policy implementation that will allow the jvm > />>/ to run in this state, and other providers are also not loading, such > />>/ as the logger and JCE. > />>/ > />>/ Note that it doesn't occur if the security manager is set > />>/ programmatically in the main method at start up, only if it's set via > />>/ command line option. > />>/ > />>/ Examples of providers not loading: > />>/ > />>/ [java] java.lang.NullPointerException > />>/ [java] Can't load log handler "java.util.logging.ConsoleHandler" > />>/ [java] java.lang.NullPointerException > />>/ [java] java.lang.NullPointerException > />>/ [java] at > />>/ java.util.logging.LogManager$5.run(LogManager.java:965) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) > />>/ [java] at > />>/ java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) > />>/ > />>/ [java] at > />>/ java.util.logging.LogManager.access$1500(LogManager.java:145) > />>/ [java] at > />>/ java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) > />>/ > />>/ [java] at java.util.logging.Logger.getHandlers(Logger.java:1777) > />>/ [java] at java.util.logging.Logger.log(Logger.java:735) > />>/ [java] at java.util.logging.Logger.doLog(Logger.java:765) > />>/ [java] at java.util.logging.Logger.log(Logger.java:788) > />>/ [java] at > />>/ org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) > />>/ > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) > />>/ > />>/ [java] at > />>/ org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) > />>/ > />>/ [java] at > />>/ org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) > />>/ > />>/ [java] at > />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > />>/ [java] at > />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > />>/ > />>/ [java] at > />>/ sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > />>/ > />>/ [java] at > />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) > />>/ [java] at java.lang.Class.newInstance(Class.java:442) > />>/ [java] at sun.misc.Launcher.(Launcher.java:93) > />>/ [java] at sun.misc.Launcher.(Launcher.java:54) > />>/ [java] at > />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > />>/ [java] at > />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > />>/ > />>/ > />>/ [java] Error occurred during initialization of VM > />>/ [java] java.lang.ExceptionInInitializerError > />>/ [java] at > />>/ java.util.ResourceBundle.getLoader(ResourceBundle.java:482) > />>/ [java] at > />>/ java.util.ResourceBundle.getBundle(ResourceBundle.java:783) > />>/ [java] at > />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) > />>/ [java] at > />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:626) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) > />>/ [java] at > />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) > />>/ [java] at > />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:439) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.(PolicyFile.java:297) > />>/ [java] at java.security.Policy.getPolicyNoCheck(Policy.java:196) > />>/ [java] at java.security.Policy.getPolicy(Policy.java:154) > />>/ [java] at net.jini.security.Security$7.run(Security.java:1054) > />>/ [java] at net.jini.security.Security$7.run(Security.java:1052) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ net.jini.security.Security.getPolicy(Security.java:1052) > />>/ [java] at > />>/ net.jini.security.Security.getContext(Security.java:506) > />>/ [java] at > />>/ org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) > />>/ > />>/ [java] at > />>/ org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) > />>/ > />>/ [java] at > />>/ org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) > />>/ > />>/ [java] at > />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > />>/ [java] at > />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > />>/ > />>/ [java] at > />>/ sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > />>/ > />>/ [java] at > />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) > />>/ [java] at java.lang.Class.newInstance(Class.java:442) > />>/ [java] at sun.misc.Launcher.(Launcher.java:93) > />>/ [java] at sun.misc.Launcher.(Launcher.java:54) > />>/ [java] at > />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > />>/ [java] at > />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > />>/ [java] Caused by: java.lang.NullPointerException > />>/ [java] at > />>/ java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) > />>/ [java] at > />>/ java.util.ResourceBundle.getLoader(ResourceBundle.java:482) > />>/ [java] at > />>/ java.util.ResourceBundle.getBundle(ResourceBundle.java:783) > />>/ [java] at > />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) > />>/ [java] at > />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:626) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) > />>/ [java] at > />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) > />>/ [java] at > />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:439) > />>/ [java] at > />>/ sun.security.provider.PolicyFile.(PolicyFile.java:297) > />>/ [java] at java.security.Policy.getPolicyNoCheck(Policy.java:196) > />>/ [java] at java.security.Policy.getPolicy(Policy.java:154) > />>/ [java] at net.jini.security.Security$7.run(Security.java:1054) > />>/ [java] at net.jini.security.Security$7.run(Security.java:1052) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ net.jini.security.Security.getPolicy(Security.java:1052) > />>/ [java] at > />>/ net.jini.security.Security.getContext(Security.java:506) > />>/ [java] Unexpected exception: > />>/ [java] at > />>/ org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) > />>/ > />>/ [java] at > />>/ org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) > />>/ > />>/ [java] at > />>/ org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) > />>/ > />>/ [java] at > />>/ org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) > />>/ > />>/ [java] at > />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > />>/ [java] at > />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > />>/ > />>/ [java] at > />>/ sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > />>/ > />>/ [java] at > />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) > />>/ [java] at java.lang.Class.newInstance(Class.java:442) > />>/ [java] at sun.misc.Launcher.(Launcher.java:93) > />>/ [java] at sun.misc.Launcher.(Launcher.java:54) > />>/ [java] at > />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > />>/ [java] at > />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > />>/ > />>/ > />>/ > />>/ [java] java.lang.ExceptionInInitializerError > />>/ [java] at > />>/ javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) > />>/ [java] at > />>/ javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) > />>/ [java] at > />>/ javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) > />>/ [java] at > />>/ sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) > />>/ [java] at > />>/ sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) > />>/ [java] at > />>/ sun.security.ssl.CipherSuite.(CipherSuite.java:614) > />>/ [java] at > />>/ sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) > />>/ > />>/ [java] at > />>/ sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) > />>/ [java] at > />>/ sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) > />>/ > />>/ [java] at java.lang.Class.forName0(Native Method) > />>/ [java] at java.lang.Class.forName(Class.java:264) > />>/ [java] at > />>/ java.security.Provider$Service.getImplClass(Provider.java:1634) > />>/ [java] at > />>/ java.security.Provider$Service.newInstance(Provider.java:1592) > />>/ [java] at > />>/ sun.security.jca.GetInstance.getInstance(GetInstance.java:236) > />>/ [java] at > />>/ sun.security.jca.GetInstance.getInstance(GetInstance.java:164) > />>/ [java] at > />>/ javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) > />>/ [java] at > />>/ net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) > />>/ [java] at > />>/ net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) > />>/ [java] at > />>/ net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) > />>/ > />>/ [java] at > />>/ net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) > />>/ > />>/ [java] at > />>/ net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) > />>/ [java] at > />>/ net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) > />>/ [java] at > />>/ net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) > />>/ [java] at > />>/ net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) > />>/ > />>/ [java] at > />>/ net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) > />>/ > />>/ [java] at com.sun.proxy.$Proxy2.registerGroup(Unknown Source) > />>/ [java] at > />>/ org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) > />>/ > />>/ [java] at > />>/ org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) > />>/ > />>/ [java] at > />>/ org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) > />>/ [java] at > />>/ org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) > />>/ [java] at > />>/ org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at > />>/ javax.security.auth.Subject.doAsPrivileged(Subject.java:483) > />>/ [java] at > />>/ org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) > />>/ > />>/ [java] at > />>/ org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) > />>/ [java] Caused by: java.lang.SecurityException: Can not initialize > />>/ cryptographic mechanism > />>/ [java] at javax.crypto.JceSecurity.(JceSecurity.java:93) > />>/ [java] ... 44 more > />>/ [java] Caused by: java.lang.SecurityException: Cannot locate > />>/ policy or framework files! > />>/ [java] at > />>/ javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) > />>/ [java] at > />>/ javax.crypto.JceSecurity.access$000(JceSecurity.java:50) > />>/ [java] at javax.crypto.JceSecurity$1.run(JceSecurity.java:85) > />>/ [java] at java.security.AccessController.doPrivileged(Native > />>/ Method) > />>/ [java] at javax.crypto.JceSecurity.(JceSecurity.java:82) > />/ > / From jini at zeus.net.au Wed Mar 28 04:20:56 2018 From: jini at zeus.net.au (Peter) Date: Wed, 28 Mar 2018 14:20:56 +1000 Subject: -Djava.security.manager=problems for service provider In-Reply-To: <5ABAF4D0.209@zeus.net.au> References: <5ABAF4D0.209@zeus.net.au> Message-ID: <5ABB1828.2030604@zeus.net.au> It would be more correct to say, it wasn't noticed until recently. The logger was recently added to our policy implementation as a todo item, previously it went to System.out.err. The logger in our security manager, while a static field, has this comment: /** * Logger is lazily loaded, the SecurityManager can be loaded prior to * the system ClassLoader, attempting to load a Logger will cause a * NullPointerException, when calling ClassLoader.getSystemClassLoader(), * in order to load the logger class. Unfortunately we can't have the same lazy loading for the policy provider as all logging is related to parsing policy file syntax errors, all done prior to construction of the policy. We could remove the Logger from the policy, but that makes tracking down policy syntax errors a problem usually after a period of running, rather than during start up. We also need to ensure all classes the SecurityManager will cause to be loaded are loaded prior to the security manager constructor completing. For example: /* The following ensures the classes we need are loaded early to avoid * class loading deadlock */ checkPermission(new RuntimePermission("setIO"), SMPrivilegedContext); It seems the best advise is to simply avoid using -Djava.security.manager in our case. Cheers, Peter. On 28/03/2018 11:50 AM, Peter wrote: > Thanks Daniel, > > Ah yes, I see what's happening and why this only occurs when using > -Djava.security.manager= > > sun.misc.Launcher calls the security manager constructor from within > its constructor, which creates a recursive call back to the static > method Launcher.getLauncher(), which returns the uninitialized static > launcher field. > > CombinerSecurityManager checks during construction that the policy has > been instantiated and it also instantiates a Logger. It could safely > lose the logger, but the policy must be fully instantiated before the > security manager is in force, otherwise it creates recursive calls in > the security manager implementation. > > The simplest fix would be to move the instantiation of SecurityManager > to a static initializer in Launcher that occurs after the > construction of Launcher and setting of the static launcher field. > > This didn't become a problem until recently upgrading to the latest > Java 8 JDK, so not sure of the history here. > > Regards Peter. > > More comments inline below: > >> Hi, >> >> On 27/03/2018 14:06, Alan Bateman wrote: >> >/ Moving this to security-dev. >> />/ >> />/ From the stack trace, it looks like you are using JDK 8 or >> older. There >> />/ are several changes in JDK 9 and newer in the PolicyFile code to >> how it >> />/ loads its resources that may help with the issues you are seeing. >> />/ >> />/ -Alan >> / >> [snip] >> >> >/ [java] at java.util.logging.Logger.log(Logger.java:788) >> />/ [java] at >> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >> / >> In what logging is concerned, it's probably not a good idea to >> use java.util.logging in a Policy/SecurityManager implementation >> supplied on the command line as java.util.logging uses >> doPrivileged and checks for permissions. > > Work arounds for that problem: > > * Delegate logging to an executor. > * Use a thread local variable to detect trusted recursive calls. > * Only log messages during startup, when the policy or security > manager isn't active. > > >> For the record the line that throws in the first stack trace >> seems to be this one at LogManager.java:965 >> >> Class clz = >> ClassLoader.getSystemClassLoader().loadClass(word); >> >> The exception is caught and printed on System.err at line 981 >> allowing the caller to proceed - so it's not what is >> causing the ExceptionInInitializerError, but it shows that >> ClassLoader.getSystemClassLoader() is probably returning null >> at this point, and it looks like it is the same issue you're >> seeing at ResourceBundle.java:502 later on, which prevents the >> CombinerSecurityManager to initialize. >> >> >> Hopes this helps, >> >> -- daniel >> >> >> >/ >> />/ On 27/03/2018 13:56, Peter Firmstone wrote: >> />>/ Not sure if this is the right place to mention this. >> />>/ >> />>/ Anyone notice that specifying a custom security manager at jvm >> start >> />>/ up causes issues with service providers loading? If using the >> sun >> />>/ PolicyFile implementation, the policy doesn't load due to the >> provider >> />>/ failure, I have a custom policy implementation that will allow >> the jvm >> />>/ to run in this state, and other providers are also not loading, >> such >> />>/ as the logger and JCE. >> />>/ >> />>/ Note that it doesn't occur if the security manager is set >> />>/ programmatically in the main method at start up, only if it's >> set via >> />>/ command line option. >> />>/ >> />>/ Examples of providers not loading: >> />>/ >> />>/ [java] java.lang.NullPointerException >> />>/ [java] Can't load log handler >> "java.util.logging.ConsoleHandler" >> />>/ [java] java.lang.NullPointerException >> />>/ [java] java.lang.NullPointerException >> />>/ [java] at >> />>/ java.util.logging.LogManager$5.run(LogManager.java:965) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ >> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) >> />>/ [java] at >> />>/ >> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) >> />>/ >> />>/ [java] at >> />>/ java.util.logging.LogManager.access$1500(LogManager.java:145) >> />>/ [java] at >> />>/ >> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) >> />>/ >> />>/ [java] at >> java.util.logging.Logger.getHandlers(Logger.java:1777) >> />>/ [java] at java.util.logging.Logger.log(Logger.java:735) >> />>/ [java] at >> java.util.logging.Logger.doLog(Logger.java:765) >> />>/ [java] at java.util.logging.Logger.log(Logger.java:788) >> />>/ [java] at >> />>/ >> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) >> />>/ >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ >> org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) >> />>/ >> />>/ [java] at >> />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> />>/ [java] at >> />>/ >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> />>/ >> />>/ [java] at >> />>/ >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> />>/ >> />>/ [java] at >> />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> />>/ [java] at java.lang.Class.newInstance(Class.java:442) >> />>/ [java] at sun.misc.Launcher.(Launcher.java:93) >> />>/ [java] at sun.misc.Launcher.(Launcher.java:54) >> />>/ [java] at >> />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> />>/ [java] at >> />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> />>/ >> />>/ >> />>/ [java] Error occurred during initialization of VM >> />>/ [java] java.lang.ExceptionInInitializerError >> />>/ [java] at >> />>/ java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> />>/ [java] at >> />>/ java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> />>/ [java] at >> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> />>/ [java] at >> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> />>/ [java] at >> />>/ >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> />>/ [java] at >> />>/ >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.(PolicyFile.java:297) >> />>/ [java] at >> java.security.Policy.getPolicyNoCheck(Policy.java:196) >> />>/ [java] at >> java.security.Policy.getPolicy(Policy.java:154) >> />>/ [java] at >> net.jini.security.Security$7.run(Security.java:1054) >> />>/ [java] at >> net.jini.security.Security$7.run(Security.java:1052) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ net.jini.security.Security.getPolicy(Security.java:1052) >> />>/ [java] at >> />>/ net.jini.security.Security.getContext(Security.java:506) >> />>/ [java] at >> />>/ >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >> />>/ >> />>/ [java] at >> />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> />>/ [java] at >> />>/ >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> />>/ >> />>/ [java] at >> />>/ >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> />>/ >> />>/ [java] at >> />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> />>/ [java] at java.lang.Class.newInstance(Class.java:442) >> />>/ [java] at sun.misc.Launcher.(Launcher.java:93) >> />>/ [java] at sun.misc.Launcher.(Launcher.java:54) >> />>/ [java] at >> />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> />>/ [java] at >> />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> />>/ [java] Caused by: java.lang.NullPointerException >> />>/ [java] at >> />>/ >> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >> />>/ [java] at >> />>/ java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> />>/ [java] at >> />>/ java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> />>/ [java] at >> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> />>/ [java] at >> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> />>/ [java] at >> />>/ >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> />>/ [java] at >> />>/ >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> />>/ [java] at >> />>/ sun.security.provider.PolicyFile.(PolicyFile.java:297) >> />>/ [java] at >> java.security.Policy.getPolicyNoCheck(Policy.java:196) >> />>/ [java] at >> java.security.Policy.getPolicy(Policy.java:154) >> />>/ [java] at >> net.jini.security.Security$7.run(Security.java:1054) >> />>/ [java] at >> net.jini.security.Security$7.run(Security.java:1052) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ net.jini.security.Security.getPolicy(Security.java:1052) >> />>/ [java] at >> />>/ net.jini.security.Security.getContext(Security.java:506) >> />>/ [java] Unexpected exception: >> />>/ [java] at >> />>/ >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >> />>/ >> />>/ [java] at >> />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> />>/ [java] at >> />>/ >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> />>/ >> />>/ [java] at >> />>/ >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> />>/ >> />>/ [java] at >> />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> />>/ [java] at java.lang.Class.newInstance(Class.java:442) >> />>/ [java] at sun.misc.Launcher.(Launcher.java:93) >> />>/ [java] at sun.misc.Launcher.(Launcher.java:54) >> />>/ [java] at >> />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> />>/ [java] at >> />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> />>/ >> />>/ >> />>/ >> />>/ [java] java.lang.ExceptionInInitializerError >> />>/ [java] at >> />>/ >> javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) >> />>/ [java] at >> />>/ javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) >> />>/ [java] at >> />>/ javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) >> />>/ [java] at >> />>/ >> sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) >> />>/ [java] at >> />>/ >> sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) >> />>/ [java] at >> />>/ sun.security.ssl.CipherSuite.(CipherSuite.java:614) >> />>/ [java] at >> />>/ >> sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) >> />>/ >> />>/ [java] at >> />>/ sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) >> />>/ [java] at >> />>/ >> sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) >> />>/ >> />>/ [java] at java.lang.Class.forName0(Native Method) >> />>/ [java] at java.lang.Class.forName(Class.java:264) >> />>/ [java] at >> />>/ java.security.Provider$Service.getImplClass(Provider.java:1634) >> />>/ [java] at >> />>/ java.security.Provider$Service.newInstance(Provider.java:1592) >> />>/ [java] at >> />>/ sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >> />>/ [java] at >> />>/ sun.security.jca.GetInstance.getInstance(GetInstance.java:164) >> />>/ [java] at >> />>/ javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) >> />>/ [java] at >> />>/ >> net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) >> />>/ [java] at >> />>/ >> net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) >> />>/ [java] at >> />>/ >> net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) >> />>/ >> />>/ [java] at >> />>/ >> net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) >> />>/ >> />>/ [java] at >> />>/ >> net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) >> />>/ [java] at >> />>/ net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) >> />>/ [java] at >> />>/ >> net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) >> />>/ [java] at >> />>/ >> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) >> />>/ >> />>/ [java] at >> />>/ >> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) >> />>/ >> />>/ [java] at com.sun.proxy.$Proxy2.registerGroup(Unknown >> Source) >> />>/ [java] at >> />>/ >> org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) >> />>/ >> />>/ [java] at >> />>/ >> org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) >> />>/ >> />>/ [java] at >> />>/ org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) >> />>/ [java] at >> />>/ org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> />>/ javax.security.auth.Subject.doAsPrivileged(Subject.java:483) >> />>/ [java] at >> />>/ >> org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) >> />>/ >> />>/ [java] at >> />>/ org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) >> />>/ [java] Caused by: java.lang.SecurityException: Can not >> initialize >> />>/ cryptographic mechanism >> />>/ [java] at >> javax.crypto.JceSecurity.(JceSecurity.java:93) >> />>/ [java] ... 44 more >> />>/ [java] Caused by: java.lang.SecurityException: Cannot locate >> />>/ policy or framework files! >> />>/ [java] at >> />>/ >> javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) >> />>/ [java] at >> />>/ javax.crypto.JceSecurity.access$000(JceSecurity.java:50) >> />>/ [java] at >> javax.crypto.JceSecurity$1.run(JceSecurity.java:85) >> />>/ [java] at >> java.security.AccessController.doPrivileged(Native >> />>/ Method) >> />>/ [java] at >> javax.crypto.JceSecurity.(JceSecurity.java:82) >> />/ >> / > From sha.jiang at oracle.com Wed Mar 28 06:48:04 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 28 Mar 2018 14:48:04 +0800 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: References: Message-ID: <6fafcd20-f70f-e2f5-7925-5e35c45b5e2c@oracle.com> Hi Jamil, I have a minor point on your tests. -- com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KAT.java ?505???? private static byte[] hex2bin(String hex) { ?506???????? int i; ?507???????? int len = hex.length(); ?508???????? byte[] data = new byte [len / 2]; ?509???????? for (i = 0; i < len; i += 2) { ?510???????????? data[i / 2] = (byte)((Character.digit(hex.charAt(i), 16) << 4) + ?511???????????????????? Character.digit(hex.charAt(i + 1), 16)); ?512???????? } ?513???????? return data; ?514???? } Would you like to move this method to a test lib class, like test/lib/jdk/test/lib/Utils.java? In fact, this class has a method, named toHexString, for converting bin to hex. I think your method will be reused by other tests, including your another test com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20Poly1305ParamTest.java. In addition, you may want to declare the local variable "i" in the initialization expression in the for-loop. Best regards, John Jiang On 27/03/2018 03:08, Jamil Nimeh wrote: > Hello all, > > This is a request for review for the ChaCha20 and ChaCha20-Poly1305 > cipher implementations.? Links to the webrev and the JEP which > outlines the characteristics and behavior of the ciphers are listed > below. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ > http://openjdk.java.net/jeps/329 > > Thanks, > --Jamil > From magnus.ihse.bursie at oracle.com Wed Mar 28 10:31:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 12:31:49 +0200 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> Message-ID: <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com> On 2018-03-28 01:52, Weijun Wang wrote: > >> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth > There is only one function to export and it already has JNIEXPORT, so you can just remove the new $(LIBJAAS_CFLAGS) [1]. Ok, thanks Max! > Are you going to update your webrev? Here is a new webrev. It includes your recommended change in Lib-jdk.security.auth.gmk. It is also updated to keep track of changes in shared native libraries that has happend in the mainline since my first webrev. Most notably is the addition of libjsig. For now, I have just added the JNIEXPORT markers for the platforms that need it. Hopefully we can unify libjsig across all platforms, but that seems to be more complicated than I thought, so that'll have to wait. I have also recieved word from Phil Race that there were no testing issues for client, so he's happy as well. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.03 /Magnus > > Thanks > Max > > [1] http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html From adam.petcher at oracle.com Wed Mar 28 13:59:10 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 28 Mar 2018 09:59:10 -0400 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <6fafcd20-f70f-e2f5-7925-5e35c45b5e2c@oracle.com> References: <6fafcd20-f70f-e2f5-7925-5e35c45b5e2c@oracle.com> Message-ID: <4493d1c1-69d4-cc4f-2d8e-68d703fb1550@oracle.com> On 3/28/2018 2:48 AM, sha.jiang at oracle.com wrote: > Would you like to move this method to a test lib class, like > test/lib/jdk/test/lib/Utils.java? In fact, this class has a method, > named toHexString, for converting bin to hex. This method appears to be the same as Convert.hexStringToByteArray that I added to jdk.test.lib along with the field arithmetic implementation. That code is not incorporated yet, but the Poly1305 code depends on the field arithmetic code, anyway. So adding this dependency may be reasonable. From jamil.j.nimeh at oracle.com Wed Mar 28 16:19:03 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 28 Mar 2018 09:19:03 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <4493d1c1-69d4-cc4f-2d8e-68d703fb1550@oracle.com> References: <6fafcd20-f70f-e2f5-7925-5e35c45b5e2c@oracle.com> <4493d1c1-69d4-cc4f-2d8e-68d703fb1550@oracle.com> Message-ID: I think I could pull in Convert.hexStringToByteArray.? I might try pulling in that test class locally just to make sure things still run before you commit the field arithmetic stuff.? I also noticed I left in some debug routines in ChaCha20Cipher that need to get the axe, so I'll cut those out today. --Jamil On 3/28/2018 6:59 AM, Adam Petcher wrote: > On 3/28/2018 2:48 AM, sha.jiang at oracle.com wrote: > >> Would you like to move this method to a test lib class, like >> test/lib/jdk/test/lib/Utils.java? In fact, this class has a method, >> named toHexString, for converting bin to hex. > > This method appears to be the same as Convert.hexStringToByteArray > that I added to jdk.test.lib along with the field arithmetic > implementation. That code is not incorporated yet, but the Poly1305 > code depends on the field arithmetic code, anyway. So adding this > dependency may be reasonable. From peter.firmstone at zeus.net.au Tue Mar 27 13:15:18 2018 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 27 Mar 2018 23:15:18 +1000 Subject: -Djava.security.manager=problems for service providers In-Reply-To: <1453efcd-4ebd-9942-34b5-fdb480977283@oracle.com> References: <5ABA3F87.50804@zeus.net.au> <1453efcd-4ebd-9942-34b5-fdb480977283@oracle.com> Message-ID: <5ABA43E6.2000207@zeus.net.au> I tested the JDK 9 pre releases and didn't experience issues, will have to test again against the latest. Note on JDK1.8.0_162 it doesn't only affect the PolicyFile provider. Thanks, Peter. On 27/03/2018 11:06 PM, Alan Bateman wrote: > Moving this to security-dev. > > From the stack trace, it looks like you are using JDK 8 or older. > There are several changes in JDK 9 and newer in the PolicyFile code to > how it loads its resources that may help with the issues you are seeing. > > -Alan > > On 27/03/2018 13:56, Peter Firmstone wrote: >> Not sure if this is the right place to mention this. >> >> Anyone notice that specifying a custom security manager at jvm start >> up causes issues with service providers loading? If using the sun >> PolicyFile implementation, the policy doesn't load due to the >> provider failure, I have a custom policy implementation that will >> allow the jvm to run in this state, and other providers are also not >> loading, such as the logger and JCE. >> >> Note that it doesn't occur if the security manager is set >> programmatically in the main method at start up, only if it's set via >> command line option. >> >> Examples of providers not loading: >> >> [java] java.lang.NullPointerException >> [java] Can't load log handler "java.util.logging.ConsoleHandler" >> [java] java.lang.NullPointerException >> [java] java.lang.NullPointerException >> [java] at >> java.util.logging.LogManager$5.run(LogManager.java:965) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) >> [java] at >> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) >> [java] at >> java.util.logging.LogManager.access$1500(LogManager.java:145) >> [java] at >> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) >> [java] at >> java.util.logging.Logger.getHandlers(Logger.java:1777) >> [java] at java.util.logging.Logger.log(Logger.java:735) >> [java] at java.util.logging.Logger.doLog(Logger.java:765) >> [java] at java.util.logging.Logger.log(Logger.java:788) >> [java] at >> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >> [java] at >> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) >> [java] at >> org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) >> [java] at >> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) >> [java] at >> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) >> [java] at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) >> [java] at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) >> [java] at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> [java] at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) >> [java] at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> [java] at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> [java] at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> [java] at >> java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> [java] at java.lang.Class.newInstance(Class.java:442) >> [java] at sun.misc.Launcher.(Launcher.java:93) >> [java] at sun.misc.Launcher.(Launcher.java:54) >> [java] at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> [java] at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> >> >> [java] Error occurred during initialization of VM >> [java] java.lang.ExceptionInInitializerError >> [java] at >> java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> [java] at >> java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> [java] at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> [java] at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> [java] at >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> [java] at >> sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> [java] at >> sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> [java] at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> [java] at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> [java] at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> [java] at >> sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> [java] at >> sun.security.provider.PolicyFile.(PolicyFile.java:297) >> [java] at >> java.security.Policy.getPolicyNoCheck(Policy.java:196) >> [java] at java.security.Policy.getPolicy(Policy.java:154) >> [java] at net.jini.security.Security$7.run(Security.java:1054) >> [java] at net.jini.security.Security$7.run(Security.java:1052) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> net.jini.security.Security.getPolicy(Security.java:1052) >> [java] at >> net.jini.security.Security.getContext(Security.java:506) >> [java] at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >> [java] at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >> [java] at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> [java] at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >> [java] at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> [java] at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> [java] at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> [java] at >> java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> [java] at java.lang.Class.newInstance(Class.java:442) >> [java] at sun.misc.Launcher.(Launcher.java:93) >> [java] at sun.misc.Launcher.(Launcher.java:54) >> [java] at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> [java] at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> [java] Caused by: java.lang.NullPointerException >> [java] at >> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >> [java] at >> java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> [java] at >> java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> [java] at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> [java] at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> [java] at >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> [java] at >> sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> [java] at >> sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> [java] at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> [java] at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> [java] at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> [java] at >> sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> [java] at >> sun.security.provider.PolicyFile.(PolicyFile.java:297) >> [java] at >> java.security.Policy.getPolicyNoCheck(Policy.java:196) >> [java] at java.security.Policy.getPolicy(Policy.java:154) >> [java] at net.jini.security.Security$7.run(Security.java:1054) >> [java] at net.jini.security.Security$7.run(Security.java:1052) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> net.jini.security.Security.getPolicy(Security.java:1052) >> [java] at >> net.jini.security.Security.getContext(Security.java:506) >> [java] Unexpected exception: >> [java] at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >> [java] at >> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >> [java] at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >> [java] at >> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >> [java] at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> [java] at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> [java] at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> [java] at >> java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> [java] at java.lang.Class.newInstance(Class.java:442) >> [java] at sun.misc.Launcher.(Launcher.java:93) >> [java] at sun.misc.Launcher.(Launcher.java:54) >> [java] at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> [java] at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> >> >> >> [java] java.lang.ExceptionInInitializerError >> [java] at >> javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) >> [java] at >> javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) >> [java] at >> javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) >> [java] at >> sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) >> [java] at >> sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) >> [java] at >> sun.security.ssl.CipherSuite.(CipherSuite.java:614) >> [java] at >> sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) >> [java] at >> sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) >> [java] at >> sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) >> [java] at java.lang.Class.forName0(Native Method) >> [java] at java.lang.Class.forName(Class.java:264) >> [java] at >> java.security.Provider$Service.getImplClass(Provider.java:1634) >> [java] at >> java.security.Provider$Service.newInstance(Provider.java:1592) >> [java] at >> sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >> [java] at >> sun.security.jca.GetInstance.getInstance(GetInstance.java:164) >> [java] at >> javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) >> [java] at >> net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) >> [java] at >> net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) >> [java] at >> net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) >> [java] at >> net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) >> [java] at >> net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) >> [java] at >> net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) >> [java] at >> net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) >> [java] at >> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) >> [java] at >> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) >> [java] at com.sun.proxy.$Proxy2.registerGroup(Unknown Source) >> [java] at >> org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) >> [java] at >> org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) >> [java] at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >> [java] at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >> [java] at >> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) >> [java] at >> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) >> [java] at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >> [java] at >> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >> [java] at >> org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) >> [java] at >> org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) >> [java] at >> org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) >> [java] at >> org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) >> [java] at >> org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) >> [java] at >> org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> javax.security.auth.Subject.doAsPrivileged(Subject.java:483) >> [java] at >> org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) >> [java] at >> org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) >> [java] Caused by: java.lang.SecurityException: Can not >> initialize cryptographic mechanism >> [java] at >> javax.crypto.JceSecurity.(JceSecurity.java:93) >> [java] ... 44 more >> [java] Caused by: java.lang.SecurityException: Cannot locate >> policy or framework files! >> [java] at >> javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) >> [java] at >> javax.crypto.JceSecurity.access$000(JceSecurity.java:50) >> [java] at javax.crypto.JceSecurity$1.run(JceSecurity.java:85) >> [java] at java.security.AccessController.doPrivileged(Native >> Method) >> [java] at >> javax.crypto.JceSecurity.(JceSecurity.java:82) > From wagnerrobert at hotmail.com Wed Mar 28 18:46:29 2018 From: wagnerrobert at hotmail.com (R Wagner) Date: Wed, 28 Mar 2018 18:46:29 +0000 Subject: Comment on https://bugs.openjdk.java.net/browse/JDK-8145252 - TLS 1.3 formally adopted by IETF In-Reply-To: References: Message-ID: I was wondering if it was possible to update this issue and make a comment that TLS 1.3 has been formally adopted. See: IETF approves TLS 1.3 Announcement https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html Article https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-internet-standard/ [https://www.bleepstatic.com/content/posts/2018/03/25/TLS13-logo.png] IETF Approves TLS 1.3 as Internet Standard www.bleepingcomputer.com The Internet Engineering Task Force (IETF) ?the organization that approves proposed Internet standards and protocols? has formally approved TLS 1.3 as the next major version of the Transport Layer Security (TLS) protocol. RW -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Wed Mar 28 19:47:46 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 28 Mar 2018 12:47:46 -0700 Subject: Comment on https://bugs.openjdk.java.net/browse/JDK-8145252 - TLS 1.3 formally adopted by IETF In-Reply-To: References: Message-ID: On 3/28/2018 11:46 AM, R Wagner wrote: > I was wondering if it was possible to update this issue and make a > comment that TLS 1.3 has been formally adopted. I just added a quick comment. > See: > > IETF approves TLS 1.3 Just FYI: the TLS 1.3 spec[1] still has a few more steps to go before it is issued as a RFC, but the technical work is "essentially" done and has been approved by the IESG. It's currently in the RFC Editor's[2] Queue[3] for final editing, and there's some IANA work (Section 11) that is still ongoing. (BTW, at 156 pages, it's the longest document currently in the queue! ) The RFC Editor's FAQ says it's typically 1-2 months from this stage to issuance of the RFC, but actual time varies greatly[5]. Brad [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ [2] https://datatracker.ietf.org/help/state/draft/rfceditor [3] https://www.rfc-editor.org/pubprocess/ [4] https://www.rfc-editor.org/current_queue.php?sortkey=6&sorting=ASC [5] https://www.rfc-editor.org/faq/#howlong From sean.mullan at oracle.com Wed Mar 28 19:55:31 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 28 Mar 2018 15:55:31 -0400 Subject: Comment on https://bugs.openjdk.java.net/browse/JDK-8145252 - TLS 1.3 formally adopted by IETF In-Reply-To: References: Message-ID: I also made a similar change to the Risks and Assumptions section of the JEP. --Sean On 3/28/18 3:47 PM, Bradford Wetmore wrote: > > On 3/28/2018 11:46 AM, R Wagner wrote: >> I was wondering if it was possible to update this issue and make a >> comment that TLS 1.3 has been formally adopted. > > I just added a quick comment. > > > See: >> >> IETF approves TLS 1.3 > > Just FYI:? the TLS 1.3 spec[1] still has a few more steps to go before > it is issued as a RFC, but the technical work is "essentially" done and > has been approved by the IESG. > > It's currently in the RFC Editor's[2] Queue[3] for final editing, and > there's some IANA work (Section 11) that is still ongoing.? (BTW, at 156 > pages, it's the longest document currently in the queue! ) > > The RFC Editor's FAQ says it's typically 1-2 months from this stage to > issuance of the RFC, but actual time varies greatly[5]. > > Brad > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ > [2] https://datatracker.ietf.org/help/state/draft/rfceditor > [3] https://www.rfc-editor.org/pubprocess/ > [4] https://www.rfc-editor.org/current_queue.php?sortkey=6&sorting=ASC > [5] https://www.rfc-editor.org/faq/#howlong > > From erik.joelsson at oracle.com Wed Mar 28 20:17:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Mar 2018 13:17:39 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com> Message-ID: Build changes still look good to me. /Erik On 2018-03-28 03:31, Magnus Ihse Bursie wrote: > On 2018-03-28 01:52, Weijun Wang wrote: >> >>> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie >>> wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for >>> jdk.security.auth >> There is only one function to export and it already has JNIEXPORT, so >> you can just remove the new $(LIBJAAS_CFLAGS) [1]. > Ok, thanks Max! >> Are you going to update your webrev? > Here is a new webrev. It includes your recommended change in > Lib-jdk.security.auth.gmk. > > It is also updated to keep track of changes in shared native libraries > that has happend in the mainline since my first webrev. Most notably > is the addition of libjsig. For now, I have just added the JNIEXPORT > markers for the platforms that need it. Hopefully we can unify libjsig > across all platforms, but that seems to be more complicated than I > thought, so that'll have to wait. > > I have also recieved word from Phil Race that there were no testing > issues for client, so he's happy as well. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.03 > > /Magnus > >> >> Thanks >> Max >> >> [1] >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html > From martinrb at google.com Wed Mar 28 21:53:10 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 14:53:10 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: I can't find any documentation for what JNIEXPORT and friends actually do. People including myself have been cargo-culting JNIEXPORT and JNICALL for decades. Why aren't they in the JNI spec? --- It's fishy that the attribute externally_visible (which seems very interesting!) is ARM specific. #ifdef ARM #define JNIEXPORT __attribute__((externally_visible,visibility("default"))) #define JNIIMPORT __attribute__((externally_visible,visibility("default"))) #else #define JNIEXPORT __attribute__((visibility("default"))) #define JNIIMPORT __attribute__((visibility("default"))) #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Mar 28 22:14:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 29 Mar 2018 00:14:13 +0200 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> On 2018-03-28 23:53, Martin Buchholz wrote: > I can't find any documentation for what JNIEXPORT and friends actually do. > People including myself have been cargo-culting JNIEXPORT and JNICALL > for decades. > Why aren't they in the JNI spec? That surprises me. I'm quite certain that javah (or rather, java -h nowadays) generate header files with JNIEXPORT and JNICALL. As you can see in the jni.h and jni_md.h files, JNIEXPORT equals __attribute__((visibility("default"))) for compilers that support it (gcc and friends), and __declspec(dllexport) for Windows. This means, that the symbol should be exported. (And it's ignored if you use mapfiles aka linker scripts.) As for JNICALL, it's empty on most compilers, but evaluates to __stdcall on Windows. This defines the calling convention to use. This is required for JNI calls from Java. (Ask the JVM team why.) While it's not technically required for calling from one dll to another, it's good practice to use it all time to be consistent. In any way, it doesn't hurt us. > > --- > > It's fishy that the attribute externally_visible (which seems very > interesting!) is ARM specific. > > ? #ifdef ARM > ? ? #define JNIEXPORT > ?__attribute__((externally_visible,visibility("default"))) > ? ? #define JNIIMPORT > ?__attribute__((externally_visible,visibility("default"))) Yeah, this is broken on so many levels. :-( The ARM here goes back to the old Oracle proprietary arm32 port. This used lto, link time optimization, to get an absolutely minimal runtime, at expense of a extremely long built time. (I think linking libjvm took like 20 minutes.) But when using lto, you also need to decorate your functions with the externally_visible attribute. So this was added to get hotspot to export the proper symbols (since they, too, used the jni.h file). So, in short, we should: 1) have used a special, local jni.h file for the proprietary arm port, and/or 2) added the externally_visible attribute not based on platform, but on the existence of lto. At this point in time, we're not building the old 32-bit arm port, and I doubt anyone does. And even if so, we could probably remove the lto part, and thus remove this from jni_md.h. If you want, please file a bug. /Magnus > ? #else > ? ? #define JNIEXPORT ?__attribute__((visibility("default"))) > ? ? #define JNIIMPORT ?__attribute__((visibility("default"))) > ? #endif > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu Mar 29 06:16:18 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 23:16:18 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> Message-ID: On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-03-28 23:53, Martin Buchholz wrote: > > I can't find any documentation for what JNIEXPORT and friends actually do. > People including myself have been cargo-culting JNIEXPORT and JNICALL for > decades. > Why aren't they in the JNI spec? > > That surprises me. I'm quite certain that javah (or rather, java -h > nowadays) generate header files with JNIEXPORT and JNICALL. > > As you can see in the jni.h and jni_md.h files, JNIEXPORT equals > __attribute__((visibility("default"))) for compilers that support it (gcc > and friends), and __declspec(dllexport) for Windows. This means, that the > symbol should be exported. (And it's ignored if you use mapfiles aka linker > scripts.) > > As for JNICALL, it's empty on most compilers, but evaluates to __stdcall > on Windows. This defines the calling convention to use. This is required > for JNI calls from Java. (Ask the JVM team why.) While it's not technically > required for calling from one dll to another, it's good practice to use it > all time to be consistent. In any way, it doesn't hurt us. > Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do they *mean?* For example, one might expect from the JNI prefix that these macros are exclusively for use by JNI linking, i.e. unsupported except in the output of javac -h. But of course in practice they are used with arbitrary symbols to communicate between components of user native code, not just to communicate with the JVM. Is that a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini at zeus.net.au Thu Mar 29 08:53:58 2018 From: jini at zeus.net.au (Peter) Date: Thu, 29 Mar 2018 18:53:58 +1000 Subject: -Djava.security.manager=problems for service provider In-Reply-To: <5ABB1828.2030604@zeus.net.au> References: <5ABAF4D0.209@zeus.net.au> <5ABB1828.2030604@zeus.net.au> Message-ID: <5ABCA9A6.9000606@zeus.net.au> Hello Java security people! It turns out we needed the -Djava.security.manager= option at startup after all... According to our SecurityManager implementation notes, the reason it instantiated the policy, was to ensure that the JVM had loaded all necessary classes, to prevent recursive errors. So I worked out we didn't actually need an instance of the policy, but instead, just make sure it's class is loaded along with other important classes, before the security manager is in force. I've also handed off the logging in the policy to an executor... So I've removed the instantation of policy provider from our security manager's constructor. I've actually got a permission check in the constructor of the security manager, if the AccessControlContext is privileged or if an AccessControlContext containing ProtectionDomains are privileged, the policy is never consulted. And so, the policy is not consulted or instantiated during the security managers construction as you can see below. I have a new problem: To state it simply, if you have a custom SecurityManager, you cannot use the built in sun.security.provider.PolicyFile because the class RBClassLoader cannot be initialized, due to a NullPointerException in it's static initializer: [java] Caused by: java.lang.NullPointerException [java] at java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) Which is just a null pointer dereference in RBClassLoaders static initializer block: static { // Find the extension class loader. ClassLoader ld = ClassLoader.getSystemClassLoader(); ClassLoader parent; while ((parent = ld.getParent()) != null) { ld = parent; } loader = ld; } It should be: static { // Find the extension class loader. ClassLoader ld = ClassLoader.getSystemClassLoader(); ClassLoader parent; while (ld != null) { parent = ld.getParent(); if (parent == null) break; ld = parent; } loader = ld; } [java] Error occurred during initialization of VM [java] java.lang.ExceptionInInitializerError [java] at java.util.ResourceBundle.getLoader(ResourceBundle.java:482) [java] at java.util.ResourceBundle.getBundle(ResourceBundle.java:783) [java] at sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) [java] at sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) [java] at java.security.AccessController.doPrivileged(Native Method) [java] at sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) [java] at sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) [java] at sun.security.provider.PolicyFile.init(PolicyFile.java:626) [java] at sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) [java] at sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) [java] at sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) [java] at java.security.AccessController.doPrivileged(Native Method) [java] at sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) [java] at sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) [java] at sun.security.provider.PolicyFile.init(PolicyFile.java:439) [java] at sun.security.provider.PolicyFile.(PolicyFile.java:297) [java] at java.security.Policy.getPolicyNoCheck(Policy.java:196) [java] at java.security.ProtectionDomain.implies(ProtectionDomain.java:285) [java] at java.lang.System$1.run(System.java:316) [java] Unexpected exception: [java] java.io.IOException: The pipe is being closed [java] at java.io.FileOutputStream.writeBytes(Native Method) [java] at java.io.FileOutputStream.write(FileOutputStream.java:326) [java] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) [java] at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126) [java] at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877) [java] at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1786) [java] at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1286) [java] at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1231) [java] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427) [java] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) [java] at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1577) [java] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:351) [java] at org.apache.river.qa.harness.MasterHarness.runTestOtherVM(MasterHarness.java:883) [java] at org.apache.river.qa.harness.MasterHarness.access$200(MasterHarness.java:122) [java] at org.apache.river.qa.harness.MasterHarness$TestRunner.run(MasterHarness.java:616) [java] at org.apache.river.qa.harness.MasterHarness.runTests(MasterHarness.java:443) [java] at org.apache.river.qa.harness.QARunner.main(QARunner.java:67) [java] [java] TIME: 5:52:12 PM [java] [java] at java.security.AccessController.doPrivileged(Native Method) [java] at java.lang.System.setSecurityManager0(System.java:313) [java] at java.lang.System.setSecurityManager(System.java:291) [java] at sun.misc.Launcher.(Launcher.java:101) [java] at sun.misc.Launcher.(Launcher.java:54) [java] at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) [java] at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) [java] Caused by: java.lang.NullPointerException [java] at java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) [java] at java.util.ResourceBundle.getLoader(ResourceBundle.java:482) [java] at java.util.ResourceBundle.getBundle(ResourceBundle.java:783) [java] at sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) [java] at sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) [java] at java.security.AccessController.doPrivileged(Native Method) [java] at sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) [java] at sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) [java] at sun.security.provider.PolicyFile.init(PolicyFile.java:626) [java] at sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) [java] at sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) [java] at sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) [java] at java.security.AccessController.doPrivileged(Native Method) [java] at sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) [java] at sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) [java] at sun.security.provider.PolicyFile.init(PolicyFile.java:439) [java] at sun.security.provider.PolicyFile.(PolicyFile.java:297) [java] at java.security.Policy.getPolicyNoCheck(Policy.java:196) [java] at java.security.ProtectionDomain.implies(ProtectionDomain.java:285) [java] at java.lang.System$1.run(System.java:316) [java] at java.security.AccessController.doPrivileged(Native Method) [java] at java.lang.System.setSecurityManager0(System.java:313) [java] at java.lang.System.setSecurityManager(System.java:291) [java] at sun.misc.Launcher.(Launcher.java:101) [java] at sun.misc.Launcher.(Launcher.java:54) [java] at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) [java] at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) In an earlier version of Java 1.8 RBClassLoader looked like this (it checked for null, so no NPE): /** * A wrapper of ClassLoader.getSystemClassLoader(). */ private static class RBClassLoader extends ClassLoader { private static final RBClassLoader INSTANCE = AccessController.doPrivileged( new PrivilegedAction() { public RBClassLoader run() { return new RBClassLoader(); } }); private static final ClassLoader loader = ClassLoader.getSystemClassLoader(); private RBClassLoader() { } public Class loadClass(String name) throws ClassNotFoundException { if (loader != null) { return loader.loadClass(name); } return Class.forName(name); } public URL getResource(String name) { if (loader != null) { return loader.getResource(name); } return ClassLoader.getSystemResource(name); } public InputStream getResourceAsStream(String name) { if (loader != null) { return loader.getResourceAsStream(name); } return ClassLoader.getSystemResourceAsStream(name); } } In 1.8.0_162 it looks like this, see the null pointer dereference in the static initializer?: /** * A wrapper of Extension Class Loader */ private static class RBClassLoader extends ClassLoader { private static final RBClassLoader INSTANCE = AccessController.doPrivileged( new PrivilegedAction() { public RBClassLoader run() { return new RBClassLoader(); } }); private static final ClassLoader loader; static { // Find the extension class loader. ClassLoader ld = ClassLoader.getSystemClassLoader(); ClassLoader parent; while ((parent = ld.getParent()) != null) { ld = parent; } loader = ld; } private RBClassLoader() { } public Class loadClass(String name) throws ClassNotFoundException { if (loader != null) { return loader.loadClass(name); } return Class.forName(name); } public URL getResource(String name) { if (loader != null) { return loader.getResource(name); } return ClassLoader.getSystemResource(name); } public InputStream getResourceAsStream(String name) { if (loader != null) { return loader.getResourceAsStream(name); } return ClassLoader.getSystemResourceAsStream(name); } } Cheers, Peter. On 28/03/2018 2:20 PM, Peter wrote: > It would be more correct to say, it wasn't noticed until recently. > > The logger was recently added to our policy implementation as a todo > item, previously it went to System.out.err. > > The logger in our security manager, while a static field, has this > comment: > > /** > * Logger is lazily loaded, the SecurityManager can be loaded > prior to > * the system ClassLoader, attempting to load a Logger will cause a > * NullPointerException, when calling > ClassLoader.getSystemClassLoader(), > * in order to load the logger class. > > Unfortunately we can't have the same lazy loading for the policy > provider as all logging is related to parsing policy file syntax > errors, all done prior to construction of the policy. > > We could remove the Logger from the policy, but that makes tracking > down policy syntax errors a problem usually after a period of running, > rather than during start up. > > We also need to ensure all classes the SecurityManager will cause to > be loaded are loaded prior to the security manager constructor > completing. > > For example: > > /* The following ensures the classes we need are loaded early to avoid > * class loading deadlock */ > checkPermission(new RuntimePermission("setIO"), SMPrivilegedContext); > > It seems the best advise is to simply avoid using > -Djava.security.manager in our case. > > Cheers, > > Peter. > > > On 28/03/2018 11:50 AM, Peter wrote: >> Thanks Daniel, >> >> Ah yes, I see what's happening and why this only occurs when using >> -Djava.security.manager= >> >> sun.misc.Launcher calls the security manager constructor from within >> its constructor, which creates a recursive call back to the static >> method Launcher.getLauncher(), which returns the uninitialized static >> launcher field. >> >> CombinerSecurityManager checks during construction that the policy >> has been instantiated and it also instantiates a Logger. It could >> safely lose the logger, but the policy must be fully instantiated >> before the security manager is in force, otherwise it creates >> recursive calls in the security manager implementation. >> >> The simplest fix would be to move the instantiation of >> SecurityManager to a static initializer in Launcher that occurs >> after the construction of Launcher and setting of the static launcher >> field. >> >> This didn't become a problem until recently upgrading to the latest >> Java 8 JDK, so not sure of the history here. >> >> Regards Peter. >> >> More comments inline below: >> >>> Hi, >>> >>> On 27/03/2018 14:06, Alan Bateman wrote: >>> >/ Moving this to security-dev. >>> />/ >>> />/ From the stack trace, it looks like you are using JDK 8 or >>> older. There >>> />/ are several changes in JDK 9 and newer in the PolicyFile code >>> to how it >>> />/ loads its resources that may help with the issues you are seeing. >>> />/ >>> />/ -Alan >>> / >>> [snip] >>> >>> >/ [java] at java.util.logging.Logger.log(Logger.java:788) >>> />/ [java] at >>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >>> / >>> In what logging is concerned, it's probably not a good idea to >>> use java.util.logging in a Policy/SecurityManager implementation >>> supplied on the command line as java.util.logging uses >>> doPrivileged and checks for permissions. >> >> Work arounds for that problem: >> >> * Delegate logging to an executor. >> * Use a thread local variable to detect trusted recursive calls. >> * Only log messages during startup, when the policy or security >> manager isn't active. >> >> >>> For the record the line that throws in the first stack trace >>> seems to be this one at LogManager.java:965 >>> >>> Class clz = >>> ClassLoader.getSystemClassLoader().loadClass(word); >>> >>> The exception is caught and printed on System.err at line 981 >>> allowing the caller to proceed - so it's not what is >>> causing the ExceptionInInitializerError, but it shows that >>> ClassLoader.getSystemClassLoader() is probably returning null >>> at this point, and it looks like it is the same issue you're >>> seeing at ResourceBundle.java:502 later on, which prevents the >>> CombinerSecurityManager to initialize. >>> >>> >>> Hopes this helps, >>> >>> -- daniel >>> >>> >>> >/ >>> />/ On 27/03/2018 13:56, Peter Firmstone wrote: >>> />>/ Not sure if this is the right place to mention this. >>> />>/ >>> />>/ Anyone notice that specifying a custom security manager at jvm >>> start >>> />>/ up causes issues with service providers loading? If using >>> the sun >>> />>/ PolicyFile implementation, the policy doesn't load due to the >>> provider >>> />>/ failure, I have a custom policy implementation that will allow >>> the jvm >>> />>/ to run in this state, and other providers are also not >>> loading, such >>> />>/ as the logger and JCE. >>> />>/ >>> />>/ Note that it doesn't occur if the security manager is set >>> />>/ programmatically in the main method at start up, only if it's >>> set via >>> />>/ command line option. >>> />>/ >>> />>/ Examples of providers not loading: >>> />>/ >>> />>/ [java] java.lang.NullPointerException >>> />>/ [java] Can't load log handler >>> "java.util.logging.ConsoleHandler" >>> />>/ [java] java.lang.NullPointerException >>> />>/ [java] java.lang.NullPointerException >>> />>/ [java] at >>> />>/ java.util.logging.LogManager$5.run(LogManager.java:965) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ >>> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) >>> />>/ [java] at >>> />>/ >>> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) >>> />>/ >>> />>/ [java] at >>> />>/ java.util.logging.LogManager.access$1500(LogManager.java:145) >>> />>/ [java] at >>> />>/ >>> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) >>> />>/ >>> />>/ [java] at >>> java.util.logging.Logger.getHandlers(Logger.java:1777) >>> />>/ [java] at java.util.logging.Logger.log(Logger.java:735) >>> />>/ [java] at >>> java.util.logging.Logger.doLog(Logger.java:765) >>> />>/ [java] at java.util.logging.Logger.log(Logger.java:788) >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) >>> />>/ >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) >>> />>/ >>> />>/ [java] at >>> />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>> />>/ [java] at >>> />>/ >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>> />>/ >>> />>/ [java] at >>> />>/ >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> />>/ >>> />>/ [java] at >>> />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>> />>/ [java] at java.lang.Class.newInstance(Class.java:442) >>> />>/ [java] at sun.misc.Launcher.(Launcher.java:93) >>> />>/ [java] at sun.misc.Launcher.(Launcher.java:54) >>> />>/ [java] at >>> />>/ >>> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>> />>/ [java] at >>> />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>> />>/ >>> />>/ >>> />>/ [java] Error occurred during initialization of VM >>> />>/ [java] java.lang.ExceptionInInitializerError >>> />>/ [java] at >>> />>/ java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >>> />>/ [java] at >>> />>/ java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >>> />>/ [java] at >>> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >>> />>/ [java] at >>> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >>> />>/ [java] at >>> />>/ >>> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:626) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ >>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >>> />>/ [java] at >>> />>/ >>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:439) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.(PolicyFile.java:297) >>> />>/ [java] at >>> java.security.Policy.getPolicyNoCheck(Policy.java:196) >>> />>/ [java] at >>> java.security.Policy.getPolicy(Policy.java:154) >>> />>/ [java] at >>> net.jini.security.Security$7.run(Security.java:1054) >>> />>/ [java] at >>> net.jini.security.Security$7.run(Security.java:1052) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ net.jini.security.Security.getPolicy(Security.java:1052) >>> />>/ [java] at >>> />>/ net.jini.security.Security.getContext(Security.java:506) >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >>> />>/ >>> />>/ [java] at >>> />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>> />>/ [java] at >>> />>/ >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>> />>/ >>> />>/ [java] at >>> />>/ >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> />>/ >>> />>/ [java] at >>> />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>> />>/ [java] at java.lang.Class.newInstance(Class.java:442) >>> />>/ [java] at sun.misc.Launcher.(Launcher.java:93) >>> />>/ [java] at sun.misc.Launcher.(Launcher.java:54) >>> />>/ [java] at >>> />>/ >>> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>> />>/ [java] at >>> />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>> />>/ [java] Caused by: java.lang.NullPointerException >>> />>/ [java] at >>> />>/ >>> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >>> />>/ [java] at >>> />>/ java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >>> />>/ [java] at >>> />>/ java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >>> />>/ [java] at >>> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >>> />>/ [java] at >>> />>/ sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >>> />>/ [java] at >>> />>/ >>> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:626) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ >>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >>> />>/ [java] at >>> />>/ >>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.init(PolicyFile.java:439) >>> />>/ [java] at >>> />>/ sun.security.provider.PolicyFile.(PolicyFile.java:297) >>> />>/ [java] at >>> java.security.Policy.getPolicyNoCheck(Policy.java:196) >>> />>/ [java] at >>> java.security.Policy.getPolicy(Policy.java:154) >>> />>/ [java] at >>> net.jini.security.Security$7.run(Security.java:1054) >>> />>/ [java] at >>> net.jini.security.Security$7.run(Security.java:1052) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ net.jini.security.Security.getPolicy(Security.java:1052) >>> />>/ [java] at >>> />>/ net.jini.security.Security.getContext(Security.java:506) >>> />>/ [java] Unexpected exception: >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >>> />>/ >>> />>/ [java] at >>> />>/ sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>> />>/ [java] at >>> />>/ >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>> />>/ >>> />>/ [java] at >>> />>/ >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> />>/ >>> />>/ [java] at >>> />>/ java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>> />>/ [java] at java.lang.Class.newInstance(Class.java:442) >>> />>/ [java] at sun.misc.Launcher.(Launcher.java:93) >>> />>/ [java] at sun.misc.Launcher.(Launcher.java:54) >>> />>/ [java] at >>> />>/ >>> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>> />>/ [java] at >>> />>/ java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>> />>/ >>> />>/ >>> />>/ >>> />>/ [java] java.lang.ExceptionInInitializerError >>> />>/ [java] at >>> />>/ >>> javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) >>> />>/ [java] at >>> />>/ javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) >>> />>/ [java] at >>> />>/ javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) >>> />>/ [java] at >>> />>/ >>> sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) >>> />>/ [java] at >>> />>/ >>> sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) >>> />>/ [java] at >>> />>/ sun.security.ssl.CipherSuite.(CipherSuite.java:614) >>> />>/ [java] at >>> />>/ >>> sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) >>> />>/ >>> />>/ [java] at >>> />>/ >>> sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) >>> />>/ [java] at >>> />>/ >>> sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) >>> />>/ >>> />>/ [java] at java.lang.Class.forName0(Native Method) >>> />>/ [java] at java.lang.Class.forName(Class.java:264) >>> />>/ [java] at >>> />>/ java.security.Provider$Service.getImplClass(Provider.java:1634) >>> />>/ [java] at >>> />>/ java.security.Provider$Service.newInstance(Provider.java:1592) >>> />>/ [java] at >>> />>/ sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >>> />>/ [java] at >>> />>/ sun.security.jca.GetInstance.getInstance(GetInstance.java:164) >>> />>/ [java] at >>> />>/ javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) >>> >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) >>> />>/ >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) >>> />>/ >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) >>> />>/ [java] at >>> />>/ net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) >>> />>/ >>> />>/ [java] at >>> />>/ >>> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) >>> />>/ >>> />>/ [java] at >>> com.sun.proxy.$Proxy2.registerGroup(Unknown Source) >>> />>/ [java] at >>> />>/ >>> org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) >>> />>/ >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) >>> />>/ [java] at >>> />>/ org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> />>/ javax.security.auth.Subject.doAsPrivileged(Subject.java:483) >>> />>/ [java] at >>> />>/ >>> org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) >>> />>/ >>> />>/ [java] at >>> />>/ org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) >>> />>/ [java] Caused by: java.lang.SecurityException: Can not >>> initialize >>> />>/ cryptographic mechanism >>> />>/ [java] at >>> javax.crypto.JceSecurity.(JceSecurity.java:93) >>> />>/ [java] ... 44 more >>> />>/ [java] Caused by: java.lang.SecurityException: Cannot >>> locate >>> />>/ policy or framework files! >>> />>/ [java] at >>> />>/ >>> javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) >>> >>> />>/ [java] at >>> />>/ javax.crypto.JceSecurity.access$000(JceSecurity.java:50) >>> />>/ [java] at >>> javax.crypto.JceSecurity$1.run(JceSecurity.java:85) >>> />>/ [java] at >>> java.security.AccessController.doPrivileged(Native >>> />>/ Method) >>> />>/ [java] at >>> javax.crypto.JceSecurity.(JceSecurity.java:82) >>> />/ >>> / >> > > From sean.mullan at oracle.com Thu Mar 29 15:00:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Mar 2018 11:00:26 -0400 Subject: RFR 8178370 : [TEST_BUG] java/security/Signature/SignatureLength.java fails In-Reply-To: <8f7f9daa-45fd-b65f-2299-a86a4c40c9a1@oracle.com> References: <8f7f9daa-45fd-b65f-2299-a86a4c40c9a1@oracle.com> Message-ID: <2f1cd444-aa90-698d-bfa1-44b503be3b9c@oracle.com> Looks fine to me. --Sean On 3/23/18 12:58 PM, Ivan Gerasimov wrote: > Ping. > > Can I please have a review for this test fix? > > Thanks in advance! > > Ivan > > > On 3/6/18 1:01 PM, Ivan Gerasimov wrote: >> Hello! >> >> The regression test SignatureLength.java was seen to fail on some >> Solaris systems. >> >> This is because signature verifier from SunPKCS11-Solaris provider >> doesn't always throw SignatureException when the signature is of wrong >> length, but can simply return false to indicate it is invalid. >> >> The test was also modified to try different combinations of providers >> used to create key-pair generator, signer and verifier. >> >> The fixed test passes well on all platforms with JDK 11 and JDK 8u. >> >> Would you please help review it? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8178370 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8178370/00/webrev/ >> >> Thanks in advance! >> > From sean.mullan at oracle.com Thu Mar 29 17:30:15 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Mar 2018 13:30:15 -0400 Subject: -Djava.security.manager=problems for service provider In-Reply-To: <5ABCA9A6.9000606@zeus.net.au> References: <5ABAF4D0.209@zeus.net.au> <5ABB1828.2030604@zeus.net.au> <5ABCA9A6.9000606@zeus.net.au> Message-ID: <455ccd47-317e-74d5-a807-79cbbab38bec@oracle.com> Copying Naoto. Naoto, the regression mentioned below that is causing the NPE looks to be caused by changes to java.util.ResourceBundle in https://bugs.openjdk.java.net/browse/JDK-8182601 Can you take a look and file a bug, if so? Thanks, Sean On 3/29/18 4:53 AM, Peter wrote: > Hello Java security people! > > It turns out we needed the -Djava.security.manager= option at startup > after all... > > According to our SecurityManager implementation notes, the reason it > instantiated the policy, was to ensure that the JVM had loaded all > necessary classes, to prevent recursive errors.? So I worked out we > didn't actually need an instance of the policy, but instead, just make > sure it's class is loaded along with other important classes, before the > security manager is in force.?? I've also handed off the logging in the > policy to an executor... > > So I've removed the instantation of policy provider from our security > manager's constructor. > > I've actually got a permission check in the constructor of the security > manager, if the AccessControlContext is privileged or if an > AccessControlContext containing ProtectionDomains are privileged, the > policy is never consulted.? And so, the policy is not consulted or > instantiated during the security managers construction as you can see > below. > > I have a new problem: > > To state it simply, if you have a custom SecurityManager, you cannot use > the built in sun.security.provider.PolicyFile because the class > RBClassLoader cannot be initialized, due to a NullPointerException in > it's static initializer: > > [java] Caused by: java.lang.NullPointerException > ???? [java]???? at > java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) > > Which is just a null pointer dereference in RBClassLoaders static > initializer block: > > static { > ??????????? // Find the extension class loader. > ??????????? ClassLoader ld = ClassLoader.getSystemClassLoader(); > ??????????? ClassLoader parent; > ??????????? while ((parent = ld.getParent()) != null) { > ??????????????? ld = parent; > ??????????? } > ??????????? loader = ld; > ??????? } > > It should be: > > static { > ??????????? // Find the extension class loader. > ??????????? ClassLoader ld = ClassLoader.getSystemClassLoader(); > ??????????? ClassLoader parent; > ??????????? while (ld != null) { > ??????????????? parent = ld.getParent(); > ??????????????? if (parent == null) break; > ??????????????? ld = parent; > ??????????? } > ??????????? loader = ld; > ??????? } > > ???? [java] Error occurred during initialization of VM > ???? [java] java.lang.ExceptionInInitializerError > ???? [java]???? at > java.util.ResourceBundle.getLoader(ResourceBundle.java:482) > ???? [java]???? at > java.util.ResourceBundle.getBundle(ResourceBundle.java:783) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) > ???? [java]???? at > sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:626) > ???? [java]???? at > sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:439) > ???? [java]???? at > sun.security.provider.PolicyFile.(PolicyFile.java:297) > ???? [java]???? at java.security.Policy.getPolicyNoCheck(Policy.java:196) > ???? [java]???? at > java.security.ProtectionDomain.implies(ProtectionDomain.java:285) > ???? [java]???? at java.lang.System$1.run(System.java:316) > ???? [java] Unexpected exception: > ???? [java] java.io.IOException: The pipe is being closed > ???? [java]???? at java.io.FileOutputStream.writeBytes(Native Method) > ???? [java]???? at > java.io.FileOutputStream.write(FileOutputStream.java:326) > ???? [java]???? at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > ???? [java]???? at > java.io.BufferedOutputStream.write(BufferedOutputStream.java:126) > ???? [java]???? at > java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877) > > ???? [java]???? at > java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1786) > > ???? [java]???? at > java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1286) > ???? [java]???? at > java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1231) > ???? [java]???? at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427) > > ???? [java]???? at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) > ???? [java]???? at > java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1577) > > ???? [java]???? at > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:351) > ???? [java]???? at > org.apache.river.qa.harness.MasterHarness.runTestOtherVM(MasterHarness.java:883) > > ???? [java]???? at > org.apache.river.qa.harness.MasterHarness.access$200(MasterHarness.java:122) > > ???? [java]???? at > org.apache.river.qa.harness.MasterHarness$TestRunner.run(MasterHarness.java:616) > > ???? [java]???? at > org.apache.river.qa.harness.MasterHarness.runTests(MasterHarness.java:443) > ???? [java]???? at > org.apache.river.qa.harness.QARunner.main(QARunner.java:67) > ???? [java] > ???? [java] TIME: 5:52:12 PM > ???? [java] > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at java.lang.System.setSecurityManager0(System.java:313) > ???? [java]???? at java.lang.System.setSecurityManager(System.java:291) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:101) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) > ???? [java]???? at > java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > ???? [java]???? at > java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > ???? [java] Caused by: java.lang.NullPointerException > ???? [java]???? at > java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) > ???? [java]???? at > java.util.ResourceBundle.getLoader(ResourceBundle.java:482) > ???? [java]???? at > java.util.ResourceBundle.getBundle(ResourceBundle.java:783) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) > ???? [java]???? at > sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) > ???? [java]???? at > sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:626) > ???? [java]???? at > sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) > ???? [java]???? at > sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) > ???? [java]???? at > sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) > ???? [java]???? at > sun.security.provider.PolicyFile.init(PolicyFile.java:439) > ???? [java]???? at > sun.security.provider.PolicyFile.(PolicyFile.java:297) > ???? [java]???? at java.security.Policy.getPolicyNoCheck(Policy.java:196) > ???? [java]???? at > java.security.ProtectionDomain.implies(ProtectionDomain.java:285) > ???? [java]???? at java.lang.System$1.run(System.java:316) > ???? [java]???? at java.security.AccessController.doPrivileged(Native > Method) > ???? [java]???? at java.lang.System.setSecurityManager0(System.java:313) > ???? [java]???? at java.lang.System.setSecurityManager(System.java:291) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:101) > ???? [java]???? at sun.misc.Launcher.(Launcher.java:54) > ???? [java]???? at > java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) > ???? [java]???? at > java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) > > > In an earlier version of Java 1.8 RBClassLoader looked like this (it > checked for null, so no NPE): > > ?/** > ???? * A wrapper of ClassLoader.getSystemClassLoader(). > ???? */ > ??? private static class RBClassLoader extends ClassLoader { > ??????? private static final RBClassLoader INSTANCE = > AccessController.doPrivileged( > ??????????????????? new PrivilegedAction() { > ??????????????????????? public RBClassLoader run() { > ??????????????????????????? return new RBClassLoader(); > ??????????????????????? } > ??????????????????? }); > ??????? private static final ClassLoader loader = > ClassLoader.getSystemClassLoader(); > > ??????? private RBClassLoader() { > ??????? } > ??????? public Class loadClass(String name) throws > ClassNotFoundException { > ??????????? if (loader != null) { > ??????????????? return loader.loadClass(name); > ??????????? } > ??????????? return Class.forName(name); > ??????? } > ??????? public URL getResource(String name) { > ??????????? if (loader != null) { > ??????????????? return loader.getResource(name); > ??????????? } > ??????????? return ClassLoader.getSystemResource(name); > ??????? } > ??????? public InputStream getResourceAsStream(String name) { > ??????????? if (loader != null) { > ??????????????? return loader.getResourceAsStream(name); > ??????????? } > ??????????? return ClassLoader.getSystemResourceAsStream(name); > ??????? } > ??? } > > In 1.8.0_162 it looks like this, see the null pointer dereference in the > static initializer?: > > ??? /** > ???? * A wrapper of Extension Class Loader > ???? */ > ??? private static class RBClassLoader extends ClassLoader { > ??????? private static final RBClassLoader INSTANCE = > AccessController.doPrivileged( > ??????????????????? new PrivilegedAction() { > ??????????????????????? public RBClassLoader run() { > ??????????????????????????? return new RBClassLoader(); > ??????????????????????? } > ??????????????????? }); > ??????? private static final ClassLoader loader; > ??????? static { > ??????????? // Find the extension class loader. > ??????????? ClassLoader ld = ClassLoader.getSystemClassLoader(); > ??????????? ClassLoader parent; > ??????????? while ((parent = ld.getParent()) != null) { > ??????????????? ld = parent; > ??????????? } > ??????????? loader = ld; > ??????? } > > ??????? private RBClassLoader() { > ??????? } > ??????? public Class loadClass(String name) throws > ClassNotFoundException { > ??????????? if (loader != null) { > ??????????????? return loader.loadClass(name); > ??????????? } > ??????????? return Class.forName(name); > ??????? } > ??????? public URL getResource(String name) { > ??????????? if (loader != null) { > ??????????????? return loader.getResource(name); > ??????????? } > ??????????? return ClassLoader.getSystemResource(name); > ??????? } > ??????? public InputStream getResourceAsStream(String name) { > ??????????? if (loader != null) { > ??????????????? return loader.getResourceAsStream(name); > ??????????? } > ??????????? return ClassLoader.getSystemResourceAsStream(name); > ??????? } > ??? } > > Cheers, > > Peter. > > On 28/03/2018 2:20 PM, Peter wrote: >> It would be more correct to say, it wasn't noticed until recently. >> >> The logger was recently added to our policy implementation as a todo >> item, previously it went to System.out.err. >> >> The logger in our security manager, while a static field, has this >> comment: >> >> /** >> ???? * Logger is lazily loaded, the SecurityManager can be loaded >> prior to >> ???? * the system ClassLoader, attempting to load a Logger will cause a >> ???? * NullPointerException, when calling >> ClassLoader.getSystemClassLoader(), >> ???? * in order to load the logger class. >> >> Unfortunately we can't have the same lazy loading for the policy >> provider as all logging is related to parsing policy file syntax >> errors, all done prior to construction of the policy. >> >> We could remove the Logger from the policy, but that makes tracking >> down policy syntax errors a problem usually after a period of running, >> rather than during start up. >> >> We also need to ensure all classes the SecurityManager will cause to >> be loaded are loaded prior to the security manager constructor >> completing. >> >> For example: >> >> /* The following ensures the classes we need are loaded early to avoid >> ???? * class loading deadlock */ >> ??? checkPermission(new RuntimePermission("setIO"), SMPrivilegedContext); >> >> It seems the best advise is to simply avoid using >> -Djava.security.manager in our case. >> >> Cheers, >> >> Peter. >> >> >> On 28/03/2018 11:50 AM, Peter wrote: >>> Thanks Daniel, >>> >>> Ah yes, I see what's happening and why this only occurs when using >>> -Djava.security.manager= >>> >>> sun.misc.Launcher calls the security manager constructor from within >>> its constructor, which creates a recursive call back to the static >>> method Launcher.getLauncher(), which returns the uninitialized static >>> launcher field. >>> >>> CombinerSecurityManager checks during construction that the policy >>> has been instantiated and it also instantiates a Logger.? It could >>> safely lose the logger, but the policy must be fully instantiated >>> before the security manager is in force, otherwise it creates >>> recursive calls in the security manager implementation. >>> >>> The simplest fix would be to move the instantiation of >>> SecurityManager to? a static initializer in Launcher that occurs >>> after the construction of Launcher and setting of the static launcher >>> field. >>> >>> This didn't become a problem until recently upgrading to the latest >>> Java 8 JDK, so not sure of the history here. >>> >>> Regards Peter. >>> >>> More comments inline below: >>> >>>> Hi, >>>> >>>> On 27/03/2018 14:06, Alan Bateman wrote: >>>> >/? Moving this to security-dev. >>>> />/ >>>> />/??? From the stack trace, it looks like you are using JDK 8 or >>>> older. There >>>> />/? are several changes in JDK 9 and newer in the PolicyFile code >>>> to how it >>>> />/? loads its resources that may help with the issues you are seeing. >>>> />/ >>>> />/? -Alan >>>> / >>>> [snip] >>>> >>>> >/?????? [java]???? at java.util.logging.Logger.log(Logger.java:788) >>>> />/?????? [java]???? at >>>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >>>> >>>> / >>>> In what logging is concerned, it's probably not a good idea to >>>> use java.util.logging in a Policy/SecurityManager implementation >>>> supplied on the command line as java.util.logging uses >>>> doPrivileged and checks for permissions. >>> >>> Work arounds for that problem: >>> >>> ?? * Delegate logging to an executor. >>> ?? * Use a thread local variable to detect trusted recursive calls. >>> ?? * Only log messages during startup, when the policy or security >>> ???? manager isn't active. >>> >>> >>>> For the record the line that throws in the first stack trace >>>> seems to be this one at LogManager.java:965 >>>> >>>> ????? Class? clz = >>>> ClassLoader.getSystemClassLoader().loadClass(word); >>>> >>>> The exception is caught and printed on System.err at line 981 >>>> allowing the caller to proceed - so it's not what is >>>> causing the ExceptionInInitializerError, but it shows that >>>> ClassLoader.getSystemClassLoader() is probably returning null >>>> at this point, and it looks like it is the same issue you're >>>> seeing at ResourceBundle.java:502 later on, which prevents the >>>> CombinerSecurityManager to initialize. >>>> >>>> >>>> Hopes this helps, >>>> >>>> -- daniel >>>> >>>> >>>> >/ >>>> />/? On 27/03/2018 13:56, Peter Firmstone wrote: >>>> />>/? Not sure if this is the right place to mention this. >>>> />>/ >>>> />>/? Anyone notice that specifying a custom security manager at jvm >>>> start >>>> />>/? up causes issues with service providers loading??? If using >>>> the sun >>>> />>/? PolicyFile implementation, the policy doesn't load due to the >>>> provider >>>> />>/? failure, I have a custom policy implementation that will allow >>>> the jvm >>>> />>/? to run in this state, and other providers are also not >>>> loading, such >>>> />>/? as the logger and JCE. >>>> />>/ >>>> />>/? Note that it doesn't occur if the security manager is set >>>> />>/? programmatically in the main method at start up, only if it's >>>> set via >>>> />>/? command line option. >>>> />>/ >>>> />>/? Examples of providers not loading: >>>> />>/ >>>> />>/??????? [java] java.lang.NullPointerException >>>> />>/??????? [java] Can't load log handler >>>> "java.util.logging.ConsoleHandler" >>>> />>/??????? [java] java.lang.NullPointerException >>>> />>/??????? [java] java.lang.NullPointerException >>>> />>/??????? [java]???? at >>>> />>/? java.util.logging.LogManager$5.run(LogManager.java:965) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/ >>>> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) >>>> />>/??????? [java]???? at >>>> />>/ >>>> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? java.util.logging.LogManager.access$1500(LogManager.java:145) >>>> />>/??????? [java]???? at >>>> />>/ >>>> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> java.util.logging.Logger.getHandlers(Logger.java:1777) >>>> />>/??????? [java]???? at java.util.logging.Logger.log(Logger.java:735) >>>> />>/??????? [java]???? at >>>> java.util.logging.Logger.doLog(Logger.java:765) >>>> />>/??????? [java]???? at java.util.logging.Logger.log(Logger.java:788) >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>> Method) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>> />>/??????? [java]???? at java.lang.Class.newInstance(Class.java:442) >>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:93) >>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >>>> />>/??????? [java]???? at >>>> />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>>> />>/??????? [java]???? at >>>> />>/? java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>>> />>/ >>>> />>/ >>>> />>/??????? [java] Error occurred during initialization of VM >>>> />>/??????? [java] java.lang.ExceptionInInitializerError >>>> />>/??????? [java]???? at >>>> />>/? java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >>>> />>/??????? [java]???? at >>>> />>/? java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:626) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:439) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.(PolicyFile.java:297) >>>> />>/??????? [java]???? at >>>> java.security.Policy.getPolicyNoCheck(Policy.java:196) >>>> />>/??????? [java]???? at >>>> java.security.Policy.getPolicy(Policy.java:154) >>>> />>/??????? [java]???? at >>>> net.jini.security.Security$7.run(Security.java:1054) >>>> />>/??????? [java]???? at >>>> net.jini.security.Security$7.run(Security.java:1052) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/? net.jini.security.Security.getPolicy(Security.java:1052) >>>> />>/??????? [java]???? at >>>> />>/? net.jini.security.Security.getContext(Security.java:506) >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>> Method) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>> />>/??????? [java]???? at java.lang.Class.newInstance(Class.java:442) >>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:93) >>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >>>> />>/??????? [java]???? at >>>> />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>>> />>/??????? [java]???? at >>>> />>/? java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>>> />>/??????? [java] Caused by: java.lang.NullPointerException >>>> />>/??????? [java]???? at >>>> />>/ >>>> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >>>> >>>> />>/??????? [java]???? at >>>> />>/? java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >>>> />>/??????? [java]???? at >>>> />>/? java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:626) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:439) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.provider.PolicyFile.(PolicyFile.java:297) >>>> />>/??????? [java]???? at >>>> java.security.Policy.getPolicyNoCheck(Policy.java:196) >>>> />>/??????? [java]???? at >>>> java.security.Policy.getPolicy(Policy.java:154) >>>> />>/??????? [java]???? at >>>> net.jini.security.Security$7.run(Security.java:1054) >>>> />>/??????? [java]???? at >>>> net.jini.security.Security$7.run(Security.java:1052) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/? net.jini.security.Security.getPolicy(Security.java:1052) >>>> />>/??????? [java]???? at >>>> />>/? net.jini.security.Security.getContext(Security.java:506) >>>> />>/??????? [java] Unexpected exception: >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>> Method) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>> />>/??????? [java]???? at java.lang.Class.newInstance(Class.java:442) >>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:93) >>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >>>> />>/??????? [java]???? at >>>> />>/ java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>>> />>/??????? [java]???? at >>>> />>/? java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>>> />>/ >>>> />>/ >>>> />>/ >>>> />>/??????? [java] java.lang.ExceptionInInitializerError >>>> />>/??????? [java]???? at >>>> />>/ >>>> javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) >>>> />>/??????? [java]???? at >>>> />>/? javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) >>>> />>/??????? [java]???? at >>>> />>/? javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) >>>> >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.ssl.CipherSuite.(CipherSuite.java:614) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) >>>> />>/??????? [java]???? at >>>> />>/ >>>> sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) >>>> >>>> />>/ >>>> />>/??????? [java]???? at java.lang.Class.forName0(Native Method) >>>> />>/??????? [java]???? at java.lang.Class.forName(Class.java:264) >>>> />>/??????? [java]???? at >>>> />>/? java.security.Provider$Service.getImplClass(Provider.java:1634) >>>> />>/??????? [java]???? at >>>> />>/? java.security.Provider$Service.newInstance(Provider.java:1592) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >>>> />>/??????? [java]???? at >>>> />>/? sun.security.jca.GetInstance.getInstance(GetInstance.java:164) >>>> />>/??????? [java]???? at >>>> />>/? javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) >>>> >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) >>>> />>/??????? [java]???? at >>>> />>/? net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> com.sun.proxy.$Proxy2.registerGroup(Unknown Source) >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/ org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) >>>> />>/??????? [java]???? at >>>> />>/? org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> />>/? javax.security.auth.Subject.doAsPrivileged(Subject.java:483) >>>> />>/??????? [java]???? at >>>> />>/ >>>> org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) >>>> >>>> />>/ >>>> />>/??????? [java]???? at >>>> />>/? org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) >>>> />>/??????? [java] Caused by: java.lang.SecurityException: Can not >>>> initialize >>>> />>/? cryptographic mechanism >>>> />>/??????? [java]???? at >>>> javax.crypto.JceSecurity.(JceSecurity.java:93) >>>> />>/??????? [java]???? ... 44 more >>>> />>/??????? [java] Caused by: java.lang.SecurityException: Cannot >>>> locate >>>> />>/? policy or framework files! >>>> />>/??????? [java]???? at >>>> />>/ >>>> javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) >>>> >>>> />>/??????? [java]???? at >>>> />>/? javax.crypto.JceSecurity.access$000(JceSecurity.java:50) >>>> />>/??????? [java]???? at >>>> javax.crypto.JceSecurity$1.run(JceSecurity.java:85) >>>> />>/??????? [java]???? at >>>> java.security.AccessController.doPrivileged(Native >>>> />>/? Method) >>>> />>/??????? [java]???? at >>>> javax.crypto.JceSecurity.(JceSecurity.java:82) >>>> />/ >>>> / >>> >> >> > From naoto.sato at oracle.com Thu Mar 29 18:02:41 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 29 Mar 2018 11:02:41 -0700 Subject: -Djava.security.manager=problems for service provider In-Reply-To: <455ccd47-317e-74d5-a807-79cbbab38bec@oracle.com> References: <5ABAF4D0.209@zeus.net.au> <5ABB1828.2030604@zeus.net.au> <5ABCA9A6.9000606@zeus.net.au> <455ccd47-317e-74d5-a807-79cbbab38bec@oracle.com> Message-ID: <339a6735-bcbc-1e6b-9720-4fbf4c95d666@oracle.com> Hi Peter/Sean, It does seem a regression. Thanks for letting me know. I will file an issue and work on it. Naoto On 3/29/18 10:30 AM, Sean Mullan wrote: > Copying Naoto. > > Naoto, the regression mentioned below that is causing the NPE looks to > be caused by changes to java.util.ResourceBundle in > https://bugs.openjdk.java.net/browse/JDK-8182601 > > Can you take a look and file a bug, if so? > > Thanks, > Sean > > On 3/29/18 4:53 AM, Peter wrote: >> Hello Java security people! >> >> It turns out we needed the -Djava.security.manager= option at startup >> after all... >> >> According to our SecurityManager implementation notes, the reason it >> instantiated the policy, was to ensure that the JVM had loaded all >> necessary classes, to prevent recursive errors.? So I worked out we >> didn't actually need an instance of the policy, but instead, just make >> sure it's class is loaded along with other important classes, before >> the security manager is in force.?? I've also handed off the logging >> in the policy to an executor... >> >> So I've removed the instantation of policy provider from our security >> manager's constructor. >> >> I've actually got a permission check in the constructor of the >> security manager, if the AccessControlContext is privileged or if an >> AccessControlContext containing ProtectionDomains are privileged, the >> policy is never consulted.? And so, the policy is not consulted or >> instantiated during the security managers construction as you can see >> below. >> >> I have a new problem: >> >> To state it simply, if you have a custom SecurityManager, you cannot >> use the built in sun.security.provider.PolicyFile because the class >> RBClassLoader cannot be initialized, due to a NullPointerException in >> it's static initializer: >> >> [java] Caused by: java.lang.NullPointerException >> ????? [java]???? at >> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >> >> Which is just a null pointer dereference in RBClassLoaders static >> initializer block: >> >> static { >> ???????????? // Find the extension class loader. >> ???????????? ClassLoader ld = ClassLoader.getSystemClassLoader(); >> ???????????? ClassLoader parent; >> ???????????? while ((parent = ld.getParent()) != null) { >> ???????????????? ld = parent; >> ???????????? } >> ???????????? loader = ld; >> ???????? } >> >> It should be: >> >> static { >> ???????????? // Find the extension class loader. >> ???????????? ClassLoader ld = ClassLoader.getSystemClassLoader(); >> ???????????? ClassLoader parent; >> ???????????? while (ld != null) { >> ???????????????? parent = ld.getParent(); >> ???????????????? if (parent == null) break; >> ???????????????? ld = parent; >> ???????????? } >> ???????????? loader = ld; >> ???????? } >> >> ????? [java] Error occurred during initialization of VM >> ????? [java] java.lang.ExceptionInInitializerError >> ????? [java]???? at >> java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> ????? [java]???? at >> java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> ????? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> ????? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> ????? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ????? [java]???? at >> sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> ????? [java]???? at >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> ????? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> ????? [java]???? at >> sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> ????? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> ????? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> ????? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ????? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> ????? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> ????? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> ????? [java]???? at >> sun.security.provider.PolicyFile.(PolicyFile.java:297) >> ????? [java]???? at >> java.security.Policy.getPolicyNoCheck(Policy.java:196) >> ????? [java]???? at >> java.security.ProtectionDomain.implies(ProtectionDomain.java:285) >> ????? [java]???? at java.lang.System$1.run(System.java:316) >> ????? [java] Unexpected exception: >> ????? [java] java.io.IOException: The pipe is being closed >> ????? [java]???? at java.io.FileOutputStream.writeBytes(Native Method) >> ????? [java]???? at >> java.io.FileOutputStream.write(FileOutputStream.java:326) >> ????? [java]???? at >> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >> ????? [java]???? at >> java.io.BufferedOutputStream.write(BufferedOutputStream.java:126) >> ????? [java]???? at >> java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877) >> >> ????? [java]???? at >> java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1786) >> >> ????? [java]???? at >> java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1286) >> >> ????? [java]???? at >> java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1231) >> ????? [java]???? at >> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427) >> >> ????? [java]???? at >> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) >> ????? [java]???? at >> java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1577) >> >> ????? [java]???? at >> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:351) >> ????? [java]???? at >> org.apache.river.qa.harness.MasterHarness.runTestOtherVM(MasterHarness.java:883) >> >> ????? [java]???? at >> org.apache.river.qa.harness.MasterHarness.access$200(MasterHarness.java:122) >> >> ????? [java]???? at >> org.apache.river.qa.harness.MasterHarness$TestRunner.run(MasterHarness.java:616) >> >> ????? [java]???? at >> org.apache.river.qa.harness.MasterHarness.runTests(MasterHarness.java:443) >> >> ????? [java]???? at >> org.apache.river.qa.harness.QARunner.main(QARunner.java:67) >> ????? [java] >> ????? [java] TIME: 5:52:12 PM >> ????? [java] >> ????? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ????? [java]???? at java.lang.System.setSecurityManager0(System.java:313) >> ????? [java]???? at java.lang.System.setSecurityManager(System.java:291) >> ????? [java]???? at sun.misc.Launcher.(Launcher.java:101) >> ????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >> ????? [java]???? at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> ????? [java]???? at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> ????? [java] Caused by: java.lang.NullPointerException >> ????? [java]???? at >> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >> ????? [java]???? at >> java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >> ????? [java]???? at >> java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >> ????? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >> ????? [java]???? at >> sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >> ????? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ????? [java]???? at >> sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >> ????? [java]???? at >> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >> ????? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:626) >> ????? [java]???? at >> sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >> ????? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >> ????? [java]???? at >> sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >> ????? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ????? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >> ????? [java]???? at >> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >> ????? [java]???? at >> sun.security.provider.PolicyFile.init(PolicyFile.java:439) >> ????? [java]???? at >> sun.security.provider.PolicyFile.(PolicyFile.java:297) >> ????? [java]???? at >> java.security.Policy.getPolicyNoCheck(Policy.java:196) >> ????? [java]???? at >> java.security.ProtectionDomain.implies(ProtectionDomain.java:285) >> ????? [java]???? at java.lang.System$1.run(System.java:316) >> ????? [java]???? at java.security.AccessController.doPrivileged(Native >> Method) >> ????? [java]???? at java.lang.System.setSecurityManager0(System.java:313) >> ????? [java]???? at java.lang.System.setSecurityManager(System.java:291) >> ????? [java]???? at sun.misc.Launcher.(Launcher.java:101) >> ????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >> ????? [java]???? at >> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >> ????? [java]???? at >> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >> >> >> In an earlier version of Java 1.8 RBClassLoader looked like this (it >> checked for null, so no NPE): >> >> ??/** >> ????? * A wrapper of ClassLoader.getSystemClassLoader(). >> ????? */ >> ???? private static class RBClassLoader extends ClassLoader { >> ???????? private static final RBClassLoader INSTANCE = >> AccessController.doPrivileged( >> ???????????????????? new PrivilegedAction() { >> ???????????????????????? public RBClassLoader run() { >> ???????????????????????????? return new RBClassLoader(); >> ???????????????????????? } >> ???????????????????? }); >> ???????? private static final ClassLoader loader = >> ClassLoader.getSystemClassLoader(); >> >> ???????? private RBClassLoader() { >> ???????? } >> ???????? public Class loadClass(String name) throws >> ClassNotFoundException { >> ???????????? if (loader != null) { >> ???????????????? return loader.loadClass(name); >> ???????????? } >> ???????????? return Class.forName(name); >> ???????? } >> ???????? public URL getResource(String name) { >> ???????????? if (loader != null) { >> ???????????????? return loader.getResource(name); >> ???????????? } >> ???????????? return ClassLoader.getSystemResource(name); >> ???????? } >> ???????? public InputStream getResourceAsStream(String name) { >> ???????????? if (loader != null) { >> ???????????????? return loader.getResourceAsStream(name); >> ???????????? } >> ???????????? return ClassLoader.getSystemResourceAsStream(name); >> ???????? } >> ???? } >> >> In 1.8.0_162 it looks like this, see the null pointer dereference in >> the static initializer?: >> >> ???? /** >> ????? * A wrapper of Extension Class Loader >> ????? */ >> ???? private static class RBClassLoader extends ClassLoader { >> ???????? private static final RBClassLoader INSTANCE = >> AccessController.doPrivileged( >> ???????????????????? new PrivilegedAction() { >> ???????????????????????? public RBClassLoader run() { >> ???????????????????????????? return new RBClassLoader(); >> ???????????????????????? } >> ???????????????????? }); >> ???????? private static final ClassLoader loader; >> ???????? static { >> ???????????? // Find the extension class loader. >> ???????????? ClassLoader ld = ClassLoader.getSystemClassLoader(); >> ???????????? ClassLoader parent; >> ???????????? while ((parent = ld.getParent()) != null) { >> ???????????????? ld = parent; >> ???????????? } >> ???????????? loader = ld; >> ???????? } >> >> ???????? private RBClassLoader() { >> ???????? } >> ???????? public Class loadClass(String name) throws >> ClassNotFoundException { >> ???????????? if (loader != null) { >> ???????????????? return loader.loadClass(name); >> ???????????? } >> ???????????? return Class.forName(name); >> ???????? } >> ???????? public URL getResource(String name) { >> ???????????? if (loader != null) { >> ???????????????? return loader.getResource(name); >> ???????????? } >> ???????????? return ClassLoader.getSystemResource(name); >> ???????? } >> ???????? public InputStream getResourceAsStream(String name) { >> ???????????? if (loader != null) { >> ???????????????? return loader.getResourceAsStream(name); >> ???????????? } >> ???????????? return ClassLoader.getSystemResourceAsStream(name); >> ???????? } >> ???? } >> >> Cheers, >> >> Peter. >> >> On 28/03/2018 2:20 PM, Peter wrote: >>> It would be more correct to say, it wasn't noticed until recently. >>> >>> The logger was recently added to our policy implementation as a todo >>> item, previously it went to System.out.err. >>> >>> The logger in our security manager, while a static field, has this >>> comment: >>> >>> /** >>> ???? * Logger is lazily loaded, the SecurityManager can be loaded >>> prior to >>> ???? * the system ClassLoader, attempting to load a Logger will cause a >>> ???? * NullPointerException, when calling >>> ClassLoader.getSystemClassLoader(), >>> ???? * in order to load the logger class. >>> >>> Unfortunately we can't have the same lazy loading for the policy >>> provider as all logging is related to parsing policy file syntax >>> errors, all done prior to construction of the policy. >>> >>> We could remove the Logger from the policy, but that makes tracking >>> down policy syntax errors a problem usually after a period of >>> running, rather than during start up. >>> >>> We also need to ensure all classes the SecurityManager will cause to >>> be loaded are loaded prior to the security manager constructor >>> completing. >>> >>> For example: >>> >>> /* The following ensures the classes we need are loaded early to avoid >>> ???? * class loading deadlock */ >>> ??? checkPermission(new RuntimePermission("setIO"), >>> SMPrivilegedContext); >>> >>> It seems the best advise is to simply avoid using >>> -Djava.security.manager in our case. >>> >>> Cheers, >>> >>> Peter. >>> >>> >>> On 28/03/2018 11:50 AM, Peter wrote: >>>> Thanks Daniel, >>>> >>>> Ah yes, I see what's happening and why this only occurs when using >>>> -Djava.security.manager= >>>> >>>> sun.misc.Launcher calls the security manager constructor from within >>>> its constructor, which creates a recursive call back to the static >>>> method Launcher.getLauncher(), which returns the uninitialized >>>> static launcher field. >>>> >>>> CombinerSecurityManager checks during construction that the policy >>>> has been instantiated and it also instantiates a Logger.? It could >>>> safely lose the logger, but the policy must be fully instantiated >>>> before the security manager is in force, otherwise it creates >>>> recursive calls in the security manager implementation. >>>> >>>> The simplest fix would be to move the instantiation of >>>> SecurityManager to? a static initializer in Launcher that occurs >>>> after the construction of Launcher and setting of the static >>>> launcher field. >>>> >>>> This didn't become a problem until recently upgrading to the latest >>>> Java 8 JDK, so not sure of the history here. >>>> >>>> Regards Peter. >>>> >>>> More comments inline below: >>>> >>>>> Hi, >>>>> >>>>> On 27/03/2018 14:06, Alan Bateman wrote: >>>>> >/? Moving this to security-dev. >>>>> />/ >>>>> />/??? From the stack trace, it looks like you are using JDK 8 or >>>>> older. There >>>>> />/? are several changes in JDK 9 and newer in the PolicyFile code >>>>> to how it >>>>> />/? loads its resources that may help with the issues you are seeing. >>>>> />/ >>>>> />/? -Alan >>>>> / >>>>> [snip] >>>>> >>>>> >/?????? [java]???? at java.util.logging.Logger.log(Logger.java:788) >>>>> />/?????? [java]???? at >>>>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >>>>> >>>>> / >>>>> In what logging is concerned, it's probably not a good idea to >>>>> use java.util.logging in a Policy/SecurityManager implementation >>>>> supplied on the command line as java.util.logging uses >>>>> doPrivileged and checks for permissions. >>>> >>>> Work arounds for that problem: >>>> >>>> ?? * Delegate logging to an executor. >>>> ?? * Use a thread local variable to detect trusted recursive calls. >>>> ?? * Only log messages during startup, when the policy or security >>>> ???? manager isn't active. >>>> >>>> >>>>> For the record the line that throws in the first stack trace >>>>> seems to be this one at LogManager.java:965 >>>>> >>>>> ????? Class? clz = >>>>> ClassLoader.getSystemClassLoader().loadClass(word); >>>>> >>>>> The exception is caught and printed on System.err at line 981 >>>>> allowing the caller to proceed - so it's not what is >>>>> causing the ExceptionInInitializerError, but it shows that >>>>> ClassLoader.getSystemClassLoader() is probably returning null >>>>> at this point, and it looks like it is the same issue you're >>>>> seeing at ResourceBundle.java:502 later on, which prevents the >>>>> CombinerSecurityManager to initialize. >>>>> >>>>> >>>>> Hopes this helps, >>>>> >>>>> -- daniel >>>>> >>>>> >>>>> >/ >>>>> />/? On 27/03/2018 13:56, Peter Firmstone wrote: >>>>> />>/? Not sure if this is the right place to mention this. >>>>> />>/ >>>>> />>/? Anyone notice that specifying a custom security manager at >>>>> jvm start >>>>> />>/? up causes issues with service providers loading??? If using >>>>> the sun >>>>> />>/? PolicyFile implementation, the policy doesn't load due to the >>>>> provider >>>>> />>/? failure, I have a custom policy implementation that will >>>>> allow the jvm >>>>> />>/? to run in this state, and other providers are also not >>>>> loading, such >>>>> />>/? as the logger and JCE. >>>>> />>/ >>>>> />>/? Note that it doesn't occur if the security manager is set >>>>> />>/? programmatically in the main method at start up, only if it's >>>>> set via >>>>> />>/? command line option. >>>>> />>/ >>>>> />>/? Examples of providers not loading: >>>>> />>/ >>>>> />>/??????? [java] java.lang.NullPointerException >>>>> />>/??????? [java] Can't load log handler >>>>> "java.util.logging.ConsoleHandler" >>>>> />>/??????? [java] java.lang.NullPointerException >>>>> />>/??????? [java] java.lang.NullPointerException >>>>> />>/??????? [java]???? at >>>>> />>/? java.util.logging.LogManager$5.run(LogManager.java:965) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? java.util.logging.LogManager.access$1500(LogManager.java:145) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> java.util.logging.Logger.getHandlers(Logger.java:1777) >>>>> />>/??????? [java]???? at >>>>> java.util.logging.Logger.log(Logger.java:735) >>>>> />>/??????? [java]???? at >>>>> java.util.logging.Logger.doLog(Logger.java:765) >>>>> />>/??????? [java]???? at >>>>> java.util.logging.Logger.log(Logger.java:788) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:496) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.ConcurrentPolicyFile$2.run(ConcurrentPolicyFile.java:469) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.ConcurrentPolicyFile.readPoliciesNoCheckGuard(ConcurrentPolicyFile.java:468) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.ConcurrentPolicyFile.readPolicyPermissionGrants(ConcurrentPolicyFile.java:243) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:253) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.ConcurrentPolicyFile.(ConcurrentPolicyFile.java:226) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:154) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:133) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:162) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>> Method) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>>> />>/??????? [java]???? at java.lang.Class.newInstance(Class.java:442) >>>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:93) >>>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>>>> />>/ >>>>> />>/ >>>>> />>/??????? [java] Error occurred during initialization of VM >>>>> />>/??????? [java] java.lang.ExceptionInInitializerError >>>>> />>/??????? [java]???? at >>>>> />>/? java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >>>>> />>/??????? [java]???? at >>>>> />>/? java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:626) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:439) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.(PolicyFile.java:297) >>>>> />>/??????? [java]???? at >>>>> java.security.Policy.getPolicyNoCheck(Policy.java:196) >>>>> />>/??????? [java]???? at >>>>> java.security.Policy.getPolicy(Policy.java:154) >>>>> />>/??????? [java]???? at >>>>> net.jini.security.Security$7.run(Security.java:1054) >>>>> />>/??????? [java]???? at >>>>> net.jini.security.Security$7.run(Security.java:1052) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/? net.jini.security.Security.getPolicy(Security.java:1052) >>>>> />>/??????? [java]???? at >>>>> />>/? net.jini.security.Security.getContext(Security.java:506) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>> Method) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>>> />>/??????? [java]???? at java.lang.Class.newInstance(Class.java:442) >>>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:93) >>>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>>>> />>/??????? [java] Caused by: java.lang.NullPointerException >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502) >>>>> >>>>> />>/??????? [java]???? at >>>>> />>/? java.util.ResourceBundle.getLoader(ResourceBundle.java:482) >>>>> />>/??????? [java]???? at >>>>> />>/? java.util.ResourceBundle.getBundle(ResourceBundle.java:783) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:626) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.access$400(PolicyFile.java:258) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:521) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile$3.run(PolicyFile.java:495) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.init(PolicyFile.java:439) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.provider.PolicyFile.(PolicyFile.java:297) >>>>> />>/??????? [java]???? at >>>>> java.security.Policy.getPolicyNoCheck(Policy.java:196) >>>>> />>/??????? [java]???? at >>>>> java.security.Policy.getPolicy(Policy.java:154) >>>>> />>/??????? [java]???? at >>>>> net.jini.security.Security$7.run(Security.java:1054) >>>>> />>/??????? [java]???? at >>>>> net.jini.security.Security$7.run(Security.java:1052) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/? net.jini.security.Security.getPolicy(Security.java:1052) >>>>> />>/??????? [java]???? at >>>>> />>/? net.jini.security.Security.getContext(Security.java:506) >>>>> />>/??????? [java] Unexpected exception: >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:140) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.api.security.CombinerSecurityManager.(CombinerSecurityManager.java:132) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:137) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.tool.SecurityPolicyWriter.(SecurityPolicyWriter.java:160) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>> Method) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>>> />>/??????? [java]???? at java.lang.Class.newInstance(Class.java:442) >>>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:93) >>>>> />>/??????? [java]???? at sun.misc.Launcher.(Launcher.java:54) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) >>>>> />>/ >>>>> />>/ >>>>> />>/ >>>>> />>/??????? [java] java.lang.ExceptionInInitializerError >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> javax.crypto.JceSecurityManager.(JceSecurityManager.java:65) >>>>> />>/??????? [java]???? at >>>>> />>/? javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2586) >>>>> />>/??????? [java]???? at >>>>> />>/? javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2610) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:535) >>>>> >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.ssl.CipherSuite$BulkCipher.(CipherSuite.java:507) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.ssl.CipherSuite.(CipherSuite.java:614) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:294) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:425) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at java.lang.Class.forName0(Native Method) >>>>> />>/??????? [java]???? at java.lang.Class.forName(Class.java:264) >>>>> />>/??????? [java]???? at >>>>> />>/? java.security.Provider$Service.getImplClass(Provider.java:1634) >>>>> />>/??????? [java]???? at >>>>> />>/? java.security.Provider$Service.newInstance(Provider.java:1592) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >>>>> />>/??????? [java]???? at >>>>> />>/? sun.security.jca.GetInstance.getInstance(GetInstance.java:164) >>>>> />>/??????? [java]???? at >>>>> />>/? javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.ssl.Utilities.getServerSSLContextInfo(Utilities.java:712) >>>>> >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.ssl.Utilities.getSupportedCipherSuites(Utilities.java:284) >>>>> >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.ssl.SslEndpointImpl.getConnectionContexts(SslEndpointImpl.java:750) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.ssl.SslEndpointImpl.getCallContext(SslEndpointImpl.java:326) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.ssl.SslEndpointImpl.newRequest(SslEndpointImpl.java:185) >>>>> />>/??????? [java]???? at >>>>> />>/? net.jini.jeri.ssl.SslEndpoint.newRequest(SslEndpoint.java:550) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.BasicObjectEndpoint.newCall(BasicObjectEndpoint.java:421) >>>>> >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:688) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:571) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> com.sun.proxy.$Proxy2.registerGroup(Unknown Source) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:370) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:204) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.getServiceSharedLogDir(ActivatableServiceStarterAdmin.java:388) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.ActivatableServiceStarterAdmin.start(ActivatableServiceStarterAdmin.java:224) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:458) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.test.spec.lookupservice.test_set00.EvntLeaseExpiration.construct(EvntLeaseExpiration.java:88) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:228) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:48) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:174) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> />>/? javax.security.auth.Subject.doAsPrivileged(Subject.java:483) >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:171) >>>>> >>>>> />>/ >>>>> />>/??????? [java]???? at >>>>> />>/? org.apache.river.qa.harness.MasterTest.main(MasterTest.java:150) >>>>> />>/??????? [java] Caused by: java.lang.SecurityException: Can not >>>>> initialize >>>>> />>/? cryptographic mechanism >>>>> />>/??????? [java]???? at >>>>> javax.crypto.JceSecurity.(JceSecurity.java:93) >>>>> />>/??????? [java]???? ... 44 more >>>>> />>/??????? [java] Caused by: java.lang.SecurityException: Cannot >>>>> locate >>>>> />>/? policy or framework files! >>>>> />>/??????? [java]???? at >>>>> />>/ >>>>> javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:316) >>>>> >>>>> />>/??????? [java]???? at >>>>> />>/? javax.crypto.JceSecurity.access$000(JceSecurity.java:50) >>>>> />>/??????? [java]???? at >>>>> javax.crypto.JceSecurity$1.run(JceSecurity.java:85) >>>>> />>/??????? [java]???? at >>>>> java.security.AccessController.doPrivileged(Native >>>>> />>/? Method) >>>>> />>/??????? [java]???? at >>>>> javax.crypto.JceSecurity.(JceSecurity.java:82) >>>>> />/ >>>>> / >>>> >>> >>> >> From prasadarao.koppula at oracle.com Fri Mar 30 06:29:53 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Thu, 29 Mar 2018 23:29:53 -0700 (PDT) Subject: [11] RFR: 8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days. In-Reply-To: References: Message-ID: <01d3ab48-daf2-450b-ba72-4b33f26d6696@default> Hi, Can I please have a review for this fix? Thanks, Prasad.K From: Prasadrao Koppula Sent: Tuesday, March 20, 2018 3:46 PM To: security-dev at openjdk.java.net Subject: [11] RFR: 8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days. Could you please review the changes Webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8187218 The tests was contributed by Weijun Wang. Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Fri Mar 30 16:36:11 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 30 Mar 2018 09:36:11 -0700 (PDT) Subject: JEP 332: Transport Layer Security (TLS) 1.3 Message-ID: <20180330163611.41C131975DE@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/332 - Mark From david.lloyd at redhat.com Fri Mar 30 16:48:15 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 30 Mar 2018 11:48:15 -0500 Subject: JEP 332: Transport Layer Security (TLS) 1.3 In-Reply-To: <20180330163611.41C131975DE@eggemoggin.niobe.net> References: <20180330163611.41C131975DE@eggemoggin.niobe.net> Message-ID: Is it possible that this could make Java 11, or is that a long shot? On Fri, Mar 30, 2018 at 11:36 AM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/332 > > - Mark -- - DML From sean.mullan at oracle.com Fri Mar 30 18:42:57 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 30 Mar 2018 14:42:57 -0400 Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: References: Message-ID: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> A few comments so far; have not finished my review yet. General comment: Many of these tests test more than XDH. That is fine and good for increasing coverage, but have you looked through existing tests to see if you are duplicating anything we are already testing and maybe those tests could be removed or you could share the same code. One of the things we should be looking at is to figure out how to reduce the overall time the security tests take. * KeyAgreementTest.java 128 // Uses platform supported provider to test interoperability. What do you mean by "platform supported provider"? Isn't this based on the provider search order? So in some cases, you might be testing against the same provider and not really doing interop testing? * KeySizeTest.java You are generating some large keys - any issues with test timeouts? Do we need to test the generation of the keypairs? Could we use cached keypairs instead? --Sean On 3/26/18 12:38 PM, Sibabrata Sahoo wrote: > Hi, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184359 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.00/ > > All the Test files uses KeyAgreement, KeyPairGenerator, Several KeySpecs > from SunJCE library to Test DiffieHellman, ECDH and XDH with curve25519 > and curve448 algorithms. Each Test files try to address several cases > and the purpose of each has been commented in their own files. > > Thanks, > > Siba > From sean.mullan at oracle.com Fri Mar 30 20:08:59 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 30 Mar 2018 16:08:59 -0400 Subject: RFR 8171277: Elliptic Curves for Security in Crypto (part 2) In-Reply-To: <5096fafb-a513-796d-652b-a712d4a7a7b2@oracle.com> References: <5096fafb-a513-796d-652b-a712d4a7a7b2@oracle.com> Message-ID: The updated webrev looks good. --Sean On 3/27/18 4:23 PM, Adam Petcher wrote: > After the last code review[1] on this topic completed, it was suggested > that I add some more "spec enforcement" to the XDH service. The code > hasn't been integrated yet, so I'm doing this as a follow-on review > under the same ticket. The latest webrev contains only the diff from the > end of the last review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8171277 > Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.03/ > > (note: you can look at webrev.02 to see the code at the end of the last > review). > > For XDH, we are adding the algorithm names "X25519" and "X448", because > these names are more widely known than "XDH". This leaves us with the > problem of whether things like this should be allowed: > > var kpg = KeyPairGenerator.getInstance("X448"); > kpg.initialize(new NamedParameterSpec("X25519")); > > To promote good code hygiene, the implementation in SunEC will reject > all confusing combinations like this in all XDH services. Programmers > can still use the "XDH" algorithm name to get a service that allows all > supported parameters and key sizes. > > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2018-March/016915.html >