From weijun.wang at oracle.com Wed Aug 1 02:34:05 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 Aug 2018 10:34:05 +0800 Subject: [12] RFR 8208602: Cannot read PEM X.509 cert if there is whitespace after the header or footer Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8208602/webrev.00/ https://tools.ietf.org/html/rfc7468#section-3 explicitly allows WSP after the header/footer: textualmsg = preeb *WSP eol *eolWSP base64text posteb *WSP [eol] preeb = "-----BEGIN " label "-----" ;... ;... posteb = "-----END " label "-----" ;... Thanks Max From xuelei.fan at oracle.com Wed Aug 1 02:48:45 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 31 Jul 2018 19:48:45 -0700 Subject: [12] RFR 8208602: Cannot read PEM X.509 cert if there is whitespace after the header or footer In-Reply-To: References: Message-ID: Looks fine to me. Xuelei On 7/31/2018 7:34 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8208602/webrev.00/ > > https://tools.ietf.org/html/rfc7468#section-3 explicitly allows WSP after the header/footer: > > textualmsg = preeb *WSP eol > *eolWSP > base64text > posteb *WSP [eol] > > preeb = "-----BEGIN " label "-----" ;... > ;... > posteb = "-----END " label "-----" ;... > > Thanks > Max > From weijun.wang at oracle.com Wed Aug 1 06:59:59 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 Aug 2018 14:59:59 +0800 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: References: Message-ID: Some comments: 1. Is it possible to let rename PBEKey::clearKey to PNEKey::destroy? 2. I am not sure if the newly added "Arrays.fill(thatEncoded, (byte)0x00)" line in PBEKey::equals is safe. What if that key does not return a cloned copy when getEncode() is called? This is possible if the class is only used internally and never escape. 3. You would need to modify the spec of s.s.p.KeyProtector:: since password is of a new type. In fact, is this change necessary? Just to prevent the duplication of code in convertToBytes()? 4. I found the last line of PBEKey:: might be modified to CleanerFactory.cleaner().register(this, this::clearKey); I have never been a lambda expert so forgive me if this is not correct. Thanks Max > On Aug 1, 2018, at 3:11 AM, Se?n Coffey wrote: > > Looking to improve management of internal buffers in KeyStore. The com.sun.crypto.provider.KeyProtector class uses the PBEKey class to protect some keys. Buffers can be freed up earlier if the caller takes responsibility for lifecycle of PBEKey object. (hence no reliance on Cleaner). Some other minor improvements made while visiting this area. > > Other improvements in sun.security.provider.KeyProtector where I believe the password buffer can be managed by the caller. I only found 2 instances of where this class is used. > > https://bugs.openjdk.java.net/browse/JDK-8208583 > http://cr.openjdk.java.net/~coffeys/webrev.8208583.v1/webrev/index.html > > regards, > Sean. > From sean.coffey at oracle.com Wed Aug 1 08:17:34 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 1 Aug 2018 09:17:34 +0100 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: References:

Message-ID: <55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com> Thanks for the comments Max. Comments inline.. On 01/08/2018 07:59, Weijun Wang wrote: > Some comments: > > 1. Is it possible to let rename PBEKey::clearKey to PNEKey::destroy? Sure. > > 2. I am not sure if the newly added "Arrays.fill(thatEncoded, (byte)0x00)" line in PBEKey::equals is safe. What if that key does not return a cloned copy when getEncode() is called? This is possible if the class is only used internally and never escape. This is not new code. I just refactored the java.util.Arrays.fill call to Arrays.fill. > > 3. You would need to modify the spec of s.s.p.KeyProtector:: since password is of a new type. In fact, is this change necessary? Just to prevent the duplication of code in convertToBytes()? Yes, I can add edits to that effect. The class is package private and I only found 2 usages of it. The main advantage is not having to copy or create an extra buffer in this code. The calling code now has full control over when it can null out the bytes in use. That should be a help here and also means we don't place unnecessary load on GC/Cleaner. > > 4. I found the last line of PBEKey:: might be modified to > > CleanerFactory.cleaner().register(this, this::clearKey); Sure - I can modify that. regards, Sean. > > I have never been a lambda expert so forgive me if this is not correct. > > Thanks > Max > >> On Aug 1, 2018, at 3:11 AM, Se?n Coffey wrote: >> >> Looking to improve management of internal buffers in KeyStore. The com.sun.crypto.provider.KeyProtector class uses the PBEKey class to protect some keys. Buffers can be freed up earlier if the caller takes responsibility for lifecycle of PBEKey object. (hence no reliance on Cleaner). Some other minor improvements made while visiting this area. >> >> Other improvements in sun.security.provider.KeyProtector where I believe the password buffer can be managed by the caller. I only found 2 instances of where this class is used. >> >> https://bugs.openjdk.java.net/browse/JDK-8208583 >> http://cr.openjdk.java.net/~coffeys/webrev.8208583.v1/webrev/index.html >> >> regards, >> Sean. >> From anthony.scarpino at oracle.com Wed Aug 1 14:55:14 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 1 Aug 2018 07:55:14 -0700 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: <69ecf86c-9ea1-d777-5ce9-59c7cc757d2c@oracle.com> References:

<64125402-3d3f-59b9-9253-9003b0b7676b@oracle.com> <080200b7-ce2e-76cb-763e-3e934f05aaaf@oracle.com> <69ecf86c-9ea1-d777-5ce9-59c7cc757d2c@oracle.com> Message-ID: <9b12b891-3aa0-e9ed-3560-e423e2b58fb7@oracle.com> My only comment is if it makes sense to have the change at 676 to also only null out on decrypt? Otherwise I'm fine with the changes Tony On 07/31/2018 02:04 AM, Se?n Coffey wrote: > Thanks for review Tony. Comments inline.. > > On 27/07/18 21:02, Anthony Scarpino wrote: >> If we are going to add more, here are two more ton consider: >> >> - It looks like there is another Arrays.copyOf() on doFinal() line 851 > Good point. >> - doFinal() >> at line 897 there might be something that should be done with >> 'buffer'.? In particular as a result of line 963's arraycopy(). > Yes - I've identified two areas where we can be proactive about nulling > out 'buffer' contents. That's around the same time where we reset > 'buffered' to 0. See lines 777 and 967 > > http://cr.openjdk.java.net/~coffeys/webrev.8207775.v3/webrev/ > > regards, > Sean. >> >> Tony >> >> >> On 07/27/2018 08:29 AM, Se?n Coffey wrote: >>> Thanks Tony. If it's alright with you, I'd like to make one more edit >>> for this change. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v2/webrev/ >>> >>> There's a condition where we can null out an array early if we're >>> returning a copy. See lines 671-683 >>> >>> Regards, >>> Sean. >>> >>> On 26/07/18 17:42, Anthony Scarpino wrote: >>>> On 07/26/2018 07:36 AM, Se?n Coffey wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8207775 >>>>> >>>>> Simple enough fix to null out some internal buffers once they're no >>>>> longer required. >>>>> >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>> >>>> that looks fine.. >>>> >>>> Tony >>> >> > From sean.coffey at oracle.com Wed Aug 1 15:39:19 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 1 Aug 2018 16:39:19 +0100 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: <9b12b891-3aa0-e9ed-3560-e423e2b58fb7@oracle.com> References:

<64125402-3d3f-59b9-9253-9003b0b7676b@oracle.com> <080200b7-ce2e-76cb-763e-3e934f05aaaf@oracle.com> <69ecf86c-9ea1-d777-5ce9-59c7cc757d2c@oracle.com> <9b12b891-3aa0-e9ed-3560-e423e2b58fb7@oracle.com> Message-ID: Thanks again for review Tony. I think you raise a good point and should give some performance gain. for line 676: maybe this : byte[] copy = Arrays.copyOf(output, len); if (decrypting) { Arrays.fill(output, (byte) 0x00); } return copy; perhaps the same again for around line 852 : byte[] copy = Arrays.copyOf(output, len); if (decrypting) { Arrays.fill(output, (byte) 0x00); } return copy; == Any other reviews/comments from folks before I submit final build/test & webrev ? Regards, Sean. On 01/08/18 15:55, Anthony Scarpino wrote: > > > My only comment is if it makes sense to have the change at 676 to also > only null out on decrypt? > > Otherwise I'm fine with the changes > > Tony > > On 07/31/2018 02:04 AM, Se?n Coffey wrote: >> Thanks for review Tony. Comments inline.. >> >> On 27/07/18 21:02, Anthony Scarpino wrote: >>> If we are going to add more, here are two more ton consider: >>> >>> - It looks like there is another Arrays.copyOf() on doFinal() line 851 >> Good point. >>> - doFinal() >>> at line 897 there might be something that should be done with >>> 'buffer'. In particular as a result of line 963's arraycopy(). >> Yes - I've identified two areas where we can be proactive about >> nulling out 'buffer' contents. That's around the same time where we >> reset 'buffered' to 0. See lines 777 and 967 >> >> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v3/webrev/ >> >> regards, >> Sean. >>> >>> Tony >>> >>> >>> On 07/27/2018 08:29 AM, Se?n Coffey wrote: >>>> Thanks Tony. If it's alright with you, I'd like to make one more >>>> edit for this change. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v2/webrev/ >>>> >>>> There's a condition where we can null out an array early if we're >>>> returning a copy. See lines 671-683 >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 26/07/18 17:42, Anthony Scarpino wrote: >>>>> On 07/26/2018 07:36 AM, Se?n Coffey wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207775 >>>>>> >>>>>> Simple enough fix to null out some internal buffers once they're >>>>>> no longer required. >>>>>> >>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>> >>>>> that looks fine.. >>>>> >>>>> Tony >>>> >>> >> > From sean.coffey at oracle.com Wed Aug 1 15:55:35 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 1 Aug 2018 16:55:35 +0100 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: <55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com> References:

<55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com> Message-ID: Max, some updates. 1. I wasn't able to rename to destroy since that method is reserved for the Destroyable interface. I've gone with destroyKey. 3. As per offline communication, I've removed the ASCII reference in the s.s.p.KeyProtector constructor comments. I don't believe ASCII requirement was ever enforced (nor needed). We use the 16 bits if presented. If password standards need review, that work should be carried out in another bug report. 4. I wasn't able to use your suggested method reference syntax. The reference to this would prevent the Object from being cleaned. The PBEKeyCleanupTest testcase seems to confirm that. http://cr.openjdk.java.net/~coffeys/webrev.8208583.v2/webrev/index.html Regards, Sean. On 01/08/18 09:17, Se?n Coffey wrote: > Thanks for the comments Max. Comments inline.. > > > On 01/08/2018 07:59, Weijun Wang wrote: >> Some comments: >> >> 1. Is it possible to let rename PBEKey::clearKey to PNEKey::destroy? > Sure. >> >> 2. I am not sure if the newly added "Arrays.fill(thatEncoded, >> (byte)0x00)" line in PBEKey::equals is safe. What if that key does >> not return a cloned copy when getEncode() is called? This is possible >> if the class is only used internally and never escape. > This is not new code. I just refactored the java.util.Arrays.fill call > to Arrays.fill. >> >> 3. You would need to modify the spec of s.s.p.KeyProtector:: >> since password is of a new type. In fact, is this change necessary? >> Just to prevent the duplication of code in convertToBytes()? > Yes, I can add edits to that effect. The class is package private and > I only found 2 usages of it. The main advantage is not having to copy > or create an extra buffer in this code. The calling code now has full > control over when it can null out the bytes in use. That should be a > help here and also means we don't place unnecessary load on GC/Cleaner. >> >> 4. I found the last line of PBEKey:: might be modified to >> >> CleanerFactory.cleaner().register(this, this::clearKey); > Sure - I can modify that. > > regards, > Sean. >> >> I have never been a lambda expert so forgive me if this is not correct. >> >> Thanks >> Max >> >>> On Aug 1, 2018, at 3:11 AM, Se?n Coffey wrote: >>> >>> Looking to improve management of internal buffers in KeyStore. The >>> com.sun.crypto.provider.KeyProtector class uses the PBEKey class to >>> protect some keys. Buffers can be freed up earlier if the caller >>> takes responsibility for lifecycle of PBEKey object. (hence no >>> reliance on Cleaner). Some other minor improvements made while >>> visiting this area. >>> >>> Other improvements in sun.security.provider.KeyProtector where I >>> believe the password buffer can be managed by the caller. I only >>> found 2 instances of where this class is used. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8208583 >>> http://cr.openjdk.java.net/~coffeys/webrev.8208583.v1/webrev/index.html >>> >>> regards, >>> Sean. >>> > From anthony.scarpino at oracle.com Wed Aug 1 17:41:26 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 1 Aug 2018 10:41:26 -0700 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: References:

<97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com>

<4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> <9b041cf3-3caa-3f3c-ebec-70c012743b7d@oracle.com> <3a986da4-20b8-c66c-aee3-603dfaedd6a4@oracle.com> Message-ID: Hi, On Tue, Jul 31, 2018 at 9:56 PM Xuelei Fan wrote: > Hm, I see your point. Because of the half-close policy, I think the > server could keep sending messages other than the close_notify alert. Exactly. > My concern of the CLOSED+NOT_HANDSHAKING is that it does not indicate > the following operations. Sure it does. CLOSED while unwrapping tells the application that the other side has closed. Now the application has a choice: it can wrap() more data, or call closeOutbound(). >From there, it follows SSLEngine instructions via the states. Having to take into consideration not only the Result, not only the HandshakeStatus, but also bytes produced seems weird to me. I'd prefer to just rely only on Result and HandshakeStatus. > Yes, but it is the desired behavior to me. For the TLS 1.3 half close > policy, it is not expected to generate close_notify reply unless the > server close its outbound. So the server can keep sending the > application data after the read close, as it write side is open. Exactly. > The TLS 1.3 spec says: > "Each party MUST send a "close_notify" alert before closing its write > side of the connection, unless it has already sent some error alert. > This does not have any effect on its read side of the connection." > > And the SSLEngine.closeOutbound() spec says: > "Signals that no more outbound application data will be sent on > this SSLEngine." > > I think it is fine to keep the write side open while the read side closed. > > In this update, for TLS 1.2 connection, the duplex-close behavior is > reserved: as the server received the close_notify, it moving to > NEED_WRAP; and the a close_notify will be delivered, and then duplex > close the connection. Exactly, and without the need for the receiver of the close_notify to call closeOutbound(). That will be a difference between TLS 1.2 and TLS 1.3 that applications should take into consideration. > However, for TLS 1.3 connection, if there is no call to > server.closeOutbound(), the server write side keeps open even the read > side has been closed. > > In this update, for TLS 1.3, I tried to support half-close for: > 1. SSLEngine.closeIn/Outbound() > 2. SSLSocket.shutdownIn/Output() > > and duplex-close for: > 3. SSLSocket.close() > > Unfortunately, it does introduce a compatibility issue that an existing > application may not close both inbound and outbound if the connection is > desired to be duplex-closed. In order to mitigate the impact, a new > System Property in introduced, "jdk.tls.acknowledgeCloseNotify". This > compatibility issues could be mitigated by closing both inbound and > outbound explicitly, or set the property to "true". If the property > value is "true", a corresponding close_notify alert will be sent when > receiving a close_notify alert, and therefore the connection will be > duplex closed. > > Does it make sense to you? Yes. Although I think application will need to make adjustments for TLS 1.3 anyway. That system property will smooth things, but won't guarantee that an application written for SSLEngine TLS 1.2 will work for SSLEngine TLS 1.3. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From valerie.peng at oracle.com Wed Aug 1 21:40:52 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 1 Aug 2018 14:40:52 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com>

<7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> Message-ID: <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> Hi Martin, I imported your webrev.06 and sun/security/pkcs11/tls/TestTLS12.java still fails, but with a different reason (see below). jib > STDERR: jib > java.lang.RuntimeException: unable to expand property pkcs11test.nss.libdir jib > at jdk.crypto.cryptoki/sun.security.pkcs11.Config.expand(Config.java:340) jib > at jdk.crypto.cryptoki/sun.security.pkcs11.Config.parseLibrary(Config.java:663) jib > at jdk.crypto.cryptoki/sun.security.pkcs11.Config.parse(Config.java:429) jib > at jdk.crypto.cryptoki/sun.security.pkcs11.Config.(Config.java:212) jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) jib > at java.base/java.security.AccessController.doPrivileged(Native Method) jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) jib > at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) jib > at TestTLS12.initializeProvider(TestTLS12.java:278) jib > at TestTLS12.main(TestTLS12.java:96) jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) jib > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566) jib > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) jib > at java.base/java.lang.Thread.run(Thread.java:834) jib > jib > JavaTest Message: Test threw exception: java.lang.RuntimeException: unable to expand property pkcs11test.nss.libdir jib > JavaTest Message: shutting down test jib > jib > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: unable to expand property pkcs11test.nss.libdir When looking at the test itself, the test extends SecmodTest instead of PKCS11Test, but then it did not call initSecmod() as other tests which extend SecmodTest. Otherwise, most of PKCS11 tests extends PKCS11Test, implement the abstract main(Provider) method, and then skip tests if the specified provider does not support the required implementation. Lastly, some nits which I forgot to include in my earlier emails 1) make sure the copyright years are current, i.e. 2018. 2) @author tags is past practice. We stopped this quite some years back. Thanks, Valerie On 7/31/2018 4:48 PM, Valerie Peng wrote: > > I sent this email a bit prematurely. I still need to review > TestTLS12.java. > > All else is done. > > Valerie > > > On 7/31/2018 4:26 PM, Valerie Peng wrote: >> >> Hi Martin, >> >> Here are the review comments for the remaining files: >> >> >> >> - Always check non-null result for JNIEnv FindClass(...) calls, e.g. >> line 530 and 802 >> >> - Sometimes the check is there but is after the return value has been >> used. These checks should be moved up, i.e. right after the >> FindClass(..) calls, e.g. line 555, 834. >> >> - line 1262, should be CK_TLS12_MASTER_KEY_DERIVE_PARAMS instead of >> CK_TLS12_MASTER_KEY_DERIVE_PARAMS_PTR >> >> >> Thanks, >> Valerie >> >> >> On 7/26/2018 9:12 AM, Martin Balao wrote: >>> Hi Valerie, >>> >>> Thanks for your feedback! >>> >>> CKM_TLS12_MAC looks like it's not in use. Authentication codes are >>> calculated through CKM_TLS12_KEY_AND_MAC_DERIVE mechanism. Do you >>> know of a library supporting CKM_TLS12_MAC but not >>> CKM_TLS12_KEY_AND_MAC_DERIVE? I've been testing this with NSS >>> software token which does not support CKM_TLS12_MAC. >>> >>> module-info.java changes were from when we used SSL/TLS constants, >>> but then I replaced these constants with hardcoded numbers -after >>> discussing with Xuelei-. I forgot to revert changes on this file. >>> Thanks. >>> >>> Config.java changes were from a wrong version I uploaded. This has >>> been already fixed. >>> >>> SunPKCS11.java: I agree with you that registration must be done >>> separately. SunTls12MasterSecret and SunTls12KeyMaterial are now >>> registered separately. I've added CKM_TLS12_MASTER_KEY_DERIVE_DH >>> mechanism to SunTls12MasterSecret algorithm. It's still assumed that >>> if CKM_TLS12_MASTER_KEY_DERIVE is supported, then >>> CKM_TLS12_MASTER_KEY_DERIVE_DH it's and vice-versa -same as with >>> previous key derivation mechanisms-. Not a big deal though I think: >>> it's unlikely that a library implements only one of these. Using >>> protocol version to decide which mechanism to use should be valid in >>> this case because if an instance of P11TlsMasterSecretGenerator is >>> used and algorithm is SunTls12MasterSecret, then protocol must be >>> TLS 1.2 and we can assume that there is support of these mechanisms >>> in the underlying library. >>> L527: I've realized that a better place for this map is >>> Functions.java. I've moved it there. >>> >>> P11TlsPrfGenerator.java: This code is for TLS 1.2 only. That's >>> because CKM_TLS_MAC mechanism is registered for SunTls12Prf >>> algorithm. Previous TLS versions use CKM_TLS_PRF and >>> CKM_NSS_TLS_PRF_GENERAL. >>> >>> P11TlsRsaPremasterSecretGenerator.java: Yes, we can remove it and >>> call all keys "TlsRsaPremasterSecret", disregarding the mechanism >>> used to generate it (CKM_SSL3_PRE_MASTER_KEY_GEN or >>> CKM_TLS_PRE_MASTER_KEY_GEN). At the end of the day, this is just an >>> array of 48 bytes. I've removed the field too. >>> >>> Functions.java: New entries (CKM_TLS12_MASTER_KEY_DERIVE, >>> CKM_TLS12_MASTER_KEY_DERIVE_DH and CKM_TLS_MAC) moved after line >>> 721. CKM_TLS12_KEY_AND_MAC_DERIVE has been added for completeness. >>> >>> CK_ATTRIBUTE.java: SENSITIVE_TRUE removed. >>> >>> Removed a dependency in TestTLS12.java to HexDumper (internal). >>> >>> Webrev 06 with all these changes here: >>> >>> ?* >>> http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06/ >>> >>> ?* >>> http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06.zip >>> >>> >>> Regression testing on jdk/sun/security/pkcs11 passes with samae pass >>> rate. >>> >>> Kind regards, >>> Martin.- >>> >>> On Tue, Jul 24, 2018 at 11:00 PM, Valerie Peng >>> > wrote: >>> >>> Hi Martin, >>> >>> Sorry for the delay, I am able to resume on reviewing this now. >>> >>> Here are some initial comments. >>> >>> What about CKM_TLS12_MAC? I see that it's defined under TLS 1.2 >>> mechanisms, but not much other details for it. >>> >>> >>> - Is this change still necessary? I didn't notice any new import >>> statement with sun.security.ssl package in the rest of changes. >>> >>> >>> - Why removing the SENSITIVE_FALSE attribute on line 829 and 854? >>> >>> >>> - As my comments for the SunPKCS11.java (see below), I think we >>> should not assume the support for CKM_TLS12_KEY_AND_MAC_DERIVE. >>> The existing impl and how it's registered in SunPKCS11 class is >>> already somewhat problematic when CKM_TLS_KEY_AND_MAC_DERIVE is >>> not supported. We should avoid assuming >>> CKM_TLS12_KEY_AND_MAC_DERIVE is supported which may create even >>> more problems. Overriding this.mechanism based on the TLS >>> version specified in the parameters from the engineInit(...) >>> call will lead to failure when the mechanism is not supported by >>> underlying PKCS11 library >>> >>> >>> - Please see above comments for P11TlsKeyMaterialGenerator.java >>> >>> >>> - Retrieve label outside of the new code block for TLS 1.2, i.e. >>> line 133- 167, as it's used by all mechanisms. >>> >>> >>> - Line 131, Is it really necessary to use >>> SunTls12RsaPremasterSecret? SunJCE provider uses >>> SunTlsRsaPremasterSecret for all cases. If different algorithm >>> is not needed, then no need to save tlsVersion as a field >>> >>> >>> - Hmm, for TLS 12 specific mechanisms, some PKCS11 libraries may >>> not support them. Instead of registering >>> SunTls12MasterSecret/SunTls12KeyMaterial as aliases, they should >>> be registered separately so that if the native TLS 12 mechanisms >>> were not supported, the new entry will be skipped. The >>> corresponding implementation classes such as >>> P11TlsMasterSecretGenerator and P11TlsKeyMaterialGenerator will >>> have to check the specified parameter spec in their >>> engineInit(..) calls to make sure things line up, e.g. error out >>> if the TLS version in the spec does not match the native mechanism. >>> - Lines 528 - 532, the mapping is stored without checking for >>> support. May become an issue when the underlying PKCS11 library >>> does not support all of these hash mechanisms. Probably not a >>> big deal as these are fairly common hash algorithms, but I think >>> it'd be good to add a comment on line 527 with something like >>> "// assuming all hash mechanisms below are supported". >>> >>> >>> - Miss the mapping for CKM_TLS12_KEY_AND_MAC_DERIVE? Move these >>> new entries to be after the existing SSL3/TLS entries (from line >>> 711-721) >>> >>> I still have a few files left and will send you comments on them >>> later. >>> Thanks, >>> Valerie >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Aug 2 01:13:14 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 2 Aug 2018 09:13:14 +0800 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: References:

<55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com> Message-ID: > On Aug 1, 2018, at 11:55 PM, Se?n Coffey wrote: > > Max, > > some updates. > > 1. > > I wasn't able to rename to destroy since that method is reserved for the Destroyable interface. I've gone with destroyKey. Sorry I wasn't clear but this is exactly what I meant. SecretKey implements Destroyable so you don't need to define sKey as PBEKey. Does it make any problem? > > 3. > > As per offline communication, I've removed the ASCII reference in the s.s.p.KeyProtector constructor comments. I don't believe ASCII requirement was ever enforced (nor needed). We use the 16 bits if presented. If password standards need review, that work should be carried out in another bug report. > > 4. > > I wasn't able to use your suggested method reference syntax. The reference to this would prevent the Object from being cleaned. The PBEKeyCleanupTest testcase seems to confirm that. Oops. > > http://cr.openjdk.java.net/~coffeys/webrev.8208583.v2/webrev/index.html > > Regards, > Sean. > > On 01/08/18 09:17, Se?n Coffey wrote: >> Thanks for the comments Max. Comments inline.. >> >> >> On 01/08/2018 07:59, Weijun Wang wrote: >>> Some comments: >>> >>> 1. Is it possible to let rename PBEKey::clearKey to PNEKey::destroy? >> Sure. >>> >>> 2. I am not sure if the newly added "Arrays.fill(thatEncoded, (byte)0x00)" line in PBEKey::equals is safe. What if that key does not return a cloned copy when getEncode() is called? This is possible if the class is only used internally and never escape. >> This is not new code. I just refactored the java.util.Arrays.fill call to Arrays.fill. >>> >>> 3. You would need to modify the spec of s.s.p.KeyProtector:: since password is of a new type. In fact, is this change necessary? Just to prevent the duplication of code in convertToBytes()? >> Yes, I can add edits to that effect. The class is package private and I only found 2 usages of it. The main advantage is not having to copy or create an extra buffer in this code. The calling code now has full control over when it can null out the bytes in use. That should be a help here and also means we don't place unnecessary load on GC/Cleaner. >>> >>> 4. I found the last line of PBEKey:: might be modified to >>> >>> CleanerFactory.cleaner().register(this, this::clearKey); >> Sure - I can modify that. >> >> regards, >> Sean. >>> >>> I have never been a lambda expert so forgive me if this is not correct. >>> >>> Thanks >>> Max >>> >>>> On Aug 1, 2018, at 3:11 AM, Se?n Coffey wrote: >>>> >>>> Looking to improve management of internal buffers in KeyStore. The com.sun.crypto.provider.KeyProtector class uses the PBEKey class to protect some keys. Buffers can be freed up earlier if the caller takes responsibility for lifecycle of PBEKey object. (hence no reliance on Cleaner). Some other minor improvements made while visiting this area. >>>> >>>> Other improvements in sun.security.provider.KeyProtector where I believe the password buffer can be managed by the caller. I only found 2 instances of where this class is used. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8208583 >>>> http://cr.openjdk.java.net/~coffeys/webrev.8208583.v1/webrev/index.html >>>> >>>> regards, >>>> Sean. >>>> >> > From xuelei.fan at oracle.com Thu Aug 2 02:27:24 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 1 Aug 2018 19:27:24 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> Message-ID: Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 renegotiation fails if Java client allows TLSv1.3". SSLHandshake.java is updated to use negotiated version so that TLS 1.2 HelloRequest is acceptable in TLS 1.3 client side. Thanks, Xuelei On 7/30/2018 10:24 AM, Xuelei Fan wrote: > > Please let me know your concerns by the end of August 1st, 2018. > > Thanks, > Xuelei > > > On 7/30/2018 9:59 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the update for the TLS 1.3 half-close and >> synchronization implementation: >> ??? http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >> >> Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify is >> use to close the local write side and peer read side only.? After the >> close_notify get handles, the local read side and peer write side may >> still be open. >> >> In this update, if an application calls >> SSLEngine.closeInbound/Outbound() or SSLSocket.shutdownInput/Output(), >> half-close will be used.? For compatibility, if SSLSocket.close() get >> called, a duplex close will be tried.? In order to support duplex >> close, JDK will use the user_canceled warning alert even the handshake >> complete. >> >> In practice, an application may only close outbound even it is >> intended to close the inbound as well, or close the connection >> completely.? It works for TLS 1.2 and prior versions.? But no more for >> TLS 1.3 because of the close_notify behavior change in the TLS 1.3 >> specification.? The application may be hung and dead-waiting for >> read/close.? It could be solved by closing the inbound explicitly.? In >> order to mitigate the impact, a new System Property is introduced, >> "jdk.tls.acknowledgeCloseNotify" if source code update is not >> available. ??If the System Property is set to "true", if receiving the >> close_notify, a close_notify alert will be responded.? It is a >> countermeasure of the TLS 1.3 half-close issues. >> >> Thanks, >> Xuelei >> >> >> From weijun.wang at oracle.com Thu Aug 2 02:28:42 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 2 Aug 2018 10:28:42 +0800 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported Message-ID: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. Thanks Max From sibabrata.sahoo at oracle.com Thu Aug 2 10:41:41 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 2 Aug 2018 03:41:41 -0700 (PDT) Subject: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. Message-ID: <078fa675-1fe8-4ef9-bb5a-5b3711b682ec@default> Hi Xuelei, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8208496 Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.00/ This is a new Test which test concurrent behavior of TLS. It uses 50 client thread to access a single server port concurrently and repeat this process for each protocol supported. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Aug 2 11:38:37 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 2 Aug 2018 12:38:37 +0100 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: References:

<55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com>

Message-ID: <8c3163d7-663a-0c07-f6bc-d732c83bc5ae@oracle.com> No - no problem at all. Some extra exception handling but probably best for the long run. http://cr.openjdk.java.net/~coffeys/webrev.8208583.v3/webrev/index.html regards, Sean. On 02/08/2018 02:13, Weijun Wang wrote: >> 1. >> >> I wasn't able to rename to destroy since that method is reserved for the Destroyable interface. I've gone with destroyKey. > Sorry I wasn't clear but this is exactly what I meant. SecretKey implements Destroyable so you don't need to define sKey as PBEKey. Does it make any problem? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Aug 2 12:15:01 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 2 Aug 2018 13:15:01 +0100 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: <560bbaeb-bf50-db52-c99a-d75341c6f0fb@oracle.com> References:

<64125402-3d3f-59b9-9253-9003b0b7676b@oracle.com> <080200b7-ce2e-76cb-763e-3e934f05aaaf@oracle.com> <69ecf86c-9ea1-d777-5ce9-59c7cc757d2c@oracle.com> <9b12b891-3aa0-e9ed-3560-e423e2b58fb7@oracle.com> <560bbaeb-bf50-db52-c99a-d75341c6f0fb@oracle.com> Message-ID: <175c2846-99b3-14bb-2736-66e8a7dd5c65@oracle.com> Thanks Tony. I was asked off thread to add some comments to help code maintenance also. webrev updated. Hope we're nearly ready to push now. http://cr.openjdk.java.net/~coffeys/webrev.8207775.v4/webrev/ regards, Sean. On 01/08/2018 18:41, Anthony Scarpino wrote: > That looks fine to me. > > Tony > > On 08/01/2018 08:39 AM, Se?n Coffey wrote: >> Thanks again for review Tony. I think you raise a good point and >> should give some performance gain. >> >> for line 676: maybe this : >> >> ????????????????? byte[] copy = Arrays.copyOf(output, len); >> ????????????????? if (decrypting) { >> ????????????????????? Arrays.fill(output, (byte) 0x00); >> ????????????????? } >> ????????????????? return copy; >> >> >> perhaps the same again for around line 852 : >> ????????????????? byte[] copy = Arrays.copyOf(output, len); >> ????????????????? if (decrypting) { >> ????????????????????? Arrays.fill(output, (byte) 0x00); >> ????????????????? } >> ????????????????? return copy; >> >> == >> >> Any other reviews/comments from folks before I submit final >> build/test & webrev ? >> >> Regards, >> Sean. >> >> On 01/08/18 15:55, Anthony Scarpino wrote: >>> >>> >>> My only comment is if it makes sense to have the change at 676 to >>> also only null out on decrypt? >>> >>> Otherwise I'm fine with the changes >>> >>> Tony >>> >>> On 07/31/2018 02:04 AM, Se?n Coffey wrote: >>>> Thanks for review Tony. Comments inline.. >>>> >>>> On 27/07/18 21:02, Anthony Scarpino wrote: >>>>> If we are going to add more, here are two more ton consider: >>>>> >>>>> - It looks like there is another Arrays.copyOf() on doFinal() line >>>>> 851 >>>> Good point. >>>>> - doFinal() >>>>> at line 897 there might be something that should be done with >>>>> 'buffer'.? In particular as a result of line 963's arraycopy(). >>>> Yes - I've identified two areas where we can be proactive about >>>> nulling out 'buffer' contents. That's around the same time where we >>>> reset 'buffered' to 0. See lines 777 and 967 >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v3/webrev/ >>>> >>>> regards, >>>> Sean. >>>>> >>>>> Tony >>>>> >>>>> >>>>> On 07/27/2018 08:29 AM, Se?n Coffey wrote: >>>>>> Thanks Tony. If it's alright with you, I'd like to make one more >>>>>> edit for this change. >>>>>> >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v2/webrev/ >>>>>> >>>>>> There's a condition where we can null out an array early if we're >>>>>> returning a copy. See lines 671-683 >>>>>> >>>>>> Regards, >>>>>> Sean. >>>>>> >>>>>> On 26/07/18 17:42, Anthony Scarpino wrote: >>>>>>> On 07/26/2018 07:36 AM, Se?n Coffey wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207775 >>>>>>>> >>>>>>>> Simple enough fix to null out some internal buffers once >>>>>>>> they're no longer required. >>>>>>>> >>>>>>>> webrev : >>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>> >>>>>>> that looks fine.. >>>>>>> >>>>>>> Tony >>>>>> >>>>> >>>> >>> >> > From sean.mullan at oracle.com Thu Aug 2 15:05:19 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Aug 2018 11:05:19 -0400 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> Message-ID: <48a1bb2f-e956-4289-b672-f7ea99774bdc@oracle.com> You will need to file a CSR since you are extending the options to -printcert to now include the provider name, class, etc. Also, there is no test. --Sean On 8/1/18 10:28 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ > > Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. > > Thanks > Max > From weijun.wang at oracle.com Thu Aug 2 15:31:51 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 2 Aug 2018 23:31:51 +0800 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: <48a1bb2f-e956-4289-b672-f7ea99774bdc@oracle.com> References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <48a1bb2f-e956-4289-b672-f7ea99774bdc@oracle.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8208689 filed. --Max > On Aug 2, 2018, at 11:05 PM, Sean Mullan wrote: > > You will need to file a CSR since you are extending the options to -printcert to now include the provider name, class, etc. > > Also, there is no test. > > --Sean > > On 8/1/18 10:28 PM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ >> Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. >> Thanks >> Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Aug 2 16:05:41 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 3 Aug 2018 00:05:41 +0800 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: <8c3163d7-663a-0c07-f6bc-d732c83bc5ae@oracle.com> References:

<55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com>

<8c3163d7-663a-0c07-f6bc-d732c83bc5ae@oracle.com> Message-ID: <9FFFEE9C-C14B-4A05-A3A5-61340045C42A@oracle.com> KeyProtector.java: 113 pbeKeySpec.clearPassword(); You can also put this into the finally block. 189 Arrays.fill(plain, (byte) 0x00); Can this be in finally? JavaKeyStore.java: 149 Arrays.fill(passwordBytes, (byte) 0x00); In other cases, you call it in a finally block. Unnecessary here? (Oops, every comment is about finally.) KeyProtector.java: 123 public KeyProtector(byte[] password) How about just "public KeyProtector(byte[] passwordBytes)"? > On Aug 2, 2018, at 7:38 PM, Se?n Coffey wrote: > > No - no problem at all. Some extra exception handling but probably best for the long run. I wonder why DestroyedFailedException was a checked exception, what can we do if it's thrown? Thanks Max > > http://cr.openjdk.java.net/~coffeys/webrev.8208583.v3/webrev/index.html > > regards, > Sean. > > On 02/08/2018 02:13, Weijun Wang wrote: >>> 1. >>> >>> I wasn't able to rename to destroy since that method is reserved for the Destroyable interface. I've gone with destroyKey. >>> >> Sorry I wasn't clear but this is exactly what I meant. SecretKey implements Destroyable so you don't need to define sKey as PBEKey. Does it make any problem? >> >> > From sean.coffey at oracle.com Thu Aug 2 16:37:05 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 2 Aug 2018 17:37:05 +0100 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: <9FFFEE9C-C14B-4A05-A3A5-61340045C42A@oracle.com> References:

<55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com>

<8c3163d7-663a-0c07-f6bc-d732c83bc5ae@oracle.com> <9FFFEE9C-C14B-4A05-A3A5-61340045C42A@oracle.com> Message-ID: <4de66122-69c8-7936-87f6-45fcedf6678c@oracle.com> All valid comments Max. Changes made. Webrev at http://cr.openjdk.java.net/~coffeys/webrev.8208583.v4/webrev/index.html > I wonder why DestroyedFailedException was a checked exception, what can we do if it's thrown? I guess we could log a message, but given the limited usage case here, I don't see a need. regards, Sean. On 02/08/2018 17:05, Weijun Wang wrote: > KeyProtector.java: > > 113 pbeKeySpec.clearPassword(); > > You can also put this into the finally block. > > 189 Arrays.fill(plain, (byte) 0x00); > > Can this be in finally? > > JavaKeyStore.java: > > 149 Arrays.fill(passwordBytes, (byte) 0x00); > > In other cases, you call it in a finally block. Unnecessary here? > > (Oops, every comment is about finally.) > > KeyProtector.java: > > 123 public KeyProtector(byte[] password) > > How about just "public KeyProtector(byte[] passwordBytes)"? > >> On Aug 2, 2018, at 7:38 PM, Se?n Coffey wrote: >> >> No - no problem at all. Some extra exception handling but probably best for the long run. > I wonder why DestroyedFailedException was a checked exception, what can we do if it's thrown? > > Thanks > Max > >> http://cr.openjdk.java.net/~coffeys/webrev.8208583.v3/webrev/index.html >> >> regards, >> Sean. >> >> On 02/08/2018 02:13, Weijun Wang wrote: >>>> 1. >>>> >>>> I wasn't able to rename to destroy since that method is reserved for the Destroyable interface. I've gone with destroyKey. >>>> >>> Sorry I wasn't clear but this is exactly what I meant. SecretKey implements Destroyable so you don't need to define sKey as PBEKey. Does it make any problem? >>> >>> From amanda.jiang at oracle.com Thu Aug 2 23:57:37 2018 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 2 Aug 2018 16:57:37 -0700 Subject: RFR 8207783: PoodleSSLv3 test update for TLSv1.2 and TLSv1.3 Message-ID: Hi All, Please help to review the changeset below, which update PoodleSSLv3 test for newer protocol versions http://sqeweb.us.oracle.com/net/scanas415/export/corelibs/users/amjiang/webrev/8207783/webrev.00/ Thanks, Amanda From sha.jiang at oracle.com Fri Aug 3 01:50:48 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 3 Aug 2018 09:50:48 +0800 Subject: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. In-Reply-To: <078fa675-1fe8-4ef9-bb5a-5b3711b682ec@default> References: <078fa675-1fe8-4ef9-bb5a-5b3711b682ec@default> Message-ID: Hi Siba, Would it be better to check how many connections the server accepts? In your case, the server must accept 50 (no more no less) connections; otherwise, some problem may raise. And I suppose, when the server thread is interrupted, the server socket may not be closed. The server should exit immediately and gracefully when it has accepted all the connections. If the server can be closed gracefully, it may be no need to set the server thread as daemon. Some minors: -- 28 import java.net.SocketException; This import statement looks unused. -- 131 sslSocket.setNeedClientAuth(false); Now that client auth is not requested by default, so it may be unnecessary to set false value explicitly. Best regards, John Jiang On 2018/8/2 18:41, Sibabrata Sahoo wrote: > > Hi Xuelei, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208496 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.00/ > > > This is a new Test which test concurrent behavior of TLS. It uses 50 > client thread to access a single server port concurrently and repeat > this process for each protocol supported. > > Thanks, > > Siba > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Fri Aug 3 04:23:55 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 2 Aug 2018 21:23:55 -0700 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: <175c2846-99b3-14bb-2736-66e8a7dd5c65@oracle.com> References:

<55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com>

<8c3163d7-663a-0c07-f6bc-d732c83bc5ae@oracle.com> <9FFFEE9C-C14B-4A05-A3A5-61340045C42A@oracle.com> <4de66122-69c8-7936-87f6-45fcedf6678c@oracle.com> Message-ID: <8A895952-84E9-4141-AF99-37DADDDE9586@oracle.com> com/sun/crypto/provider/KeyProtector.java: 187 Key k = kFac.generatePrivate(new PKCS8EncodedKeySpec(plain)); 188 return k; No need to create a local variable "k" anymore. JavaKeyStore.java: 128 byte[] passwordBytes = null; No need to define so early and assigned null. No other comments. > On Aug 3, 2018, at 12:37 AM, Se?n Coffey wrote: > > All valid comments Max. Changes made. Webrev at > > http://cr.openjdk.java.net/~coffeys/webrev.8208583.v4/webrev/index.html > >> I wonder why DestroyedFailedException was a checked exception, what can we do if it's thrown? > I guess we could log a message, but given the limited usage case here, I don't see a need. I was not clear, I meant I cannot find a proper action to do in this case, thus it might be better to defined as an unchecked exception. Thanks Max > > regards, > Sean. > > > On 02/08/2018 17:05, Weijun Wang wrote: >> KeyProtector.java: >> >> 113 pbeKeySpec.clearPassword(); >> >> You can also put this into the finally block. >> >> 189 Arrays.fill(plain, (byte) 0x00); >> >> Can this be in finally? >> >> JavaKeyStore.java: >> >> 149 Arrays.fill(passwordBytes, (byte) 0x00); >> >> In other cases, you call it in a finally block. Unnecessary here? >> >> (Oops, every comment is about finally.) >> >> KeyProtector.java: >> >> 123 public KeyProtector(byte[] password) >> >> How about just "public KeyProtector(byte[] passwordBytes)"? >> >>> On Aug 2, 2018, at 7:38 PM, Se?n Coffey wrote: >>> >>> No - no problem at all. Some extra exception handling but probably best for the long run. >> I wonder why DestroyedFailedException was a checked exception, what can we do if it's thrown? >> >> Thanks >> Max >> >>> http://cr.openjdk.java.net/~coffeys/webrev.8208583.v3/webrev/index.html >>> >>> regards, >>> Sean. >>> >>> On 02/08/2018 02:13, Weijun Wang wrote: >>>>> 1. >>>>> >>>>> I wasn't able to rename to destroy since that method is reserved for the Destroyable interface. I've gone with destroyKey. >>>>> >>>> Sorry I wasn't clear but this is exactly what I meant. SecretKey implements Destroyable so you don't need to define sKey as PBEKey. Does it make any problem? >>>> >>>> > From sibabrata.sahoo at oracle.com Fri Aug 3 09:32:01 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 3 Aug 2018 02:32:01 -0700 (PDT) Subject: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. In-Reply-To: References: <078fa675-1fe8-4ef9-bb5a-5b3711b682ec@default> Message-ID: <9e183b2e-1323-46f9-b4f5-846269952282@default> Hi Xuelei/John, I did a minor change to handle graceful shutdown of server thread along with handling timeout for long waiting accept(). Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.01/ Thanks, Siba From: John Jiang Sent: Friday, August 03, 2018 7:21 AM To: Sibabrata Sahoo Cc: Xue-Lei Fan ; security-dev at openjdk.java.net Subject: Re: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. Hi Siba, Would it be better to check how many connections the server accepts? In your case, the server must accept 50 (no more no less) connections; otherwise, some problem may raise. And I suppose, when the server thread is interrupted, the server socket may not be closed. The server should exit immediately and gracefully when it has accepted all the connections. If the server can be closed gracefully, it may be no need to set the server thread as daemon. Some minors: -- 28 import java.net.SocketException; This import statement looks unused. -- 131 sslSocket.setNeedClientAuth(false); Now that client auth is not requested by default, so it may be unnecessary to set false value explicitly. Best regards, John Jiang On 2018/8/2 18:41, Sibabrata Sahoo wrote: Hi Xuelei, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8208496 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Essahoo/8208496/webrev.00/"http://cr.openjdk.java.net/~ssahoo/8208496/webrev.00/ This is a new Test which test concurrent behavior of TLS. It uses 50 client thread to access a single server port concurrently and repeat this process for each protocol supported. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Aug 3 09:41:07 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 3 Aug 2018 10:41:07 +0100 Subject: RFR: 8208583: Better management of internal KeyStore buffers In-Reply-To: <8A895952-84E9-4141-AF99-37DADDDE9586@oracle.com> References:

<55b44af0-173f-1be2-b4c9-1b88b68253e3@oracle.com>

<8c3163d7-663a-0c07-f6bc-d732c83bc5ae@oracle.com> <9FFFEE9C-C14B-4A05-A3A5-61340045C42A@oracle.com> <4de66122-69c8-7936-87f6-45fcedf6678c@oracle.com> <8A895952-84E9-4141-AF99-37DADDDE9586@oracle.com> Message-ID: <3e27237d-19b6-c094-2cdc-eb9c77189c0b@oracle.com> Thanks for your review Weijun. I'll update with your comments [1] and push shortly. regards, Sean. [1] com/sun/crypto/provider/KeyProtector.java: (reverted to as was) 187: KeyFactory kFac = KeyFactory.getInstance(oidName); return kFac.generatePrivate(new PKCS8EncodedKeySpec(plain)); ====== JavaKeyStore.java: @@ -133,18 +133,20 @@ throw new UnrecoverableKeyException("Password must not be null"); } - KeyProtector keyProtector = new KeyProtector(password); + byte[] passwordBytes = convertToBytes(password); + KeyProtector keyProtector = new KeyProtector(passwordBytes); Regards, Sean. On 03/08/18 10:05, Weijun Wang wrote: > com/sun/crypto/provider/KeyProtector.java: > > 187 Key k = kFac.generatePrivate(new PKCS8EncodedKeySpec(plain)); > 188 return k; > > No need to create a local variable "k" anymore. > > JavaKeyStore.java: > > 128 byte[] passwordBytes = null; > > No need to define so early and assigned null. > > No other comments. > >> On Aug 3, 2018, at 12:37 AM, Se?n Coffey wrote: >> >> All valid comments Max. Changes made. Webrev at >> >> http://cr.openjdk.java.net/~coffeys/webrev.8208583.v4/webrev/index.html >> >>> I wonder why DestroyedFailedException was a checked exception, what can we do if it's thrown? >> I guess we could log a message, but given the limited usage case here, I don't see a need. > I was not clear, I meant I cannot find a proper action to do in this case, thus it might be better to defined as an unchecked exception. > > Thanks > Max > >> regards, >> Sean. >> >> >> On 02/08/2018 17:05, Weijun Wang wrote: >>> KeyProtector.java: >>> >>> 113 pbeKeySpec.clearPassword(); >>> >>> You can also put this into the finally block. >>> >>> 189 Arrays.fill(plain, (byte) 0x00); >>> >>> Can this be in finally? >>> >>> JavaKeyStore.java: >>> >>> 149 Arrays.fill(passwordBytes, (byte) 0x00); >>> >>> In other cases, you call it in a finally block. Unnecessary here? >>> >>> (Oops, every comment is about finally.) >>> >>> KeyProtector.java: >>> >>> 123 public KeyProtector(byte[] password) >>> >>> How about just "public KeyProtector(byte[] passwordBytes)"? >>> >>>> On Aug 2, 2018, at 7:38 PM, Se?n Coffey wrote: >>>> >>>> No - no problem at all. Some extra exception handling but probably best for the long run. >>> I wonder why DestroyedFailedException was a checked exception, what can we do if it's thrown? >>> >>> Thanks >>> Max >>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8208583.v3/webrev/index.html >>>> >>>> regards, >>>> Sean. >>>> >>>> On 02/08/2018 02:13, Weijun Wang wrote: >>>>>> 1. >>>>>> >>>>>> I wasn't able to rename to destroy since that method is reserved for the Destroyable interface. I've gone with destroyKey. >>>>>> >>>>> Sorry I wasn't clear but this is exactly what I meant. SecretKey implements Destroyable so you don't need to define sKey as PBEKey. Does it make any problem? >>>>> >>>>> From sean.coffey at oracle.com Fri Aug 3 10:49:49 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 3 Aug 2018 11:49:49 +0100 Subject: RFR: jdk8u : 8208583: Better management of internal KeyStore buffers Message-ID: <777b6bc2-cc30-d431-9f0a-787eeb9ea73a@oracle.com> Max, I've applied the same patch to jdk8u-dev. It's pretty much a straightforward port. Some small parts didn't apply cleanly since jdk8u doesn't involve use of Finalizer/Cleaner in some areas. i.e. around line 80 : src/share/classes/com/sun/crypto/provider/PBEKey.java and in constructor of src/share/classes/sun/security/provider/KeyProtector.java http://cr.openjdk.java.net/~coffeys/webrev.8208583.8u/webrev/ Would appreciate your review. -- Regards, Sean. From weijun.wang at oracle.com Fri Aug 3 11:14:46 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 3 Aug 2018 19:14:46 +0800 Subject: RFR: jdk8u : 8208583: Better management of internal KeyStore buffers In-Reply-To: <777b6bc2-cc30-d431-9f0a-787eeb9ea73a@oracle.com> References: <777b6bc2-cc30-d431-9f0a-787eeb9ea73a@oracle.com> Message-ID: <497890E6-DF1E-4549-A9FF-0EAEB25C56B0@oracle.com> Why does PBEKey::new still have a useClear parameter then? > On Aug 3, 2018, at 6:49 PM, Se?n Coffey wrote: > > Max, > > I've applied the same patch to jdk8u-dev. It's pretty much a straightforward port. Some small parts didn't apply cleanly since jdk8u doesn't involve use of Finalizer/Cleaner in some areas. > > i.e. > > around line 80 : src/share/classes/com/sun/crypto/provider/PBEKey.java > and in constructor of src/share/classes/sun/security/provider/KeyProtector.java > > http://cr.openjdk.java.net/~coffeys/webrev.8208583.8u/webrev/ > > Would appreciate your review. > > -- > Regards, > Sean. > From sean.coffey at oracle.com Fri Aug 3 12:49:44 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 3 Aug 2018 13:49:44 +0100 Subject: RFR: jdk8u : 8208583: Better management of internal KeyStore buffers In-Reply-To: <497890E6-DF1E-4549-A9FF-0EAEB25C56B0@oracle.com> References: <777b6bc2-cc30-d431-9f0a-787eeb9ea73a@oracle.com> <497890E6-DF1E-4549-A9FF-0EAEB25C56B0@oracle.com> Message-ID: Whoops! Patching too fast. Yes- that field is redundant for jdk8u. I've removed its use. Webrev updated in place. Regards, Sean. On 03/08/18 12:14, Weijun Wang wrote: > Why does PBEKey::new still have a useClear parameter then? > >> On Aug 3, 2018, at 6:49 PM, Se?n Coffey wrote: >> >> Max, >> >> I've applied the same patch to jdk8u-dev. It's pretty much a straightforward port. Some small parts didn't apply cleanly since jdk8u doesn't involve use of Finalizer/Cleaner in some areas. >> >> i.e. >> >> around line 80 : src/share/classes/com/sun/crypto/provider/PBEKey.java >> and in constructor of src/share/classes/sun/security/provider/KeyProtector.java >> >> http://cr.openjdk.java.net/~coffeys/webrev.8208583.8u/webrev/ >> >> Would appreciate your review. >> >> -- >> Regards, >> Sean. >> From weijun.wang at oracle.com Fri Aug 3 13:02:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 3 Aug 2018 21:02:17 +0800 Subject: RFR: jdk8u : 8208583: Better management of internal KeyStore buffers In-Reply-To: References: <777b6bc2-cc30-d431-9f0a-787eeb9ea73a@oracle.com> <497890E6-DF1E-4549-A9FF-0EAEB25C56B0@oracle.com> Message-ID: <0A1E35F7-4A4C-488A-9B3E-AA0C67A2574A@oracle.com> You don't need to modify PBEKeyFactory.java anymore. Everything else is fine. --Max > On Aug 3, 2018, at 8:49 PM, Se?n Coffey wrote: > > Whoops! Patching too fast. Yes- that field is redundant for jdk8u. > > I've removed its use. Webrev updated in place. > > Regards, > Sean. > > On 03/08/18 12:14, Weijun Wang wrote: >> Why does PBEKey::new still have a useClear parameter then? >> >>> On Aug 3, 2018, at 6:49 PM, Se?n Coffey wrote: >>> >>> Max, >>> >>> I've applied the same patch to jdk8u-dev. It's pretty much a straightforward port. Some small parts didn't apply cleanly since jdk8u doesn't involve use of Finalizer/Cleaner in some areas. >>> >>> i.e. >>> >>> around line 80 : src/share/classes/com/sun/crypto/provider/PBEKey.java >>> and in constructor of src/share/classes/sun/security/provider/KeyProtector.java >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8208583.8u/webrev/ >>> >>> Would appreciate your review. >>> >>> -- >>> Regards, >>> Sean. >>> > From sean.coffey at oracle.com Fri Aug 3 13:05:31 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 3 Aug 2018 14:05:31 +0100 Subject: RFR: jdk8u : 8208583: Better management of internal KeyStore buffers In-Reply-To: <0A1E35F7-4A4C-488A-9B3E-AA0C67A2574A@oracle.com> References: <777b6bc2-cc30-d431-9f0a-787eeb9ea73a@oracle.com> <497890E6-DF1E-4549-A9FF-0EAEB25C56B0@oracle.com> <0A1E35F7-4A4C-488A-9B3E-AA0C67A2574A@oracle.com> Message-ID: Thanks. Regards, Sean. On 03/08/18 14:02, Weijun Wang wrote: > You don't need to modify PBEKeyFactory.java anymore. Everything else is fine. > > --Max > >> On Aug 3, 2018, at 8:49 PM, Se?n Coffey wrote: >> >> Whoops! Patching too fast. Yes- that field is redundant for jdk8u. >> >> I've removed its use. Webrev updated in place. >> >> Regards, >> Sean. >> >> On 03/08/18 12:14, Weijun Wang wrote: >>> Why does PBEKey::new still have a useClear parameter then? >>> >>>> On Aug 3, 2018, at 6:49 PM, Se?n Coffey wrote: >>>> >>>> Max, >>>> >>>> I've applied the same patch to jdk8u-dev. It's pretty much a straightforward port. Some small parts didn't apply cleanly since jdk8u doesn't involve use of Finalizer/Cleaner in some areas. >>>> >>>> i.e. >>>> >>>> around line 80 : src/share/classes/com/sun/crypto/provider/PBEKey.java >>>> and in constructor of src/share/classes/sun/security/provider/KeyProtector.java >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8208583.8u/webrev/ >>>> >>>> Would appreciate your review. >>>> >>>> -- >>>> Regards, >>>> Sean. >>>> From xuelei.fan at oracle.com Fri Aug 3 17:08:12 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 Aug 2018 10:08:12 -0700 Subject: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. In-Reply-To: <9e183b2e-1323-46f9-b4f5-846269952282@default> References: <078fa675-1fe8-4ef9-bb5a-5b3711b682ec@default> <9e183b2e-1323-46f9-b4f5-846269952282@default> Message-ID: <9c46687e-ab8b-c5b6-226a-fbbc61188331@oracle.com> Hi Siba, The use of SO_TIMEOUT may cause intermittent failure in JDK test environment. I'm not very sure if serverSocket.close() and serverSocket.accept() are synchronized or not. If they did, there may be a dead waiting condition. Xuelei On 8/3/2018 2:32 AM, Sibabrata Sahoo wrote: > Hi Xuelei/John, > > I did a minor change to handle graceful shutdown of server thread along > with handling timeout for long waiting accept(). > > Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.01/ > > > Thanks, > > Siba > > *From:*John Jiang > *Sent:* Friday, August 03, 2018 7:21 AM > *To:* Sibabrata Sahoo > *Cc:* Xue-Lei Fan ; security-dev at openjdk.java.net > *Subject:* Re: [11] RFR: 8208496: New Test to verify concurrent behavior > for TLS. > > Hi Siba, > Would it be better to check how many connections the server accepts? > In your case, the server must accept 50 (no more no less) connections; > otherwise, some problem may raise. > > And I suppose, when the server thread is interrupted, the server socket > may not be closed. > The server should exit immediately and gracefully when it has accepted > all the connections. > If the server can be closed gracefully, it may be no need to set the > server thread as daemon. > > Some minors: > -- 28 import java.net.SocketException; > This import statement looks unused. > > -- 131 sslSocket.setNeedClientAuth(false); > Now that client auth is not requested by default, so it may be > unnecessary to set false value explicitly. > > Best regards, > John Jiang > > On 2018/8/2 18:41, Sibabrata Sahoo wrote: > > Hi Xuelei, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208496 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.00/ > > > This is a new Test which test concurrent behavior of TLS. It uses 50 > client thread to access a single server port concurrently and repeat > this process for each protocol supported. > > Thanks, > > Siba > From sibabrata.sahoo at oracle.com Fri Aug 3 17:50:56 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 3 Aug 2018 10:50:56 -0700 (PDT) Subject: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. In-Reply-To: <9c46687e-ab8b-c5b6-226a-fbbc61188331@oracle.com> References: <078fa675-1fe8-4ef9-bb5a-5b3711b682ec@default> <9e183b2e-1323-46f9-b4f5-846269952282@default> <9c46687e-ab8b-c5b6-226a-fbbc61188331@oracle.com> Message-ID: serverSocket.close() and serverSocket.accept() are not declared synchronized in java/net/ServerSocket.java. Thanks, Siba -----Original Message----- From: Xuelei Fan Sent: Friday, August 03, 2018 10:38 PM To: Sibabrata Sahoo ; John Jiang Cc: security-dev at openjdk.java.net Subject: Re: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. Hi Siba, The use of SO_TIMEOUT may cause intermittent failure in JDK test environment. I'm not very sure if serverSocket.close() and serverSocket.accept() are synchronized or not. If they did, there may be a dead waiting condition. Xuelei On 8/3/2018 2:32 AM, Sibabrata Sahoo wrote: > Hi Xuelei/John, > > I did a minor change to handle graceful shutdown of server thread > along with handling timeout for long waiting accept(). > > Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.01/ > > > Thanks, > > Siba > > *From:*John Jiang > *Sent:* Friday, August 03, 2018 7:21 AM > *To:* Sibabrata Sahoo > *Cc:* Xue-Lei Fan ; > security-dev at openjdk.java.net > *Subject:* Re: [11] RFR: 8208496: New Test to verify concurrent > behavior for TLS. > > Hi Siba, > Would it be better to check how many connections the server accepts? > In your case, the server must accept 50 (no more no less) connections; > otherwise, some problem may raise. > > And I suppose, when the server thread is interrupted, the server > socket may not be closed. > The server should exit immediately and gracefully when it has accepted > all the connections. > If the server can be closed gracefully, it may be no need to set the > server thread as daemon. > > Some minors: > -- 28 import java.net.SocketException; This import statement looks > unused. > > -- 131 sslSocket.setNeedClientAuth(false); > Now that client auth is not requested by default, so it may be > unnecessary to set false value explicitly. > > Best regards, > John Jiang > > On 2018/8/2 18:41, Sibabrata Sahoo wrote: > > Hi Xuelei, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208496 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.00/ > > > This is a new Test which test concurrent behavior of TLS. It uses 50 > client thread to access a single server port concurrently and repeat > this process for each protocol supported. > > Thanks, > > Siba > From xuelei.fan at oracle.com Fri Aug 3 18:02:54 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 Aug 2018 11:02:54 -0700 Subject: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. In-Reply-To: References: <078fa675-1fe8-4ef9-bb5a-5b3711b682ec@default> <9e183b2e-1323-46f9-b4f5-846269952282@default> <9c46687e-ab8b-c5b6-226a-fbbc61188331@oracle.com> Message-ID: It looks fine to me, then. Thanks, Xuelei On 8/3/2018 10:50 AM, Sibabrata Sahoo wrote: > serverSocket.close() and serverSocket.accept() are not declared synchronized in java/net/ServerSocket.java. > > Thanks, > Siba > > -----Original Message----- > From: Xuelei Fan > Sent: Friday, August 03, 2018 10:38 PM > To: Sibabrata Sahoo ; John Jiang > Cc: security-dev at openjdk.java.net > Subject: Re: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS. > > Hi Siba, > > The use of SO_TIMEOUT may cause intermittent failure in JDK test environment. I'm not very sure if serverSocket.close() and > serverSocket.accept() are synchronized or not. If they did, there may be a dead waiting condition. > > Xuelei > > On 8/3/2018 2:32 AM, Sibabrata Sahoo wrote: >> Hi Xuelei/John, >> >> I did a minor change to handle graceful shutdown of server thread >> along with handling timeout for long waiting accept(). >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.01/ >> >> >> Thanks, >> >> Siba >> >> *From:*John Jiang >> *Sent:* Friday, August 03, 2018 7:21 AM >> *To:* Sibabrata Sahoo >> *Cc:* Xue-Lei Fan ; >> security-dev at openjdk.java.net >> *Subject:* Re: [11] RFR: 8208496: New Test to verify concurrent >> behavior for TLS. >> >> Hi Siba, >> Would it be better to check how many connections the server accepts? >> In your case, the server must accept 50 (no more no less) connections; >> otherwise, some problem may raise. >> >> And I suppose, when the server thread is interrupted, the server >> socket may not be closed. >> The server should exit immediately and gracefully when it has accepted >> all the connections. >> If the server can be closed gracefully, it may be no need to set the >> server thread as daemon. >> >> Some minors: >> -- 28 import java.net.SocketException; This import statement looks >> unused. >> >> -- 131 sslSocket.setNeedClientAuth(false); >> Now that client auth is not requested by default, so it may be >> unnecessary to set false value explicitly. >> >> Best regards, >> John Jiang >> >> On 2018/8/2 18:41, Sibabrata Sahoo wrote: >> >> Hi Xuelei, >> >> Please review the patch for, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208496 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.00/ >> >> >> This is a new Test which test concurrent behavior of TLS. It uses 50 >> client thread to access a single server port concurrently and repeat >> this process for each protocol supported. >> >> Thanks, >> >> Siba >> From xuelei.fan at oracle.com Fri Aug 3 20:55:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 Aug 2018 13:55:10 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com>

Message-ID: Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ In webrev.01, the socket close may be blocked by super class close synchronization. Updated the SSLSocketImpl.java to use handshake only lock in the startHandshake() implementation. Thanks, Xuelei On 8/1/2018 7:27 PM, Xuelei Fan wrote: > Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ > > Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 > renegotiation fails if Java client allows TLSv1.3".? SSLHandshake.java > is updated to use negotiated version so that TLS 1.2 HelloRequest is > acceptable in TLS 1.3 client side. > > Thanks, > Xuelei > > On 7/30/2018 10:24 AM, Xuelei Fan wrote: >> >> Please let me know your concerns by the end of August 1st, 2018. >> >> Thanks, >> Xuelei >> >> >> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the update for the TLS 1.3 half-close and >>> synchronization implementation: >>> ??? http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>> >>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify is >>> use to close the local write side and peer read side only.? After the >>> close_notify get handles, the local read side and peer write side may >>> still be open. >>> >>> In this update, if an application calls >>> SSLEngine.closeInbound/Outbound() or >>> SSLSocket.shutdownInput/Output(), half-close will be used.? For >>> compatibility, if SSLSocket.close() get called, a duplex close will >>> be tried.? In order to support duplex close, JDK will use the >>> user_canceled warning alert even the handshake complete. >>> >>> In practice, an application may only close outbound even it is >>> intended to close the inbound as well, or close the connection >>> completely.? It works for TLS 1.2 and prior versions.? But no more >>> for TLS 1.3 because of the close_notify behavior change in the TLS >>> 1.3 specification.? The application may be hung and dead-waiting for >>> read/close.? It could be solved by closing the inbound explicitly. >>> In order to mitigate the impact, a new System Property is introduced, >>> "jdk.tls.acknowledgeCloseNotify" if source code update is not >>> available. ??If the System Property is set to "true", if receiving >>> the close_notify, a close_notify alert will be responded.? It is a >>> countermeasure of the TLS 1.3 half-close issues. >>> >>> Thanks, >>> Xuelei >>> >>> >>> From mbalao at redhat.com Fri Aug 3 21:13:54 2018 From: mbalao at redhat.com (Martin Balao) Date: Fri, 3 Aug 2018 18:13:54 -0300 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References:

Message-ID: Hi Valerie, * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/ * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip New in webrev 10: * Bug fix when private DSA/EC keys are sensitive * I found this bug removing "attributes = compatibility" entry in NSS configuration file so keys were CKA_SENSITIVE. * This is really an NSS bug when unwrapping ephemeral keys (NSC_UnwrapKey function), because CKA_NETSCAPE_DB attribute is required but not used/needed. There was a similar bug when creating objects (NSC_CreateObject function), fixed many years ago [1]. * In those cases in which the bug occurs (private keys, of DSA/EC type, sensitive and without CKA_NETSCAPE_DB attribute set), I store an empty CKA_NETSCAPE_DB attribute in the buffer that will later be used for key unwrapping. I'm not doing a C_SetAttributeValue call because keys are read-only. We can let users set CKA_NETSCAPE_DB attribute in NSS configuration file [2] but this would be a workaround on users side. * Changes in: * p11_keymgmt.c * L175-187, L212-214 and L275-278 * Bug fix when storing sensitive RSA keys in a keystore * CKA_NETSCAPE_DB attribute is not needed so we return it as null (instead of failing with an "Invalid algorithm" message) * Changes in: * P11KeyStore.java * L1909-1914 * Lines length was cut to improve code readability Regression tests on jdk/sun/security/pkcs11 category passed. I ran my internal test suite too, that covers the following services (with SunPKCS11 provider): Cipher, Signature, KeyAgreement, Digest, Mac, KeyGenerator, KeyPairGenerator and Keystore. Kind regards, Martin.- -- [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=309701#c6 [2] - https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/ test/sun/security/pkcs11/fips/fips.cfg.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From timbrooks at fastmail.com Wed Aug 1 00:09:33 2018 From: timbrooks at fastmail.com (Tim Brooks) Date: Tue, 31 Jul 2018 18:09:33 -0600 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> References:

<8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> Message-ID: Yes I should be able to take a look this week. > On Jul 30, 2018, at 12:13 PM, Xuelei Fan wrote: > > Hi Tim, > > Would you mind look at the code I posted in the following thread: > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html > > In the update, we are trying make the synchronization more simple and robust. I appreciate if you could comment by the end of this week. > > Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way because TLS 1.2 and prior version can work around it. But for TLS 1.3, it is possible to hang the application if the connection is not closed. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. > > Thanks, > Xuelei > > On 7/18/2018 11:51 AM, Tim Brooks wrote: >> Yes. I can test once there is a patch. My inquiry was motivated by some work on Elasticsearch fyi. I can test a patch against that work. >> https://github.com/elastic/elasticsearch/issues/32144 >> - Tim >>> On Jul 17, 2018, at 8:40 PM, Xuelei Fan > wrote: >>> >>> Hi, >>> >>> We are working on the JDK 11 close issue. >>> https://bugs.openjdk.java.net/browse/JDK-8207009 >>> >>> I appreciate if you can help test if we have a patch. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/17/2018 4:26 PM, Tim Brooks wrote: >>>> My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. >>>> One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: >>>> 1. Initiate handshake >>>> 2. UNWRAP data from client >>>> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >>>> 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). >>>> 5. Handshake status now returns "NEED_WRAP" >>>> JDK10: >>>> isInboundDone() - returns false >>>> isOutboundDone() - returns false >>>> A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. >>>> isInboundDone() - returns false >>>> isOutboundDone() - returns true >>>> JDK11: >>>> isInboundDone() - returns true >>>> isOutboundDone() - returns false >>>> A call to wrap() throws the following exception: >>>> javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed >>>> at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >>>> at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >>>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >>>> I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. From timbrooks at fastmail.com Sat Aug 4 00:04:19 2018 From: timbrooks at fastmail.com (Tim Brooks) Date: Fri, 3 Aug 2018 18:04:19 -0600 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> References:

<8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> Message-ID: Hi Xuelei I pulled the JDK 11 source today and applied your patch. And then I built the jdk to run some tests. I hope that is the correct approach. It appears that this change resolved some of my prior issues. But I notice some other issues. This is tested with TLS 1.2. I have not really setup my environment yet for TLS 1.3, so I was not able to test that code path. I have -Djavax.net.debug=all enabled. However, I have pruned some of messages from this email to reduce text. If you need more let me know. Client: 1. ClientHello.java:633|Produced ClientHello handshake message 2. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 204 Server: 3. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 204 4. ClientHello.java:788|Consuming ClientHello handshake message 5. ClientHello.java:818|Negotiated protocol version: TLSv1.2 6. ServerHello.java:361|Produced ServerHello handshake message 7. CertificateMessage.java:263|Produced server Certificate handshake message 8. ServerHelloDone.java:97|Produced ServerHelloDone handshake message 9. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 1086 Client: 10. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 1086 11. ServerHello.java:862|Consuming ServerHello handshake message 12. ServerHello.java:958|Negotiated protocol version: TLSv1.2 13. CertificateMessage.java:358|Consuming server Certificate handshake message 14. ServerHelloDone.java:142|Consuming ServerHelloDone handshake message 15. RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange handshake message 16. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message 17. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message 18. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 262 19. SSLEngineOutputRecord.java:465|WRITE: TLS12 change_cipher_spec, length = 1 20. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 16 At this point I do not send that data yet to the server. The client has produced the client key exchange and client finished messages. But they are still in transit (in this scenario). Server (we manually call closeOutboud() because we have decided we need to close this socket): 21. SSLEngineImpl.java:745|Closing outbound of SSLEngine 22. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 23. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 5A ......Z) - I believe this is user_canceled alert 24. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 00 .......) - I believe this is close_notify At this point: Server engine.isOutboundDone() = true Server engine.isInboundDone() = false Client: 24. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 25. Alert.java:232|Received alert message ("Alert": {"level" : "warning", "description": "user_canceled"}) 26. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 27. Alert.java:232|Received alert message ("Alert": {"level": "warning", "description": "close_notify"}) 28. Fatal (UNEXPECTED_MESSAGE): Received close_notify during handshake ( "throwable" : { javax.net.ssl.SSLProtocolException: Received close_notify during handshake at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) At this point I want to note that it feels weird that this produces an exception. The other side said "user_canceled" and then sent "close_notify". That seems correct to me? So it feels weird that consumers of the SSlEngine have to handle this exception and then continue using the engine for a proper close. That's just a side note. I (think) this behavior is not new. But it seems odd. At this point: Client engine.isOutboundDone() = false Client engine.isInboundDone() = true Still Client: 29. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 30. SSLCipher.java:1726|Plaintext before ENCRYPTION (0000: 02 0A ..) 31. 2018-08-04 05:16:34.300 KGT|SSLEngineOutputRecord.java:483|Raw write ( 0000: 15 03 03 00 1A 00 00 00 00 00 00 00 01 E2 36 F9 ..............6. 0010: 09 D2 20 65 B5 C9 04 CB D3 47 8B E2 CA 0B B2 .. e.....G..... ) - I believe this is unexpected_message. And I believe it is encrypted at this point as the client has sent the client finished message. This alert feels incorrect to me. The server sent "user_canceled". I feel like once that is sent, we should be able to receive "close_notify" without the client engine identifying this as an unexpected message. At this point: Client engine.isOutboundDone() = true Client engine.isInboundDone() = true That seems correct to me. We need to flush the last alert for the client and then we are done with the engine (although I believe the alert should be close_notify and not unexpected_message). At this point the server starts receiving all the handshake messages from the client. Server: 32. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 262 33. RSAClientKeyExchange.java:279|Consuming RSA ClientKeyExchange handshake message 34. SSLEngineInputRecord.java:214|READ: TLSv1.2 change_cipher_spec, length = 1 35. ChangeCipherSpec.java:143|Consuming ChangeCipherSpec message 36. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 40 37. Finished.java:581|Consuming client Finished handshake message. At this point: Server engine.isOutboundDone() = false Server engine.isInboundDone() = false That seems completely wrong to me. We manually told the server outbound was done. But receiving the final handshake messages has put it back to outbound not being done. Additionally, at this point the server's handshake status is NEED_WRAP and NEED_TASK. It looks like it is trying to continue handshaking. Still Server: 38. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message 39. Finished.java:450|Produced server Finished handshake message 40. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 26 41. Alert.java:232|Received alert message 42. TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Received fatal alert: unexpected_message ( "throwable" : { javax.net.ssl.SSLProtocolException: Received fatal alert: unexpected_message at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:281) At this point the server engine has received the alert. That throws an exception. And the engine still seems to be in an incorrect "done" state. At this point: Server engine.isOutboundDone() = false Server engine.isInboundDone() = true Let me know if you have any questions. The particular point where we send close_notify from the server to the client is just incidental from how our "close during handshake" test works. Sending it at other points in the handshake process may produce different outcomes. Thanks, Tim > On Jul 30, 2018, at 12:13 PM, Xuelei Fan wrote: > > Hi Tim, > > Would you mind look at the code I posted in the following thread: > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html > > In the update, we are trying make the synchronization more simple and robust. I appreciate if you could comment by the end of this week. > > Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way because TLS 1.2 and prior version can work around it. But for TLS 1.3, it is possible to hang the application if the connection is not closed. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. > > Thanks, > Xuelei > > On 7/18/2018 11:51 AM, Tim Brooks wrote: >> Yes. I can test once there is a patch. My inquiry was motivated by some work on Elasticsearch fyi. I can test a patch against that work. >> https://github.com/elastic/elasticsearch/issues/32144 >> - Tim >>> On Jul 17, 2018, at 8:40 PM, Xuelei Fan > wrote: >>> >>> Hi, >>> >>> We are working on the JDK 11 close issue. >>> https://bugs.openjdk.java.net/browse/JDK-8207009 >>> >>> I appreciate if you can help test if we have a patch. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/17/2018 4:26 PM, Tim Brooks wrote: >>>> My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. >>>> One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: >>>> 1. Initiate handshake >>>> 2. UNWRAP data from client >>>> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >>>> 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). >>>> 5. Handshake status now returns "NEED_WRAP" >>>> JDK10: >>>> isInboundDone() - returns false >>>> isOutboundDone() - returns false >>>> A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. >>>> isInboundDone() - returns false >>>> isOutboundDone() - returns true >>>> JDK11: >>>> isInboundDone() - returns true >>>> isOutboundDone() - returns false >>>> A call to wrap() throws the following exception: >>>> javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed >>>> at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >>>> at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >>>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >>>> I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. From valerie.peng at oracle.com Sat Aug 4 00:19:24 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 3 Aug 2018 17:19:24 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com>

<3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> <8601c0bb-0f73-76d6-8ad0-5f8dd3e788e0@oracle.com> <68B87EA5-6F86-4970-AB80-556D4783CF28@oracle.com> Message-ID: I can file a follow-on issue. However, I want to clarify what we want to do before filing it. Based on current exchanges: We want to update Cipher.getParameters()/CipherSpi.engineGetParameters() with similar format/wording as Signature.getParameters(), e.g. expanding the meaning when null is returned. In addition, we also need to change the part of "same parameters" due to this special PBE parameter handling behavior. Right? Thanks, Valerie On 7/31/2018 12:56 PM, Sean Mullan wrote: > On 7/24/18 9:38 PM, Weijun Wang wrote: >> Something related. >> >> Cipher has a similar init(..,params) and getParameters() structure >> and the spec is also similar. >> >> *

The returned parameters may be the same that were used to >> initialize >> * this cipher, or may contain a combination of default and random >> * parameter values used by the underlying cipher implementation if this >> * cipher requires algorithm parameters but was not initialized with any. >> >> However, one can supply an incomplete parameters object in init() and >> getParameters() will fill in default/random values to make it complete. >> >> For example, in PBE-based Cipher, one can only include salt and >> iteration count in the init params, and init() will add in a random >> IV, and the IV can be retrieved with getParameters(). >> >> Is this something we need to clarify? > > Yes, we should update the Cipher API to be consistent with Signature. > I think this can wait until JDK 12 though. > > Valerie, can you file a follow-on issue? > > Thanks, > Sean From xuelei.fan at oracle.com Sat Aug 4 00:47:19 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 Aug 2018 17:47:19 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> Message-ID: <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> Hi Tim, Your concerns make sense to me. Did you have a test case that I can use to reproduce the issues? Thanks, Xuelei On 8/3/2018 5:04 PM, Tim Brooks wrote: > Hi Xuelei > > I pulled the JDK 11 source today and applied your patch. And then I built the jdk to run some tests. I hope that is the correct approach. > > It appears that this change resolved some of my prior issues. But I notice some other issues. This is tested with TLS 1.2. I have not really setup my environment yet for TLS 1.3, so I was not able to test that code path. I have -Djavax.net.debug=all enabled. However, I have pruned some of messages from this email to reduce text. If you need more let me know. > > Client: > 1. ClientHello.java:633|Produced ClientHello handshake message > 2. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 204 > > Server: > 3. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 204 > 4. ClientHello.java:788|Consuming ClientHello handshake message > 5. ClientHello.java:818|Negotiated protocol version: TLSv1.2 > 6. ServerHello.java:361|Produced ServerHello handshake message > 7. CertificateMessage.java:263|Produced server Certificate handshake message > 8. ServerHelloDone.java:97|Produced ServerHelloDone handshake message > 9. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 1086 > > Client: > 10. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 1086 > 11. ServerHello.java:862|Consuming ServerHello handshake message > 12. ServerHello.java:958|Negotiated protocol version: TLSv1.2 > 13. CertificateMessage.java:358|Consuming server Certificate handshake message > 14. ServerHelloDone.java:142|Consuming ServerHelloDone handshake message > 15. RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange handshake message > 16. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message > 17. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message > 18. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 262 > 19. SSLEngineOutputRecord.java:465|WRITE: TLS12 change_cipher_spec, length = 1 > 20. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 16 > > At this point I do not send that data yet to the server. The client has produced the client key exchange and client finished messages. But they are still in transit (in this scenario). > > Server (we manually call closeOutboud() because we have decided we need to close this socket): > 21. SSLEngineImpl.java:745|Closing outbound of SSLEngine > 22. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 > 23. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 5A ......Z) > - I believe this is user_canceled alert > 24. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 00 .......) > - I believe this is close_notify > > At this point: > Server engine.isOutboundDone() = true > Server engine.isInboundDone() = false > > Client: > 24. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 > 25. Alert.java:232|Received alert message ("Alert": {"level" : "warning", "description": "user_canceled"}) > 26. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 > 27. Alert.java:232|Received alert message ("Alert": {"level": "warning", "description": "close_notify"}) > 28. Fatal (UNEXPECTED_MESSAGE): Received close_notify during handshake ( > "throwable" : { > javax.net.ssl.SSLProtocolException: Received close_notify during handshake > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) > at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) > > At this point I want to note that it feels weird that this produces an exception. The other side said "user_canceled" and then sent "close_notify". That seems correct to me? So it feels weird that consumers of the SSlEngine have to handle this exception and then continue using the engine for a proper close. That's just a side note. I (think) this behavior is not new. But it seems odd. > > At this point: > Client engine.isOutboundDone() = false > Client engine.isInboundDone() = true > > Still Client: > 29. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 > 30. SSLCipher.java:1726|Plaintext before ENCRYPTION (0000: 02 0A ..) > 31. 2018-08-04 05:16:34.300 KGT|SSLEngineOutputRecord.java:483|Raw write ( > 0000: 15 03 03 00 1A 00 00 00 00 00 00 00 01 E2 36 F9 ..............6. > 0010: 09 D2 20 65 B5 C9 04 CB D3 47 8B E2 CA 0B B2 .. e.....G..... > ) > - I believe this is unexpected_message. And I believe it is encrypted at this point as the client has sent the client finished message. This alert feels incorrect to me. The server sent "user_canceled". I feel like once that is sent, we should be able to receive "close_notify" without the client engine identifying this as an unexpected message. > > At this point: > Client engine.isOutboundDone() = true > Client engine.isInboundDone() = true > > That seems correct to me. We need to flush the last alert for the client and then we are done with the engine (although I believe the alert should be close_notify and not unexpected_message). > > At this point the server starts receiving all the handshake messages from the client. > > Server: > 32. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 262 > 33. RSAClientKeyExchange.java:279|Consuming RSA ClientKeyExchange handshake message > 34. SSLEngineInputRecord.java:214|READ: TLSv1.2 change_cipher_spec, length = 1 > 35. ChangeCipherSpec.java:143|Consuming ChangeCipherSpec message > 36. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 40 > 37. Finished.java:581|Consuming client Finished handshake message. > > At this point: > Server engine.isOutboundDone() = false > Server engine.isInboundDone() = false > > That seems completely wrong to me. We manually told the server outbound was done. But receiving the final handshake messages has put it back to outbound not being done. Additionally, at this point the server's handshake status is NEED_WRAP and NEED_TASK. It looks like it is trying to continue handshaking. > > Still Server: > > 38. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message > 39. Finished.java:450|Produced server Finished handshake message > 40. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 26 > 41. Alert.java:232|Received alert message > 42. TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Received fatal alert: unexpected_message ( > "throwable" : { > javax.net.ssl.SSLProtocolException: Received fatal alert: unexpected_message > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:281) > > At this point the server engine has received the alert. That throws an exception. And the engine still seems to be in an incorrect "done" state. > > At this point: > Server engine.isOutboundDone() = false > Server engine.isInboundDone() = true > > Let me know if you have any questions. The particular point where we send close_notify from the server to the client is just incidental from how our "close during handshake" test works. Sending it at other points in the handshake process may produce different outcomes. > > Thanks, > > Tim > >> On Jul 30, 2018, at 12:13 PM, Xuelei Fan wrote: >> >> Hi Tim, >> >> Would you mind look at the code I posted in the following thread: >> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >> >> In the update, we are trying make the synchronization more simple and robust. I appreciate if you could comment by the end of this week. >> >> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way because TLS 1.2 and prior version can work around it. But for TLS 1.3, it is possible to hang the application if the connection is not closed. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. >> >> Thanks, >> Xuelei >> >> On 7/18/2018 11:51 AM, Tim Brooks wrote: >>> Yes. I can test once there is a patch. My inquiry was motivated by some work on Elasticsearch fyi. I can test a patch against that work. >>> https://github.com/elastic/elasticsearch/issues/32144 >>> - Tim >>>> On Jul 17, 2018, at 8:40 PM, Xuelei Fan > wrote: >>>> >>>> Hi, >>>> >>>> We are working on the JDK 11 close issue. >>>> https://bugs.openjdk.java.net/browse/JDK-8207009 >>>> >>>> I appreciate if you can help test if we have a patch. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 7/17/2018 4:26 PM, Tim Brooks wrote: >>>>> My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. >>>>> One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: >>>>> 1. Initiate handshake >>>>> 2. UNWRAP data from client >>>>> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >>>>> 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). >>>>> 5. Handshake status now returns "NEED_WRAP" >>>>> JDK10: >>>>> isInboundDone() - returns false >>>>> isOutboundDone() - returns false >>>>> A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. >>>>> isInboundDone() - returns false >>>>> isOutboundDone() - returns true >>>>> JDK11: >>>>> isInboundDone() - returns true >>>>> isOutboundDone() - returns false >>>>> A call to wrap() throws the following exception: >>>>> javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed >>>>> at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >>>>> at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >>>>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >>>>> I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. > From timbrooks at fastmail.com Sat Aug 4 01:14:07 2018 From: timbrooks at fastmail.com (Tim Brooks) Date: Fri, 3 Aug 2018 19:14:07 -0600 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> Message-ID: My test case is using all higher level classes that wrap SSLEngine. But on Monday I should be able to convert it to a test that uses just the SSLEngine. - Tim > On Aug 3, 2018, at 6:47 PM, Xuelei Fan wrote: > > Hi Tim, > > Your concerns make sense to me. Did you have a test case that I can use to reproduce the issues? > > Thanks, > Xuelei > > On 8/3/2018 5:04 PM, Tim Brooks wrote: >> Hi Xuelei >> I pulled the JDK 11 source today and applied your patch. And then I built the jdk to run some tests. I hope that is the correct approach. >> It appears that this change resolved some of my prior issues. But I notice some other issues. This is tested with TLS 1.2. I have not really setup my environment yet for TLS 1.3, so I was not able to test that code path. I have -Djavax.net.debug=all enabled. However, I have pruned some of messages from this email to reduce text. If you need more let me know. >> Client: >> 1. ClientHello.java:633|Produced ClientHello handshake message >> 2. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 204 >> Server: >> 3. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 204 >> 4. ClientHello.java:788|Consuming ClientHello handshake message >> 5. ClientHello.java:818|Negotiated protocol version: TLSv1.2 >> 6. ServerHello.java:361|Produced ServerHello handshake message >> 7. CertificateMessage.java:263|Produced server Certificate handshake message >> 8. ServerHelloDone.java:97|Produced ServerHelloDone handshake message >> 9. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 1086 >> Client: >> 10. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 1086 >> 11. ServerHello.java:862|Consuming ServerHello handshake message >> 12. ServerHello.java:958|Negotiated protocol version: TLSv1.2 >> 13. CertificateMessage.java:358|Consuming server Certificate handshake message >> 14. ServerHelloDone.java:142|Consuming ServerHelloDone handshake message >> 15. RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange handshake message >> 16. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 17. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 18. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 262 >> 19. SSLEngineOutputRecord.java:465|WRITE: TLS12 change_cipher_spec, length = 1 >> 20. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 16 >> At this point I do not send that data yet to the server. The client has produced the client key exchange and client finished messages. But they are still in transit (in this scenario). >> Server (we manually call closeOutboud() because we have decided we need to close this socket): >> 21. SSLEngineImpl.java:745|Closing outbound of SSLEngine >> 22. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 >> 23. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 5A ......Z) >> - I believe this is user_canceled alert >> 24. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 00 .......) >> - I believe this is close_notify >> At this point: >> Server engine.isOutboundDone() = true >> Server engine.isInboundDone() = false >> Client: >> 24. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >> 25. Alert.java:232|Received alert message ("Alert": {"level" : "warning", "description": "user_canceled"}) >> 26. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >> 27. Alert.java:232|Received alert message ("Alert": {"level": "warning", "description": "close_notify"}) >> 28. Fatal (UNEXPECTED_MESSAGE): Received close_notify during handshake ( >> "throwable" : { >> javax.net.ssl.SSLProtocolException: Received close_notify during handshake >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) >> At this point I want to note that it feels weird that this produces an exception. The other side said "user_canceled" and then sent "close_notify". That seems correct to me? So it feels weird that consumers of the SSlEngine have to handle this exception and then continue using the engine for a proper close. That's just a side note. I (think) this behavior is not new. But it seems odd. >> At this point: >> Client engine.isOutboundDone() = false >> Client engine.isInboundDone() = true >> Still Client: >> 29. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 >> 30. SSLCipher.java:1726|Plaintext before ENCRYPTION (0000: 02 0A ..) >> 31. 2018-08-04 05:16:34.300 KGT|SSLEngineOutputRecord.java:483|Raw write ( >> 0000: 15 03 03 00 1A 00 00 00 00 00 00 00 01 E2 36 F9 ..............6. >> 0010: 09 D2 20 65 B5 C9 04 CB D3 47 8B E2 CA 0B B2 .. e.....G..... >> ) >> - I believe this is unexpected_message. And I believe it is encrypted at this point as the client has sent the client finished message. This alert feels incorrect to me. The server sent "user_canceled". I feel like once that is sent, we should be able to receive "close_notify" without the client engine identifying this as an unexpected message. >> At this point: >> Client engine.isOutboundDone() = true >> Client engine.isInboundDone() = true >> That seems correct to me. We need to flush the last alert for the client and then we are done with the engine (although I believe the alert should be close_notify and not unexpected_message). >> At this point the server starts receiving all the handshake messages from the client. >> Server: >> 32. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 262 >> 33. RSAClientKeyExchange.java:279|Consuming RSA ClientKeyExchange handshake message >> 34. SSLEngineInputRecord.java:214|READ: TLSv1.2 change_cipher_spec, length = 1 >> 35. ChangeCipherSpec.java:143|Consuming ChangeCipherSpec message >> 36. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 40 >> 37. Finished.java:581|Consuming client Finished handshake message. >> At this point: >> Server engine.isOutboundDone() = false >> Server engine.isInboundDone() = false >> That seems completely wrong to me. We manually told the server outbound was done. But receiving the final handshake messages has put it back to outbound not being done. Additionally, at this point the server's handshake status is NEED_WRAP and NEED_TASK. It looks like it is trying to continue handshaking. >> Still Server: >> 38. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 39. Finished.java:450|Produced server Finished handshake message >> 40. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 26 >> 41. Alert.java:232|Received alert message >> 42. TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Received fatal alert: unexpected_message ( >> "throwable" : { >> javax.net.ssl.SSLProtocolException: Received fatal alert: unexpected_message >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) >> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:281) >> At this point the server engine has received the alert. That throws an exception. And the engine still seems to be in an incorrect "done" state. >> At this point: >> Server engine.isOutboundDone() = false >> Server engine.isInboundDone() = true >> Let me know if you have any questions. The particular point where we send close_notify from the server to the client is just incidental from how our "close during handshake" test works. Sending it at other points in the handshake process may produce different outcomes. >> Thanks, >> Tim >>> On Jul 30, 2018, at 12:13 PM, Xuelei Fan wrote: >>> >>> Hi Tim, >>> >>> Would you mind look at the code I posted in the following thread: >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>> >>> In the update, we are trying make the synchronization more simple and robust. I appreciate if you could comment by the end of this week. >>> >>> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way because TLS 1.2 and prior version can work around it. But for TLS 1.3, it is possible to hang the application if the connection is not closed. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/18/2018 11:51 AM, Tim Brooks wrote: >>>> Yes. I can test once there is a patch. My inquiry was motivated by some work on Elasticsearch fyi. I can test a patch against that work. >>>> https://github.com/elastic/elasticsearch/issues/32144 >>>> - Tim >>>>> On Jul 17, 2018, at 8:40 PM, Xuelei Fan > wrote: >>>>> >>>>> Hi, >>>>> >>>>> We are working on the JDK 11 close issue. >>>>> https://bugs.openjdk.java.net/browse/JDK-8207009 >>>>> >>>>> I appreciate if you can help test if we have a patch. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 7/17/2018 4:26 PM, Tim Brooks wrote: >>>>>> My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. >>>>>> One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: >>>>>> 1. Initiate handshake >>>>>> 2. UNWRAP data from client >>>>>> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >>>>>> 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). >>>>>> 5. Handshake status now returns "NEED_WRAP" >>>>>> JDK10: >>>>>> isInboundDone() - returns false >>>>>> isOutboundDone() - returns false >>>>>> A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. >>>>>> isInboundDone() - returns false >>>>>> isOutboundDone() - returns true >>>>>> JDK11: >>>>>> isInboundDone() - returns true >>>>>> isOutboundDone() - returns false >>>>>> A call to wrap() throws the following exception: >>>>>> javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed >>>>>> at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >>>>>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >>>>>> I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. From weijun.wang at oracle.com Mon Aug 6 08:53:35 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 6 Aug 2018 16:53:35 +0800 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> Message-ID: Ping again. Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. Thanks Max > On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ > > Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. > > Thanks > Max > From sean.mullan at oracle.com Mon Aug 6 14:16:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Aug 2018 10:16:26 -0400 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> <8601c0bb-0f73-76d6-8ad0-5f8dd3e788e0@oracle.com> <68B87EA5-6F86-4970-AB80-556D4783CF28@oracle.com> Message-ID: <4ff220a5-c07c-4154-d3a1-3c4896497979@oracle.com> On 8/3/18 8:19 PM, Valerie Peng wrote: > > I can file a follow-on issue. However, I want to clarify what we want to > do before filing it. > > Based on current exchanges: We want to update > Cipher.getParameters()/CipherSpi.engineGetParameters() with similar > format/wording as Signature.getParameters(), e.g. expanding the meaning > when null is returned. Yes. > In addition, we also need to change the part of > "same parameters" due to this special PBE parameter handling behavior. > Right? I think so, but can you add a bit more details on the "special PBE parameter handling behavior"? --Sean > > Thanks, > Valerie > > On 7/31/2018 12:56 PM, Sean Mullan wrote: >> On 7/24/18 9:38 PM, Weijun Wang wrote: >>> Something related. >>> >>> Cipher has a similar init(..,params) and getParameters() structure >>> and the spec is also similar. >>> >>> *

The returned parameters may be the same that were used to >>> initialize >>> * this cipher, or may contain a combination of default and random >>> * parameter values used by the underlying cipher implementation if this >>> * cipher requires algorithm parameters but was not initialized with any. >>> >>> However, one can supply an incomplete parameters object in init() and >>> getParameters() will fill in default/random values to make it complete. >>> >>> For example, in PBE-based Cipher, one can only include salt and >>> iteration count in the init params, and init() will add in a random >>> IV, and the IV can be retrieved with getParameters(). >>> >>> Is this something we need to clarify? >> >> Yes, we should update the Cipher API to be consistent with Signature. >> I think this can wait until JDK 12 though. >> >> Valerie, can you file a follow-on issue? >> >> Thanks, >> Sean > From xuelei.fan at oracle.com Mon Aug 6 14:38:50 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 6 Aug 2018 07:38:50 -0700 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> Message-ID: <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> Maybe, the specified provider should be honored firstly? Xuelei On 8/6/2018 1:53 AM, Weijun Wang wrote: > Ping again. > > Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. > > Thanks > Max > >> On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ >> >> Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Mon Aug 6 15:14:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 6 Aug 2018 23:14:33 +0800 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> Message-ID: That would be a real behavior change and I want to be safe. -providername is now used by "keytool -importcert" to choose keystore implementations. I am not sure if someone already using -providername for this purpose might encounter any unexpected change. We can rethink about this decision if there is a real world problem. Maybe a single -providername is inadequate for complicated scenarios. Thanks Max > On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: > > Maybe, the specified provider should be honored firstly? > > Xuelei > > On 8/6/2018 1:53 AM, Weijun Wang wrote: >> Ping again. >> Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. >> Thanks >> Max >>> On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ >>> >>> Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. >>> >>> Thanks >>> Max >>> From xuelei.fan at oracle.com Mon Aug 6 15:31:40 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 6 Aug 2018 08:31:40 -0700 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> Message-ID: OK. No more comment from me. Thanks, Xuelei On 8/6/2018 8:14 AM, Weijun Wang wrote: > That would be a real behavior change and I want to be safe. > > -providername is now used by "keytool -importcert" to choose keystore implementations. I am not sure if someone already using -providername for this purpose might encounter any unexpected change. > > We can rethink about this decision if there is a real world problem. Maybe a single -providername is inadequate for complicated scenarios. > > Thanks > Max > > >> On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: >> >> Maybe, the specified provider should be honored firstly? >> >> Xuelei >> >> On 8/6/2018 1:53 AM, Weijun Wang wrote: >>> Ping again. >>> Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. >>> Thanks >>> Max >>>> On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ >>>> >>>> Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. >>>> >>>> Thanks >>>> Max >>>> > From sean.mullan at oracle.com Mon Aug 6 18:50:14 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Aug 2018 14:50:14 -0400 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> Message-ID: On 8/6/18 11:14 AM, Weijun Wang wrote: > That would be a real behavior change and I want to be safe. I'm not seeing how this would be a behavior change if it is a new option, can you add more details on that? If I specify -providerName, intuitively I would expect it would be used, at least as the first one. > -providername is now used by "keytool -importcert" to choose keystore implementations. I am not sure if someone already using -providername for this purpose might encounter any unexpected change. How does that relate to -printcert? --Sean > > We can rethink about this decision if there is a real world problem. Maybe a single -providername is inadequate for complicated scenarios. > > Thanks > Max > > >> On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: >> >> Maybe, the specified provider should be honored firstly? >> >> Xuelei >> >> On 8/6/2018 1:53 AM, Weijun Wang wrote: >>> Ping again. >>> Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. >>> Thanks >>> Max >>>> On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ >>>> >>>> Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. >>>> >>>> Thanks >>>> Max >>>> > From joe.darcy at oracle.com Mon Aug 6 19:11:26 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 6 Aug 2018 12:11:26 -0700 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces Message-ID: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the security-libs area with a handful in RMI and JNDI: ??? http://cr.openjdk.java.net/~darcy/8209024.0/ Patch below. I'll fix-up the copyright years before any push. Thanks, -Joe --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700 +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.510000999 -0700 @@ -109,6 +109,7 @@ ???? * serialization compatibility with a previous ???? * version of the class. ???? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 6603384152749567654L; ???? /** --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700 +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700 @@ -64,5 +64,6 @@ ????? * The class fingerprint that is set to indicate serialization ????? * compatibility with a previous version of the class. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 6034044314589513430L; ?} --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700 +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700 @@ -50,5 +50,6 @@ ????? * The class fingerprint that is set to indicate serialization ????? * compatibility with a previous version of the class. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 7187392471159151072L; ?} --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700 @@ -48,6 +48,7 @@ ???? * serialization compatibility with a previous ???? * version of the class. ???? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 7776497482533790279L; ???? /** --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.270000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700 @@ -48,6 +48,7 @@ ???? * serialization compatibility with a previous ???? * version of the class. ???? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 1234526332779022332L; ???? /** --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700 @@ -43,6 +43,7 @@ ???? * The class fingerprint that is set to indicate ???? * serialization compatibility. ???? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -7896394956925609184L; ???? /** --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700 @@ -45,6 +45,7 @@ ???? * The class fingerprint that is set to indicate ???? * serialization compatibility. ???? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -3314988629879632826L; ???? /** --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.470000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700 @@ -51,6 +51,7 @@ ????? * serialization compatibility with a previous ????? * version of the type. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 618058533534628008L; ???? /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.890000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.726000999 -0700 @@ -46,6 +46,7 @@ ????? * serialization compatibility with a previous ????? * version of the type. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -5682214253527700368L; ???? /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.290000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.146000999 -0700 @@ -45,6 +45,7 @@ ????? * serialization compatibility with a previous ????? * version of the type. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 5187144804936595022L; ???? /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.706000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.554000999 -0700 @@ -42,6 +42,7 @@ ????? * serialization compatibility with a previous ????? * version of the type. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -8727434096241101194L; ???? /** --- old/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:51.142000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:50.986000999 -0700 @@ -64,5 +64,6 @@ ????? * The class fingerprint that is set to indicate serialization ????? * compatibility since J2SE 1.4. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -4795878709595146952L; ?} --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.550000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.398000999 -0700 @@ -42,6 +42,7 @@ ????? * The class fingerprint that is set to indicate serialization ????? * compatibility since J2SE 1.4. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 2211791113380396553L; ???? /** --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.966000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.810000999 -0700 @@ -42,6 +42,7 @@ ????? * The class fingerprint that is set to indicate serialization ????? * compatibility since J2SE 1.4. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -6628103563352519193L; ???? /** --- old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.390000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.238000999 -0700 @@ -42,6 +42,7 @@ ????? * The class fingerprint that is set to indicate serialization ????? * compatibility since J2SE 1.4. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -1430015993304333921L; ???? /** --- old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.814000999 -0700 +++ new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.658000999 -0700 @@ -44,6 +44,7 @@ ?@Deprecated ?public interface TlsMasterSecret extends SecretKey { +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? public static final long serialVersionUID = -461748105810469773L; ???? /** --- old/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.294000999 -0700 +++ new/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.126000999 -0700 @@ -64,6 +64,7 @@ ???? * serialization compatibility with a previous ???? * version of the class. ???? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -3617482732056931635L; ???? /** --- old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.702000999 -0700 +++ new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.550000999 -0700 @@ -336,5 +336,6 @@ ???? /** ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability. ????? */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 8707690322213556804L; ?} --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:54.098000999 -0700 +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:53.942000999 -0700 @@ -39,6 +39,7 @@ ?public interface RemoteRef extends java.io.Externalizable { ???? /** indicate compatibility with JDK 1.1.x version of class. */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = 3632638527362204081L; ???? /** --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.494000999 -0700 +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.338000999 -0700 @@ -39,6 +39,7 @@ ?public interface ServerRef extends RemoteRef { ???? /** indicate compatibility with JDK 1.1.x version of class. */ +??? @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual ???? static final long serialVersionUID = -4557750989390278438L; ???? /** From sean.mullan at oracle.com Mon Aug 6 19:23:52 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Aug 2018 15:23:52 -0400 Subject: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security property Message-ID: After further evaluation of the new jdk.includeInExceptions security property originally introduced in JDK-8204233 [1] and further generalized in JDK-8207846 [2], I felt that a stronger warning should be added to the description of the property alerting the user to the potential risks of setting the property. I also added a test to ensure that the property was not accidentally turned on by default (mainly to catch accidental pushes where the property was left on as part of testing, etc). webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/ --Sean [1] https://bugs.openjdk.java.net/browse/JDK-8204233 [2] https://bugs.openjdk.java.net/browse/JDK-8207846 From brian.burkhalter at oracle.com Mon Aug 6 19:34:22 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Aug 2018 12:34:22 -0700 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> Message-ID: <5834E0A4-240A-4A39-9165-0416265C7849@oracle.com> Hi Joe, Looks fine. Brian On Aug 6, 2018, at 12:11 PM, joe darcy wrote: > Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). > > Most of the affected files are in the security-libs area with a handful in RMI and JNDI: > > http://cr.openjdk.java.net/~darcy/8209024.0/ > > Patch below. I'll fix-up the copyright years before any push. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Mon Aug 6 19:44:44 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 6 Aug 2018 15:44:44 -0400 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> Message-ID: Hi Joe, Looks fine.? I would probably have used "ineffective" instead of "ineffectual". (Googling "define ineffective" and "define ineffectual" shows an interesting graph of the use of the term with ineffective growing and ineffectual dropping in use. Look under the more tag) Regards, Roger On 8/6/2018 3:11 PM, joe darcy wrote: > Hello, > > Various interfaces in the JDK extend Serializable and declare > serialVersionUID fields. Such fields are ineffectual and > @SuppressWarnings("serial") should be applied to such fields to > suppress future planned serial lint checks (JDK-8202056). > > Most of the affected files are in the security-libs area with a > handful in RMI and JNDI: > > ??? http://cr.openjdk.java.net/~darcy/8209024.0/ > > Patch below. I'll fix-up the copyright years before any push. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 > 12:04:46.666000999 -0700 > +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 > 12:04:46.510000999 -0700 > @@ -109,6 +109,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 6603384152749567654L; > > ???? /** > --- old/src/java.base/share/classes/java/security/PrivateKey.java > 2018-08-06 12:04:47.062000999 -0700 > +++ new/src/java.base/share/classes/java/security/PrivateKey.java > 2018-08-06 12:04:46.914000999 -0700 > @@ -64,5 +64,6 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility with a previous version of the class. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 6034044314589513430L; > ?} > --- old/src/java.base/share/classes/java/security/PublicKey.java > 2018-08-06 12:04:47.454000999 -0700 > +++ new/src/java.base/share/classes/java/security/PublicKey.java > 2018-08-06 12:04:47.306000999 -0700 > @@ -50,5 +50,6 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility with a previous version of the class. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 7187392471159151072L; > ?} > --- > old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java > 2018-08-06 12:04:47.858000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java > 2018-08-06 12:04:47.706000999 -0700 > @@ -48,6 +48,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 7776497482533790279L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java > 2018-08-06 12:04:48.270000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java > 2018-08-06 12:04:48.114000999 -0700 > @@ -48,6 +48,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 1234526332779022332L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java > 2018-08-06 12:04:48.674000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java > 2018-08-06 12:04:48.522000999 -0700 > @@ -43,6 +43,7 @@ > ???? * The class fingerprint that is set to indicate > ???? * serialization compatibility. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -7896394956925609184L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java > 2018-08-06 12:04:49.078000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java > 2018-08-06 12:04:48.926000999 -0700 > @@ -45,6 +45,7 @@ > ???? * The class fingerprint that is set to indicate > ???? * serialization compatibility. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -3314988629879632826L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java > 2018-08-06 12:04:49.470000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java > 2018-08-06 12:04:49.318000999 -0700 > @@ -51,6 +51,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 618058533534628008L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java > 2018-08-06 12:04:49.890000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java > 2018-08-06 12:04:49.726000999 -0700 > @@ -46,6 +46,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -5682214253527700368L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java > 2018-08-06 12:04:50.290000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java > 2018-08-06 12:04:50.146000999 -0700 > @@ -45,6 +45,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 5187144804936595022L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java > 2018-08-06 12:04:50.706000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java > 2018-08-06 12:04:50.554000999 -0700 > @@ -42,6 +42,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -8727434096241101194L; > > ???? /** > --- old/src/java.base/share/classes/javax/crypto/SecretKey.java > 2018-08-06 12:04:51.142000999 -0700 > +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java > 2018-08-06 12:04:50.986000999 -0700 > @@ -64,5 +64,6 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -4795878709595146952L; > ?} > --- > old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java > 2018-08-06 12:04:51.550000999 -0700 > +++ > new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java > 2018-08-06 12:04:51.398000999 -0700 > @@ -42,6 +42,7 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 2211791113380396553L; > > ???? /** > --- > old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java > 2018-08-06 12:04:51.966000999 -0700 > +++ > new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java > 2018-08-06 12:04:51.810000999 -0700 > @@ -42,6 +42,7 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -6628103563352519193L; > > ???? /** > --- > old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java > 2018-08-06 12:04:52.390000999 -0700 > +++ > new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java > 2018-08-06 12:04:52.238000999 -0700 > @@ -42,6 +42,7 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -1430015993304333921L; > > ???? /** > --- > old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java > 2018-08-06 12:04:52.814000999 -0700 > +++ > new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java > 2018-08-06 12:04:52.658000999 -0700 > @@ -44,6 +44,7 @@ > ?@Deprecated > ?public interface TlsMasterSecret extends SecretKey { > > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? public static final long serialVersionUID = -461748105810469773L; > > ???? /** > --- old/src/java.naming/share/classes/javax/naming/Name.java > 2018-08-06 12:04:53.294000999 -0700 > +++ new/src/java.naming/share/classes/javax/naming/Name.java > 2018-08-06 12:04:53.126000999 -0700 > @@ -64,6 +64,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -3617482732056931635L; > > ???? /** > --- > old/src/java.naming/share/classes/javax/naming/directory/Attribute.java > 2018-08-06 12:04:53.702000999 -0700 > +++ > new/src/java.naming/share/classes/javax/naming/directory/Attribute.java > 2018-08-06 12:04:53.550000999 -0700 > @@ -336,5 +336,6 @@ > ???? /** > ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 8707690322213556804L; > ?} > --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java > 2018-08-06 12:04:54.098000999 -0700 > +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java > 2018-08-06 12:04:53.942000999 -0700 > @@ -39,6 +39,7 @@ > ?public interface RemoteRef extends java.io.Externalizable { > > ???? /** indicate compatibility with JDK 1.1.x version of class. */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = 3632638527362204081L; > > ???? /** > --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java > 2018-08-06 12:04:54.494000999 -0700 > +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java > 2018-08-06 12:04:54.338000999 -0700 > @@ -39,6 +39,7 @@ > ?public interface ServerRef extends RemoteRef { > > ???? /** indicate compatibility with JDK 1.1.x version of class. */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface > is ineffectual > ???? static final long serialVersionUID = -4557750989390278438L; > > ???? /** > > > From sean.mullan at oracle.com Mon Aug 6 19:49:39 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Aug 2018 15:49:39 -0400 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> Message-ID: <5cb5ec06-ad7c-594a-6514-662cec207ad5@oracle.com> Looks fine to me. --Sean On 8/6/18 3:11 PM, joe darcy wrote: > Hello, > > Various interfaces in the JDK extend Serializable and declare > serialVersionUID fields. Such fields are ineffectual and > @SuppressWarnings("serial") should be applied to such fields to suppress > future planned serial lint checks (JDK-8202056). > > Most of the affected files are in the security-libs area with a handful > in RMI and JNDI: > > ??? http://cr.openjdk.java.net/~darcy/8209024.0/ > > Patch below. I'll fix-up the copyright years before any push. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 > 12:04:46.666000999 -0700 > +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 > 12:04:46.510000999 -0700 > @@ -109,6 +109,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 6603384152749567654L; > > ???? /** > --- old/src/java.base/share/classes/java/security/PrivateKey.java > 2018-08-06 12:04:47.062000999 -0700 > +++ new/src/java.base/share/classes/java/security/PrivateKey.java > 2018-08-06 12:04:46.914000999 -0700 > @@ -64,5 +64,6 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility with a previous version of the class. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 6034044314589513430L; > ?} > --- old/src/java.base/share/classes/java/security/PublicKey.java > 2018-08-06 12:04:47.454000999 -0700 > +++ new/src/java.base/share/classes/java/security/PublicKey.java > 2018-08-06 12:04:47.306000999 -0700 > @@ -50,5 +50,6 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility with a previous version of the class. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 7187392471159151072L; > ?} > --- > old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java > 2018-08-06 12:04:47.858000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java > 2018-08-06 12:04:47.706000999 -0700 > @@ -48,6 +48,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 7776497482533790279L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java > 2018-08-06 12:04:48.270000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java > 2018-08-06 12:04:48.114000999 -0700 > @@ -48,6 +48,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 1234526332779022332L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java > 2018-08-06 12:04:48.674000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java > 2018-08-06 12:04:48.522000999 -0700 > @@ -43,6 +43,7 @@ > ???? * The class fingerprint that is set to indicate > ???? * serialization compatibility. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -7896394956925609184L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 > 12:04:49.078000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 > 12:04:48.926000999 -0700 > @@ -45,6 +45,7 @@ > ???? * The class fingerprint that is set to indicate > ???? * serialization compatibility. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -3314988629879632826L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java > 2018-08-06 12:04:49.470000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java > 2018-08-06 12:04:49.318000999 -0700 > @@ -51,6 +51,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 618058533534628008L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java > 2018-08-06 12:04:49.890000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java > 2018-08-06 12:04:49.726000999 -0700 > @@ -46,6 +46,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -5682214253527700368L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java > 2018-08-06 12:04:50.290000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java > 2018-08-06 12:04:50.146000999 -0700 > @@ -45,6 +45,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 5187144804936595022L; > > ???? /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java > 2018-08-06 12:04:50.706000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java > 2018-08-06 12:04:50.554000999 -0700 > @@ -42,6 +42,7 @@ > ????? * serialization compatibility with a previous > ????? * version of the type. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -8727434096241101194L; > > ???? /** > --- old/src/java.base/share/classes/javax/crypto/SecretKey.java > 2018-08-06 12:04:51.142000999 -0700 > +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java > 2018-08-06 12:04:50.986000999 -0700 > @@ -64,5 +64,6 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -4795878709595146952L; > ?} > --- > old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 > 12:04:51.550000999 -0700 > +++ > new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 > 12:04:51.398000999 -0700 > @@ -42,6 +42,7 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 2211791113380396553L; > > ???? /** > --- > old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java > 2018-08-06 12:04:51.966000999 -0700 > +++ > new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java > 2018-08-06 12:04:51.810000999 -0700 > @@ -42,6 +42,7 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -6628103563352519193L; > > ???? /** > --- old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java > 2018-08-06 12:04:52.390000999 -0700 > +++ new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java > 2018-08-06 12:04:52.238000999 -0700 > @@ -42,6 +42,7 @@ > ????? * The class fingerprint that is set to indicate serialization > ????? * compatibility since J2SE 1.4. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -1430015993304333921L; > > ???? /** > --- > old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java > 2018-08-06 12:04:52.814000999 -0700 > +++ > new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java > 2018-08-06 12:04:52.658000999 -0700 > @@ -44,6 +44,7 @@ > ?@Deprecated > ?public interface TlsMasterSecret extends SecretKey { > > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? public static final long serialVersionUID = -461748105810469773L; > > ???? /** > --- old/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 > 12:04:53.294000999 -0700 > +++ new/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 > 12:04:53.126000999 -0700 > @@ -64,6 +64,7 @@ > ???? * serialization compatibility with a previous > ???? * version of the class. > ???? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -3617482732056931635L; > > ???? /** > --- > old/src/java.naming/share/classes/javax/naming/directory/Attribute.java > 2018-08-06 12:04:53.702000999 -0700 > +++ > new/src/java.naming/share/classes/javax/naming/directory/Attribute.java > 2018-08-06 12:04:53.550000999 -0700 > @@ -336,5 +336,6 @@ > ???? /** > ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability. > ????? */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 8707690322213556804L; > ?} > --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java > 2018-08-06 12:04:54.098000999 -0700 > +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java > 2018-08-06 12:04:53.942000999 -0700 > @@ -39,6 +39,7 @@ > ?public interface RemoteRef extends java.io.Externalizable { > > ???? /** indicate compatibility with JDK 1.1.x version of class. */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = 3632638527362204081L; > > ???? /** > --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java > 2018-08-06 12:04:54.494000999 -0700 > +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java > 2018-08-06 12:04:54.338000999 -0700 > @@ -39,6 +39,7 @@ > ?public interface ServerRef extends RemoteRef { > > ???? /** indicate compatibility with JDK 1.1.x version of class. */ > +??? @SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > ???? static final long serialVersionUID = -4557750989390278438L; > > ???? /** > > > From joe.darcy at oracle.com Mon Aug 6 21:30:55 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 6 Aug 2018 14:30:55 -0700 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> Message-ID: <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com> Hi Roger, Even if currently less commonly used, I think "ineffectual" better captures the intention of what I want to convey in the comment than "ineffective." Thanks all for the reviews; cheers, -Joe On 8/6/2018 12:44 PM, Roger Riggs wrote: > Hi Joe, > > Looks fine.? I would probably have used "ineffective" instead of > "ineffectual". > > (Googling "define ineffective" and "define ineffectual" shows an > interesting graph of > the use of the term with ineffective growing and ineffectual dropping > in use. > Look under the more tag) > > Regards, Roger > > > On 8/6/2018 3:11 PM, joe darcy wrote: >> Hello, >> >> Various interfaces in the JDK extend Serializable and declare >> serialVersionUID fields. Such fields are ineffectual and >> @SuppressWarnings("serial") should be applied to such fields to >> suppress future planned serial lint checks (JDK-8202056). >> >> Most of the affected files are in the security-libs area with a >> handful in RMI and JNDI: >> >> ??? http://cr.openjdk.java.net/~darcy/8209024.0/ >> >> Patch below. I'll fix-up the copyright years before any push. >> >> Thanks, >> >> -Joe >> >> --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 >> 12:04:46.666000999 -0700 >> +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 >> 12:04:46.510000999 -0700 >> @@ -109,6 +109,7 @@ >> ???? * serialization compatibility with a previous >> ???? * version of the class. >> ???? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 6603384152749567654L; >> >> ???? /** >> --- old/src/java.base/share/classes/java/security/PrivateKey.java >> 2018-08-06 12:04:47.062000999 -0700 >> +++ new/src/java.base/share/classes/java/security/PrivateKey.java >> 2018-08-06 12:04:46.914000999 -0700 >> @@ -64,5 +64,6 @@ >> ????? * The class fingerprint that is set to indicate serialization >> ????? * compatibility with a previous version of the class. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 6034044314589513430L; >> ?} >> --- old/src/java.base/share/classes/java/security/PublicKey.java >> 2018-08-06 12:04:47.454000999 -0700 >> +++ new/src/java.base/share/classes/java/security/PublicKey.java >> 2018-08-06 12:04:47.306000999 -0700 >> @@ -50,5 +50,6 @@ >> ????? * The class fingerprint that is set to indicate serialization >> ????? * compatibility with a previous version of the class. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 7187392471159151072L; >> ?} >> --- >> old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java >> 2018-08-06 12:04:47.858000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java >> 2018-08-06 12:04:47.706000999 -0700 >> @@ -48,6 +48,7 @@ >> ???? * serialization compatibility with a previous >> ???? * version of the class. >> ???? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 7776497482533790279L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java >> 2018-08-06 12:04:48.270000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java >> 2018-08-06 12:04:48.114000999 -0700 >> @@ -48,6 +48,7 @@ >> ???? * serialization compatibility with a previous >> ???? * version of the class. >> ???? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 1234526332779022332L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java >> 2018-08-06 12:04:48.674000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java >> 2018-08-06 12:04:48.522000999 -0700 >> @@ -43,6 +43,7 @@ >> ???? * The class fingerprint that is set to indicate >> ???? * serialization compatibility. >> ???? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -7896394956925609184L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java >> 2018-08-06 12:04:49.078000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java >> 2018-08-06 12:04:48.926000999 -0700 >> @@ -45,6 +45,7 @@ >> ???? * The class fingerprint that is set to indicate >> ???? * serialization compatibility. >> ???? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -3314988629879632826L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java >> 2018-08-06 12:04:49.470000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java >> 2018-08-06 12:04:49.318000999 -0700 >> @@ -51,6 +51,7 @@ >> ????? * serialization compatibility with a previous >> ????? * version of the type. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 618058533534628008L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java >> 2018-08-06 12:04:49.890000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java >> 2018-08-06 12:04:49.726000999 -0700 >> @@ -46,6 +46,7 @@ >> ????? * serialization compatibility with a previous >> ????? * version of the type. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -5682214253527700368L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java >> 2018-08-06 12:04:50.290000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java >> 2018-08-06 12:04:50.146000999 -0700 >> @@ -45,6 +45,7 @@ >> ????? * serialization compatibility with a previous >> ????? * version of the type. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 5187144804936595022L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java >> 2018-08-06 12:04:50.706000999 -0700 >> +++ >> new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java >> 2018-08-06 12:04:50.554000999 -0700 >> @@ -42,6 +42,7 @@ >> ????? * serialization compatibility with a previous >> ????? * version of the type. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -8727434096241101194L; >> >> ???? /** >> --- old/src/java.base/share/classes/javax/crypto/SecretKey.java >> 2018-08-06 12:04:51.142000999 -0700 >> +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java >> 2018-08-06 12:04:50.986000999 -0700 >> @@ -64,5 +64,6 @@ >> ????? * The class fingerprint that is set to indicate serialization >> ????? * compatibility since J2SE 1.4. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -4795878709595146952L; >> ?} >> --- >> old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java >> 2018-08-06 12:04:51.550000999 -0700 >> +++ >> new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java >> 2018-08-06 12:04:51.398000999 -0700 >> @@ -42,6 +42,7 @@ >> ????? * The class fingerprint that is set to indicate serialization >> ????? * compatibility since J2SE 1.4. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 2211791113380396553L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java >> 2018-08-06 12:04:51.966000999 -0700 >> +++ >> new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java >> 2018-08-06 12:04:51.810000999 -0700 >> @@ -42,6 +42,7 @@ >> ????? * The class fingerprint that is set to indicate serialization >> ????? * compatibility since J2SE 1.4. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -6628103563352519193L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java >> 2018-08-06 12:04:52.390000999 -0700 >> +++ >> new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java >> 2018-08-06 12:04:52.238000999 -0700 >> @@ -42,6 +42,7 @@ >> ????? * The class fingerprint that is set to indicate serialization >> ????? * compatibility since J2SE 1.4. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -1430015993304333921L; >> >> ???? /** >> --- >> old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java >> 2018-08-06 12:04:52.814000999 -0700 >> +++ >> new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java >> 2018-08-06 12:04:52.658000999 -0700 >> @@ -44,6 +44,7 @@ >> ?@Deprecated >> ?public interface TlsMasterSecret extends SecretKey { >> >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? public static final long serialVersionUID = -461748105810469773L; >> >> ???? /** >> --- old/src/java.naming/share/classes/javax/naming/Name.java >> 2018-08-06 12:04:53.294000999 -0700 >> +++ new/src/java.naming/share/classes/javax/naming/Name.java >> 2018-08-06 12:04:53.126000999 -0700 >> @@ -64,6 +64,7 @@ >> ???? * serialization compatibility with a previous >> ???? * version of the class. >> ???? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -3617482732056931635L; >> >> ???? /** >> --- >> old/src/java.naming/share/classes/javax/naming/directory/Attribute.java >> 2018-08-06 12:04:53.702000999 -0700 >> +++ >> new/src/java.naming/share/classes/javax/naming/directory/Attribute.java >> 2018-08-06 12:04:53.550000999 -0700 >> @@ -336,5 +336,6 @@ >> ???? /** >> ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability. >> ????? */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 8707690322213556804L; >> ?} >> --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java >> 2018-08-06 12:04:54.098000999 -0700 >> +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java >> 2018-08-06 12:04:53.942000999 -0700 >> @@ -39,6 +39,7 @@ >> ?public interface RemoteRef extends java.io.Externalizable { >> >> ???? /** indicate compatibility with JDK 1.1.x version of class. */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = 3632638527362204081L; >> >> ???? /** >> --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java >> 2018-08-06 12:04:54.494000999 -0700 >> +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java >> 2018-08-06 12:04:54.338000999 -0700 >> @@ -39,6 +39,7 @@ >> ?public interface ServerRef extends RemoteRef { >> >> ???? /** indicate compatibility with JDK 1.1.x version of class. */ >> +??? @SuppressWarnings("serial") // serialVersionUID in an interface >> is ineffectual >> ???? static final long serialVersionUID = -4557750989390278438L; >> >> ???? /** >> >> >> > From lance.andersen at oracle.com Mon Aug 6 22:11:35 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 6 Aug 2018 18:11:35 -0400 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> Message-ID: +1 > On Aug 6, 2018, at 3:11 PM, joe darcy wrote: > > Hello, > > Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). > > Most of the affected files are in the security-libs area with a handful in RMI and JNDI: > > http://cr.openjdk.java.net/~darcy/8209024.0/ > > Patch below. I'll fix-up the copyright years before any push. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700 > +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.510000999 -0700 > @@ -109,6 +109,7 @@ > * serialization compatibility with a previous > * version of the class. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 6603384152749567654L; > > /** > --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700 > +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700 > @@ -64,5 +64,6 @@ > * The class fingerprint that is set to indicate serialization > * compatibility with a previous version of the class. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 6034044314589513430L; > } > --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700 > +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700 > @@ -50,5 +50,6 @@ > * The class fingerprint that is set to indicate serialization > * compatibility with a previous version of the class. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 7187392471159151072L; > } > --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700 > @@ -48,6 +48,7 @@ > * serialization compatibility with a previous > * version of the class. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 7776497482533790279L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.270000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700 > @@ -48,6 +48,7 @@ > * serialization compatibility with a previous > * version of the class. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 1234526332779022332L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700 > @@ -43,6 +43,7 @@ > * The class fingerprint that is set to indicate > * serialization compatibility. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -7896394956925609184L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700 > @@ -45,6 +45,7 @@ > * The class fingerprint that is set to indicate > * serialization compatibility. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -3314988629879632826L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.470000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700 > @@ -51,6 +51,7 @@ > * serialization compatibility with a previous > * version of the type. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 618058533534628008L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.890000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.726000999 -0700 > @@ -46,6 +46,7 @@ > * serialization compatibility with a previous > * version of the type. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -5682214253527700368L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.290000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.146000999 -0700 > @@ -45,6 +45,7 @@ > * serialization compatibility with a previous > * version of the type. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 5187144804936595022L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.706000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.554000999 -0700 > @@ -42,6 +42,7 @@ > * serialization compatibility with a previous > * version of the type. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -8727434096241101194L; > > /** > --- old/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:51.142000999 -0700 > +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:50.986000999 -0700 > @@ -64,5 +64,6 @@ > * The class fingerprint that is set to indicate serialization > * compatibility since J2SE 1.4. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -4795878709595146952L; > } > --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.550000999 -0700 > +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.398000999 -0700 > @@ -42,6 +42,7 @@ > * The class fingerprint that is set to indicate serialization > * compatibility since J2SE 1.4. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 2211791113380396553L; > > /** > --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.966000999 -0700 > +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.810000999 -0700 > @@ -42,6 +42,7 @@ > * The class fingerprint that is set to indicate serialization > * compatibility since J2SE 1.4. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -6628103563352519193L; > > /** > --- old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.390000999 -0700 > +++ new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.238000999 -0700 > @@ -42,6 +42,7 @@ > * The class fingerprint that is set to indicate serialization > * compatibility since J2SE 1.4. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -1430015993304333921L; > > /** > --- old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.814000999 -0700 > +++ new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.658000999 -0700 > @@ -44,6 +44,7 @@ > @Deprecated > public interface TlsMasterSecret extends SecretKey { > > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > public static final long serialVersionUID = -461748105810469773L; > > /** > --- old/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.294000999 -0700 > +++ new/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.126000999 -0700 > @@ -64,6 +64,7 @@ > * serialization compatibility with a previous > * version of the class. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -3617482732056931635L; > > /** > --- old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.702000999 -0700 > +++ new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.550000999 -0700 > @@ -336,5 +336,6 @@ > /** > * Use serialVersionUID from JNDI 1.1.1 for interoperability. > */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 8707690322213556804L; > } > --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:54.098000999 -0700 > +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:53.942000999 -0700 > @@ -39,6 +39,7 @@ > public interface RemoteRef extends java.io.Externalizable { > > /** indicate compatibility with JDK 1.1.x version of class. */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = 3632638527362204081L; > > /** > --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.494000999 -0700 > +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.338000999 -0700 > @@ -39,6 +39,7 @@ > public interface ServerRef extends RemoteRef { > > /** indicate compatibility with JDK 1.1.x version of class. */ > + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual > static final long serialVersionUID = -4557750989390278438L; > > /** > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From valerie.peng at oracle.com Mon Aug 6 22:36:38 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 6 Aug 2018 15:36:38 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <4ff220a5-c07c-4154-d3a1-3c4896497979@oracle.com> References: <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> <8601c0bb-0f73-76d6-8ad0-5f8dd3e788e0@oracle.com> <68B87EA5-6F86-4970-AB80-556D4783CF28@oracle.com> <4ff220a5-c07c-4154-d3a1-3c4896497979@oracle.com> Message-ID: <56d531d0-b296-0c4e-76b0-6a98de8ac032@oracle.com> Ok, I included Max's description for the special PBE parameter handling. Should be enough details... Filed: https://bugs.openjdk.java.net/browse/JDK-8209038 Thanks, Valerie On 8/6/2018 7:16 AM, Sean Mullan wrote: > On 8/3/18 8:19 PM, Valerie Peng wrote: >> >> I can file a follow-on issue. However, I want to clarify what we want >> to do before filing it. >> >> Based on current exchanges: We want to update >> Cipher.getParameters()/CipherSpi.engineGetParameters() with similar >> format/wording as Signature.getParameters(), e.g. expanding the >> meaning when null is returned. > > Yes. > >> In addition, we also need to change the part of "same parameters" due >> to this special PBE parameter handling behavior. Right? > > I think so, but can you add a bit more details on the "special PBE > parameter handling behavior"? > > --Sean > >> >> Thanks, >> Valerie >> >> On 7/31/2018 12:56 PM, Sean Mullan wrote: >>> On 7/24/18 9:38 PM, Weijun Wang wrote: >>>> Something related. >>>> >>>> Cipher has a similar init(..,params) and getParameters() structure >>>> and the spec is also similar. >>>> >>>> *

The returned parameters may be the same that were used to >>>> initialize >>>> * this cipher, or may contain a combination of default and random >>>> * parameter values used by the underlying cipher implementation if >>>> this >>>> * cipher requires algorithm parameters but was not initialized with >>>> any. >>>> >>>> However, one can supply an incomplete parameters object in init() >>>> and getParameters() will fill in default/random values to make it >>>> complete. >>>> >>>> For example, in PBE-based Cipher, one can only include salt and >>>> iteration count in the init params, and init() will add in a random >>>> IV, and the IV can be retrieved with getParameters(). >>>> >>>> Is this something we need to clarify? >>> >>> Yes, we should update the Cipher API to be consistent with >>> Signature. I think this can wait until JDK 12 though. >>> >>> Valerie, can you file a follow-on issue? >>> >>> Thanks, >>> Sean >> From Sergey.Bylokhov at oracle.com Mon Aug 6 22:39:38 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 6 Aug 2018 15:39:38 -0700 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com> Message-ID: <60dc4d93-64a3-9162-e51b-15b7a86b2272@oracle.com> Hi, Joe. On 06/08/2018 14:30, joe darcy wrote: > Even if currently less commonly used, I think "ineffectual" better > captures the intention of what I want to convey in the comment than > "ineffective." Can you please clarify this: what does it mean "ineffectual" in this context? why we need to "suppress" them and why these fields cannot be dropped? -- Best regards, Sergey. From joe.darcy at oracle.com Mon Aug 6 23:16:45 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 6 Aug 2018 16:16:45 -0700 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: <60dc4d93-64a3-9162-e51b-15b7a86b2272@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com> <60dc4d93-64a3-9162-e51b-15b7a86b2272@oracle.com> Message-ID: <167d903a-b3a0-19bb-b442-41463aa64962@oracle.com> Hi Sergey, On 8/6/2018 3:39 PM, Sergey Bylokhov wrote: > Hi, Joe. > > On 06/08/2018 14:30, joe darcy wrote: >> Even if currently less commonly used, I think "ineffectual" better >> captures the intention of what I want to convey in the comment than >> "ineffective." > > Can you please clarify this: what does it mean "ineffectual" in this > context? why we need to "suppress" them and why these fields cannot be > dropped? > A serialVersionUID field is intended to be used to provide the serial hash of a class both to avoid the cost of its computation at runtime and to provide cross-version serial stability in the face of innocuous changes to the class. The serialVersionUID of an interface type is *not* used in the serialization machinery. The names of interfaces are used however. Therefore, a serialVersionUID field on an interface does not have the effect one would assume it has, namely altering the behavior of serialization. In that sense, these field declarations in interfaces are ineffectual. I'm working on expanding the checks done by "javac -Xlint:serial", including flagging these and other ineffectual serialization coding patterns. I've pushed a number of related cleanup fixes earlier in JDK 12 (JDK-8208060, JDK-8207751, JDK-8208782, etc.). Much of the JDK code base is compiled using "-Xlint:all -Werror", meaning that if the set of checks is expanded and new warnings are generated, the build will fail. While it would be possible to exclude the expanded serial check from the build, I'd prefer to address the serial issues instead. Since the files modified by? JDK-8209024 are pre-JDK 9 interfaces, their static serialVersionUID fields are *public* fields, meaning they are part of the interfaces' contract. Therefore, the fieldscannot just be removed per our usual compatibility policy, unlike, say a private field in a class. For that reason, I think it is reasonable to suppress the (future) serial warnings for these fields, rather than to remove the fields. I wouldn't oppose the effort if someone else wanted to deprecated these fields for removal and then remove the fields in a future release, but I don't think the cost/benefit of that particular route is justified. HTH, -Joe From timbrooks at fastmail.com Tue Aug 7 00:01:35 2018 From: timbrooks at fastmail.com (Tim Brooks) Date: Mon, 6 Aug 2018 18:01:35 -0600 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> Message-ID: Hi Xuelei, I?ve attached a java file with a method that can be used as a test case. The caller will need to provide SSLEngines. I assume that is something you can do? As I said this is with TLS 1.2. I catch the exceptions I mentioned in my last email. Although there are comments that I do not think that these exceptions make sense. Additionally, the failing assertions are currently wrapped in if(false) {} so that the method will complete. Let me know if you have any questions. - Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: JDKSSLEngineTest.java Type: application/octet-stream Size: 12204 bytes Desc: not available URL: -------------- next part -------------- > On Aug 3, 2018, at 6:47 PM, Xuelei Fan wrote: > > Hi Tim, > > Your concerns make sense to me. Did you have a test case that I can use to reproduce the issues? > > Thanks, > Xuelei > > On 8/3/2018 5:04 PM, Tim Brooks wrote: >> Hi Xuelei >> I pulled the JDK 11 source today and applied your patch. And then I built the jdk to run some tests. I hope that is the correct approach. >> It appears that this change resolved some of my prior issues. But I notice some other issues. This is tested with TLS 1.2. I have not really setup my environment yet for TLS 1.3, so I was not able to test that code path. I have -Djavax.net.debug=all enabled. However, I have pruned some of messages from this email to reduce text. If you need more let me know. >> Client: >> 1. ClientHello.java:633|Produced ClientHello handshake message >> 2. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 204 >> Server: >> 3. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 204 >> 4. ClientHello.java:788|Consuming ClientHello handshake message >> 5. ClientHello.java:818|Negotiated protocol version: TLSv1.2 >> 6. ServerHello.java:361|Produced ServerHello handshake message >> 7. CertificateMessage.java:263|Produced server Certificate handshake message >> 8. ServerHelloDone.java:97|Produced ServerHelloDone handshake message >> 9. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 1086 >> Client: >> 10. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 1086 >> 11. ServerHello.java:862|Consuming ServerHello handshake message >> 12. ServerHello.java:958|Negotiated protocol version: TLSv1.2 >> 13. CertificateMessage.java:358|Consuming server Certificate handshake message >> 14. ServerHelloDone.java:142|Consuming ServerHelloDone handshake message >> 15. RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange handshake message >> 16. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 17. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 18. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 262 >> 19. SSLEngineOutputRecord.java:465|WRITE: TLS12 change_cipher_spec, length = 1 >> 20. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 16 >> At this point I do not send that data yet to the server. The client has produced the client key exchange and client finished messages. But they are still in transit (in this scenario). >> Server (we manually call closeOutboud() because we have decided we need to close this socket): >> 21. SSLEngineImpl.java:745|Closing outbound of SSLEngine >> 22. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 >> 23. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 5A ......Z) >> - I believe this is user_canceled alert >> 24. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 00 .......) >> - I believe this is close_notify >> At this point: >> Server engine.isOutboundDone() = true >> Server engine.isInboundDone() = false >> Client: >> 24. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >> 25. Alert.java:232|Received alert message ("Alert": {"level" : "warning", "description": "user_canceled"}) >> 26. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >> 27. Alert.java:232|Received alert message ("Alert": {"level": "warning", "description": "close_notify"}) >> 28. Fatal (UNEXPECTED_MESSAGE): Received close_notify during handshake ( >> "throwable" : { >> javax.net.ssl.SSLProtocolException: Received close_notify during handshake >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) >> At this point I want to note that it feels weird that this produces an exception. The other side said "user_canceled" and then sent "close_notify". That seems correct to me? So it feels weird that consumers of the SSlEngine have to handle this exception and then continue using the engine for a proper close. That's just a side note. I (think) this behavior is not new. But it seems odd. >> At this point: >> Client engine.isOutboundDone() = false >> Client engine.isInboundDone() = true >> Still Client: >> 29. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 >> 30. SSLCipher.java:1726|Plaintext before ENCRYPTION (0000: 02 0A ..) >> 31. 2018-08-04 05:16:34.300 KGT|SSLEngineOutputRecord.java:483|Raw write ( >> 0000: 15 03 03 00 1A 00 00 00 00 00 00 00 01 E2 36 F9 ..............6. >> 0010: 09 D2 20 65 B5 C9 04 CB D3 47 8B E2 CA 0B B2 .. e.....G..... >> ) >> - I believe this is unexpected_message. And I believe it is encrypted at this point as the client has sent the client finished message. This alert feels incorrect to me. The server sent "user_canceled". I feel like once that is sent, we should be able to receive "close_notify" without the client engine identifying this as an unexpected message. >> At this point: >> Client engine.isOutboundDone() = true >> Client engine.isInboundDone() = true >> That seems correct to me. We need to flush the last alert for the client and then we are done with the engine (although I believe the alert should be close_notify and not unexpected_message). >> At this point the server starts receiving all the handshake messages from the client. >> Server: >> 32. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 262 >> 33. RSAClientKeyExchange.java:279|Consuming RSA ClientKeyExchange handshake message >> 34. SSLEngineInputRecord.java:214|READ: TLSv1.2 change_cipher_spec, length = 1 >> 35. ChangeCipherSpec.java:143|Consuming ChangeCipherSpec message >> 36. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 40 >> 37. Finished.java:581|Consuming client Finished handshake message. >> At this point: >> Server engine.isOutboundDone() = false >> Server engine.isInboundDone() = false >> That seems completely wrong to me. We manually told the server outbound was done. But receiving the final handshake messages has put it back to outbound not being done. Additionally, at this point the server's handshake status is NEED_WRAP and NEED_TASK. It looks like it is trying to continue handshaking. >> Still Server: >> 38. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 39. Finished.java:450|Produced server Finished handshake message >> 40. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 26 >> 41. Alert.java:232|Received alert message >> 42. TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Received fatal alert: unexpected_message ( >> "throwable" : { >> javax.net.ssl.SSLProtocolException: Received fatal alert: unexpected_message >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) >> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:281) >> At this point the server engine has received the alert. That throws an exception. And the engine still seems to be in an incorrect "done" state. >> At this point: >> Server engine.isOutboundDone() = false >> Server engine.isInboundDone() = true >> Let me know if you have any questions. The particular point where we send close_notify from the server to the client is just incidental from how our "close during handshake" test works. Sending it at other points in the handshake process may produce different outcomes. >> Thanks, >> Tim >>> On Jul 30, 2018, at 12:13 PM, Xuelei Fan wrote: >>> >>> Hi Tim, >>> >>> Would you mind look at the code I posted in the following thread: >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>> >>> In the update, we are trying make the synchronization more simple and robust. I appreciate if you could comment by the end of this week. >>> >>> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way because TLS 1.2 and prior version can work around it. But for TLS 1.3, it is possible to hang the application if the connection is not closed. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/18/2018 11:51 AM, Tim Brooks wrote: >>>> Yes. I can test once there is a patch. My inquiry was motivated by some work on Elasticsearch fyi. I can test a patch against that work. >>>> https://github.com/elastic/elasticsearch/issues/32144 >>>> - Tim >>>>> On Jul 17, 2018, at 8:40 PM, Xuelei Fan > wrote: >>>>> >>>>> Hi, >>>>> >>>>> We are working on the JDK 11 close issue. >>>>> https://bugs.openjdk.java.net/browse/JDK-8207009 >>>>> >>>>> I appreciate if you can help test if we have a patch. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 7/17/2018 4:26 PM, Tim Brooks wrote: >>>>>> My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. >>>>>> One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: >>>>>> 1. Initiate handshake >>>>>> 2. UNWRAP data from client >>>>>> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >>>>>> 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). >>>>>> 5. Handshake status now returns "NEED_WRAP" >>>>>> JDK10: >>>>>> isInboundDone() - returns false >>>>>> isOutboundDone() - returns false >>>>>> A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. >>>>>> isInboundDone() - returns false >>>>>> isOutboundDone() - returns true >>>>>> JDK11: >>>>>> isInboundDone() - returns true >>>>>> isOutboundDone() - returns false >>>>>> A call to wrap() throws the following exception: >>>>>> javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed >>>>>> at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >>>>>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >>>>>> I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. From weijun.wang at oracle.com Tue Aug 7 00:20:43 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Aug 2018 08:20:43 +0800 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> Message-ID: > On Aug 7, 2018, at 2:50 AM, Sean Mullan wrote: > > On 8/6/18 11:14 AM, Weijun Wang wrote: >> That would be a real behavior change and I want to be safe. > > I'm not seeing how this would be a behavior change if it is a new option, can you add more details on that? If I specify -providerName, intuitively I would expect it would be used, at least as the first one. Before this change when "keytool -importcert" is called, KeyStore.getInstance() uses "-providername" but CertificateFactory.getInstance() *does not*. Now CertificateFactory.getInstance() is using it. If it's preferred than the default provider, then it's a behavior change. > >> -providername is now used by "keytool -importcert" to choose keystore implementations. I am not sure if someone already using -providername for this purpose might encounter any unexpected change. > > How does that relate to -printcert? Not related. In this case, it's a new option. Thanks Max > > --Sean > >> We can rethink about this decision if there is a real world problem. Maybe a single -providername is inadequate for complicated scenarios. >> Thanks >> Max >>> On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: >>> >>> Maybe, the specified provider should be honored firstly? >>> >>> Xuelei >>> >>> On 8/6/2018 1:53 AM, Weijun Wang wrote: >>>> Ping again. >>>> Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. >>>> Thanks >>>> Max >>>>> On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: >>>>> >>>>> Please take a review at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ >>>>> >>>>> Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. >>>>> >>>>> Thanks >>>>> Max >>>>> From Alan.Bateman at oracle.com Tue Aug 7 06:12:15 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Aug 2018 07:12:15 +0100 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> Message-ID: <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com> On 06/08/2018 20:11, joe darcy wrote: > Hello, > > Various interfaces in the JDK extend Serializable and declare > serialVersionUID fields. Such fields are ineffectual and > @SuppressWarnings("serial") should be applied to such fields to > suppress future planned serial lint checks (JDK-8202056). > > Most of the affected files are in the security-libs area with a > handful in RMI and JNDI: > > ??? http://cr.openjdk.java.net/~darcy/8209024.0/ > > Patch below. I'll fix-up the copyright years before any push. Is there a follow-on patch coming to deprecate these fields? -Alan From weijun.wang at oracle.com Tue Aug 7 06:31:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Aug 2018 14:31:55 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject Message-ID: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com> Please review the code change at webrev: http://cr.openjdk.java.net/~weijun/8193859/webrev.00/ where JBS: https://bugs.openjdk.java.net/browse/JDK-8193859 CSR: https://bugs.openjdk.java.net/browse/JDK-8193887 Thanks Max From Alan.Bateman at oracle.com Tue Aug 7 07:09:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Aug 2018 08:09:35 +0100 Subject: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security property In-Reply-To: References: Message-ID: <0485c5c3-b3b3-34ca-e276-27f2ca6135b1@oracle.com> On 06/08/2018 20:23, Sean Mullan wrote: > After further evaluation of the new jdk.includeInExceptions security > property originally introduced in JDK-8204233 [1] and further > generalized in JDK-8207846 [2], I felt that a stronger warning should > be added to the description of the property alerting the user to the > potential risks of setting the property. I also added a test to ensure > that the property was not accidentally turned on by default (mainly to > catch accidental pushes where the property was left on as part of > testing, etc). > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/ I think it would simpler and read a bit better to just say "Use caution before ...", meaning drop "NOTE" and "extra". The rest of the text is okay. The additional test looks okay too. -Alan From sean.mullan at oracle.com Tue Aug 7 13:09:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 7 Aug 2018 09:09:06 -0400 Subject: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security property In-Reply-To: <0485c5c3-b3b3-34ca-e276-27f2ca6135b1@oracle.com> References: <0485c5c3-b3b3-34ca-e276-27f2ca6135b1@oracle.com> Message-ID: <8bcc18af-8ef5-b354-3ecf-274ff669ac2f@oracle.com> On 8/7/18 3:09 AM, Alan Bateman wrote: > On 06/08/2018 20:23, Sean Mullan wrote: >> After further evaluation of the new jdk.includeInExceptions security >> property originally introduced in JDK-8204233 [1] and further >> generalized in JDK-8207846 [2], I felt that a stronger warning should >> be added to the description of the property alerting the user to the >> potential risks of setting the property. I also added a test to ensure >> that the property was not accidentally turned on by default (mainly to >> catch accidental pushes where the property was left on as part of >> testing, etc). >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/ > I think it would simpler and read a bit better to just say "Use caution > before ...", meaning drop "NOTE" and "extra". The rest of the text is > okay. The additional test looks okay too. I'll remove "extra" but I'd prefer to keep "NOTE" to draw attention to it. --Sean From roger.riggs at oracle.com Tue Aug 7 14:13:20 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 7 Aug 2018 10:13:20 -0400 Subject: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security property In-Reply-To: <8bcc18af-8ef5-b354-3ecf-274ff669ac2f@oracle.com> References: <0485c5c3-b3b3-34ca-e276-27f2ca6135b1@oracle.com> <8bcc18af-8ef5-b354-3ecf-274ff669ac2f@oracle.com> Message-ID: <0b3a41d6-1b98-ae3d-d2c6-5fc4901dad68@oracle.com> +1 On 8/7/18 9:09 AM, Sean Mullan wrote: > On 8/7/18 3:09 AM, Alan Bateman wrote: >> On 06/08/2018 20:23, Sean Mullan wrote: >>> After further evaluation of the new jdk.includeInExceptions security >>> property originally introduced in JDK-8204233 [1] and further >>> generalized in JDK-8207846 [2], I felt that a stronger warning >>> should be added to the description of the property alerting the user >>> to the potential risks of setting the property. I also added a test >>> to ensure that the property was not accidentally turned on by >>> default (mainly to catch accidental pushes where the property was >>> left on as part of testing, etc). >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/ >> I think it would simpler and read a bit better to just say "Use >> caution before ...", meaning drop "NOTE" and "extra". The rest of the >> text is okay. The additional test looks okay too. > > I'll remove "extra" but I'd prefer to keep "NOTE" to draw attention to > it. > > --Sean From xuelei.fan at oracle.com Tue Aug 7 14:46:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Aug 2018 07:46:28 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> Message-ID: <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> New webrev: http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ Thanks for a find of Tim Brooks, that the SSLEngine inbound/outbound status is incorrect if closing during handshake. The above webrev is trying to fix the problems. See more in the OpenJDK thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html Please let me know your concerns before this Wednesday. Thanks, Xuelei On 8/3/2018 1:55 PM, Xuelei Fan wrote: > Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ > > In webrev.01, the socket close may be blocked by super class close > synchronization.? Updated the SSLSocketImpl.java to use handshake only > lock in the startHandshake() implementation. > > Thanks, > Xuelei > > On 8/1/2018 7:27 PM, Xuelei Fan wrote: >> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >> >> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >> renegotiation fails if Java client allows TLSv1.3".? SSLHandshake.java >> is updated to use negotiated version so that TLS 1.2 HelloRequest is >> acceptable in TLS 1.3 client side. >> >> Thanks, >> Xuelei >> >> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>> >>> Please let me know your concerns by the end of August 1st, 2018. >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the update for the TLS 1.3 half-close and >>>> synchronization implementation: >>>> ??? http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>> >>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify is >>>> use to close the local write side and peer read side only.? After >>>> the close_notify get handles, the local read side and peer write >>>> side may still be open. >>>> >>>> In this update, if an application calls >>>> SSLEngine.closeInbound/Outbound() or >>>> SSLSocket.shutdownInput/Output(), half-close will be used.? For >>>> compatibility, if SSLSocket.close() get called, a duplex close will >>>> be tried.? In order to support duplex close, JDK will use the >>>> user_canceled warning alert even the handshake complete. >>>> >>>> In practice, an application may only close outbound even it is >>>> intended to close the inbound as well, or close the connection >>>> completely.? It works for TLS 1.2 and prior versions.? But no more >>>> for TLS 1.3 because of the close_notify behavior change in the TLS >>>> 1.3 specification.? The application may be hung and dead-waiting for >>>> read/close.? It could be solved by closing the inbound explicitly. >>>> In order to mitigate the impact, a new System Property is >>>> introduced, "jdk.tls.acknowledgeCloseNotify" if source code update >>>> is not available. ??If the System Property is set to "true", if >>>> receiving the close_notify, a close_notify alert will be responded. >>>> It is a countermeasure of the TLS 1.3 half-close issues. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> From xuelei.fan at oracle.com Tue Aug 7 14:54:25 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Aug 2018 07:54:25 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> Message-ID: <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> Hi Tim, Thank you very much for the test code. I can play with it. I made an update accordingly in the new webrev patch: http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ Would you mind test if the patch works for you? Thanks & Regards, Xuelei On 8/6/2018 5:01 PM, Tim Brooks wrote: > Hi Xuelei, > > I?ve attached a java file with a method that can be used as a test case. The caller will need to provide SSLEngines. I assume that is something you can do? As I said this is with TLS 1.2. > > I catch the exceptions I mentioned in my last email. Although there are comments that I do not think that these exceptions make sense. Additionally, the failing assertions are currently wrapped in if(false) {} so that the method will complete. > > Let me know if you have any questions. > > - Tim= > > > > > >> On Aug 3, 2018, at 6:47 PM, Xuelei Fan wrote: >> >> Hi Tim, >> >> Your concerns make sense to me. Did you have a test case that I can use to reproduce the issues? >> >> Thanks, >> Xuelei >> >> On 8/3/2018 5:04 PM, Tim Brooks wrote: >>> Hi Xuelei >>> I pulled the JDK 11 source today and applied your patch. And then I built the jdk to run some tests. I hope that is the correct approach. >>> It appears that this change resolved some of my prior issues. But I notice some other issues. This is tested with TLS 1.2. I have not really setup my environment yet for TLS 1.3, so I was not able to test that code path. I have -Djavax.net.debug=all enabled. However, I have pruned some of messages from this email to reduce text. If you need more let me know. >>> Client: >>> 1. ClientHello.java:633|Produced ClientHello handshake message >>> 2. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 204 >>> Server: >>> 3. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 204 >>> 4. ClientHello.java:788|Consuming ClientHello handshake message >>> 5. ClientHello.java:818|Negotiated protocol version: TLSv1.2 >>> 6. ServerHello.java:361|Produced ServerHello handshake message >>> 7. CertificateMessage.java:263|Produced server Certificate handshake message >>> 8. ServerHelloDone.java:97|Produced ServerHelloDone handshake message >>> 9. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 1086 >>> Client: >>> 10. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 1086 >>> 11. ServerHello.java:862|Consuming ServerHello handshake message >>> 12. ServerHello.java:958|Negotiated protocol version: TLSv1.2 >>> 13. CertificateMessage.java:358|Consuming server Certificate handshake message >>> 14. ServerHelloDone.java:142|Consuming ServerHelloDone handshake message >>> 15. RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange handshake message >>> 16. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >>> 17. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >>> 18. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 262 >>> 19. SSLEngineOutputRecord.java:465|WRITE: TLS12 change_cipher_spec, length = 1 >>> 20. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 16 >>> At this point I do not send that data yet to the server. The client has produced the client key exchange and client finished messages. But they are still in transit (in this scenario). >>> Server (we manually call closeOutboud() because we have decided we need to close this socket): >>> 21. SSLEngineImpl.java:745|Closing outbound of SSLEngine >>> 22. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 >>> 23. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 5A ......Z) >>> - I believe this is user_canceled alert >>> 24. SSLEngineOutputRecord.java:465|Raw write (0000: 15 03 03 00 02 01 00 .......) >>> - I believe this is close_notify >>> At this point: >>> Server engine.isOutboundDone() = true >>> Server engine.isInboundDone() = false >>> Client: >>> 24. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >>> 25. Alert.java:232|Received alert message ("Alert": {"level" : "warning", "description": "user_canceled"}) >>> 26. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >>> 27. Alert.java:232|Received alert message ("Alert": {"level": "warning", "description": "close_notify"}) >>> 28. Fatal (UNEXPECTED_MESSAGE): Received close_notify during handshake ( >>> "throwable" : { >>> javax.net.ssl.SSLProtocolException: Received close_notify during handshake >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) >>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) >>> At this point I want to note that it feels weird that this produces an exception. The other side said "user_canceled" and then sent "close_notify". That seems correct to me? So it feels weird that consumers of the SSlEngine have to handle this exception and then continue using the engine for a proper close. That's just a side note. I (think) this behavior is not new. But it seems odd. >>> At this point: >>> Client engine.isOutboundDone() = false >>> Client engine.isInboundDone() = true >>> Still Client: >>> 29. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 >>> 30. SSLCipher.java:1726|Plaintext before ENCRYPTION (0000: 02 0A ..) >>> 31. 2018-08-04 05:16:34.300 KGT|SSLEngineOutputRecord.java:483|Raw write ( >>> 0000: 15 03 03 00 1A 00 00 00 00 00 00 00 01 E2 36 F9 ..............6. >>> 0010: 09 D2 20 65 B5 C9 04 CB D3 47 8B E2 CA 0B B2 .. e.....G..... >>> ) >>> - I believe this is unexpected_message. And I believe it is encrypted at this point as the client has sent the client finished message. This alert feels incorrect to me. The server sent "user_canceled". I feel like once that is sent, we should be able to receive "close_notify" without the client engine identifying this as an unexpected message. >>> At this point: >>> Client engine.isOutboundDone() = true >>> Client engine.isInboundDone() = true >>> That seems correct to me. We need to flush the last alert for the client and then we are done with the engine (although I believe the alert should be close_notify and not unexpected_message). >>> At this point the server starts receiving all the handshake messages from the client. >>> Server: >>> 32. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 262 >>> 33. RSAClientKeyExchange.java:279|Consuming RSA ClientKeyExchange handshake message >>> 34. SSLEngineInputRecord.java:214|READ: TLSv1.2 change_cipher_spec, length = 1 >>> 35. ChangeCipherSpec.java:143|Consuming ChangeCipherSpec message >>> 36. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 40 >>> 37. Finished.java:581|Consuming client Finished handshake message. >>> At this point: >>> Server engine.isOutboundDone() = false >>> Server engine.isInboundDone() = false >>> That seems completely wrong to me. We manually told the server outbound was done. But receiving the final handshake messages has put it back to outbound not being done. Additionally, at this point the server's handshake status is NEED_WRAP and NEED_TASK. It looks like it is trying to continue handshaking. >>> Still Server: >>> 38. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >>> 39. Finished.java:450|Produced server Finished handshake message >>> 40. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 26 >>> 41. Alert.java:232|Received alert message >>> 42. TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Received fatal alert: unexpected_message ( >>> "throwable" : { >>> javax.net.ssl.SSLProtocolException: Received fatal alert: unexpected_message >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) >>> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:281) >>> At this point the server engine has received the alert. That throws an exception. And the engine still seems to be in an incorrect "done" state. >>> At this point: >>> Server engine.isOutboundDone() = false >>> Server engine.isInboundDone() = true >>> Let me know if you have any questions. The particular point where we send close_notify from the server to the client is just incidental from how our "close during handshake" test works. Sending it at other points in the handshake process may produce different outcomes. >>> Thanks, >>> Tim >>>> On Jul 30, 2018, at 12:13 PM, Xuelei Fan wrote: >>>> >>>> Hi Tim, >>>> >>>> Would you mind look at the code I posted in the following thread: >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>>> >>>> In the update, we are trying make the synchronization more simple and robust. I appreciate if you could comment by the end of this week. >>>> >>>> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way because TLS 1.2 and prior version can work around it. But for TLS 1.3, it is possible to hang the application if the connection is not closed. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 7/18/2018 11:51 AM, Tim Brooks wrote: >>>>> Yes. I can test once there is a patch. My inquiry was motivated by some work on Elasticsearch fyi. I can test a patch against that work. >>>>> https://github.com/elastic/elasticsearch/issues/32144 >>>>> - Tim >>>>>> On Jul 17, 2018, at 8:40 PM, Xuelei Fan > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> We are working on the JDK 11 close issue. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207009 >>>>>> >>>>>> I appreciate if you can help test if we have a patch. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 7/17/2018 4:26 PM, Tim Brooks wrote: >>>>>>> My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. >>>>>>> One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: >>>>>>> 1. Initiate handshake >>>>>>> 2. UNWRAP data from client >>>>>>> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >>>>>>> 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). >>>>>>> 5. Handshake status now returns "NEED_WRAP" >>>>>>> JDK10: >>>>>>> isInboundDone() - returns false >>>>>>> isOutboundDone() - returns false >>>>>>> A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. >>>>>>> isInboundDone() - returns false >>>>>>> isOutboundDone() - returns true >>>>>>> JDK11: >>>>>>> isInboundDone() - returns true >>>>>>> isOutboundDone() - returns false >>>>>>> A call to wrap() throws the following exception: >>>>>>> javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed >>>>>>> at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >>>>>>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >>>>>>> I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. From roger.riggs at oracle.com Tue Aug 7 14:57:27 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 7 Aug 2018 10:57:27 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com> References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com> Message-ID: Hi Max, It may be useful to include in the descriptions a reminder that if no ObjectInputFilter is supplied the global filter is used.? Details in ObjectInputStream. Typically, the @throws clauses that are not full sentences do not include a final period "." For consistency with the existing javadoc, omit the "." For example, SealedObject.java:191, 239, 240, 330 SignedObject.java: 128, 130, 229, 252, 253 While you are editing SealedObject.java: 143-145, please indent the continuation lines of @throws. Are there any caveats on what the serial filter needs to allow when used in SealedObject or SignedObject? Thanks, Roger On 8/7/18 2:31 AM, Weijun Wang wrote: > Please review the code change at > > webrev: http://cr.openjdk.java.net/~weijun/8193859/webrev.00/ > > where > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193859 > CSR: https://bugs.openjdk.java.net/browse/JDK-8193887 > > Thanks > Max > > From oddbjornkvalsund at gmail.com Tue Aug 7 05:36:10 2018 From: oddbjornkvalsund at gmail.com (=?UTF-8?Q?Oddbj=C3=B8rn_Kvalsund?=) Date: Tue, 7 Aug 2018 07:36:10 +0200 Subject: JDK-6782021 Message-ID: Hi, I was just bit by this issue [JDK-6782021] It is not possible to read local computer certificates with the SunMSCAPI provider and from StackOverflow I notice that several other people (see [1][2][3]) have come across the same problem. Coming up on the 10th anniversary for this issue; any chance we'll see some love for it? Or at least a comment on the issue on what timeline to expect and a list of workaround/alternative solutions for the meantime? Background: I'm working with a company having primarily Microsoft infrastructure and they have a routine where all Windows servers automatically receive new certificates/keys when the old ones expire. These certificates are installed in the "Local Computer ? Private" certificate store. They're quite fond of this system and hesitant to diverge from it, so my preferred option is to just "get with the program". To temporarily get around JDK-6782021 I created a small utility [5] that intercepts the JDKs call to 'CertOpenSystemStore' [4] and presents a read-only virtual certificate store combining all certificates and keys from the "Current User" and "Local Computer" certificate stores, but this may have unexpected implications that I've not yet uncovered, so I'd much prefer not having to do this. A more thorough solution would be to use the commercial Pheox JCAPI [6] product, but this is rather expensive and way overkill for what I (and most others, it seems) need. References: [1] https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java/51708360 [2] https://stackoverflow.com/questions/51205158/access-windows-local-machine-personal-keystore-with-java-sunmscapi [3] https://stackoverflow.com/questions/51193143/use-jna-to-get-local-machine-certificate [4] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp [5] https://github.com/oddbjornkvalsund/wcsa [6] https://pheox.com/products/jcapi/ Best regards, Oddbj?rn Kvalsund -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Aug 7 16:58:03 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 7 Aug 2018 12:58:03 -0400 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> Message-ID: <5426b607-1a45-02bb-f2ce-61a71ea36c16@oracle.com> On 8/6/18 8:20 PM, Weijun Wang wrote: >> I'm not seeing how this would be a behavior change if it is a new option, can you add more details on that? If I specify -providerName, intuitively I would expect it would be used, at least as the first one. > Before this change when "keytool -importcert" is called, KeyStore.getInstance() uses "-providername" but CertificateFactory.getInstance()*does not*. Now CertificateFactory.getInstance() is using it. If it's preferred than the default provider, then it's a behavior change. Ok, I see. But this is the first time we have had issues with CertificateFactory. And we probably want to avoid having multiple -providerName options for each JCA engine that is used. But keytool -printcert does not interact with a KeyStore at all. Couldn't you distinguish between the two options and always use -providerName for CertificateFactory for -printcert? --Sean From anthony.scarpino at oracle.com Tue Aug 7 19:17:08 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Aug 2018 12:17:08 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS Message-ID: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> I need a review of a CSR for SSLSocket should throw an exception when configuring DTLS. We are targeting this for 12 right now. https://bugs.openjdk.java.net/browse/JDK-8209031 thanks Tony From sean.mullan at oracle.com Tue Aug 7 20:35:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 7 Aug 2018 16:35:13 -0400 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> Message-ID: There are a few typos in the CSR and an unfinished sentence in the Summary. I think the Solution or Specification should say what standard APIs the underlying impl will be throwing an UnsupportedOperationException, i.e. SSLContextSpi.engineGetSocketFactory and engineGetServerSocketFactory. It's not apparent from the diffs unless you compare it against the full source code, so I think it would be helpful so you don't need to do that. I also think the Interface Kind should be "Java API" since you are changing the JSSE DTLS implementation of a standard API. Otherwise, looks ok. --Sean On 8/7/18 3:17 PM, Anthony Scarpino wrote: > I need a review of a CSR for SSLSocket should throw an exception when > configuring DTLS.? We are targeting this for 12 right now. > > https://bugs.openjdk.java.net/browse/JDK-8209031 > > thanks > > Tony > From xuelei.fan at oracle.com Tue Aug 7 20:43:17 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Aug 2018 13:43:17 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> Message-ID: Hi Tony, Would you mind make it clear that this impact the JDK JSSE provider only? Third party's provider may be able to support DTLS with SSLSocket. I think there may be no specification change. The SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory() defines the spec if the algorithm is not supported by the underlying provider, "UnsupportedOperationException - if the underlying provider does not implement the operation.". I may prefer to make it clear that this is just a behavior change of the JDK JSSE provider (SunJSSE). The SunJSSE provider now throws UnsupportedOperationException for creating SSL(Server)SocketFactory with DTLS SSLContext, because it does not actually support DTLS SSLSocket. In Solution section, "Throwing a UnsupportedOperationException when getting a socket from the SSLServerSocketFactory or SSLSocketFactory for DTLS." I guess you meant, throwing a UOE when calling SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? Thanks, Xuelei On 8/7/2018 12:17 PM, Anthony Scarpino wrote: > I need a review of a CSR for SSLSocket should throw an exception when > configuring DTLS.? We are targeting this for 12 right now. > > https://bugs.openjdk.java.net/browse/JDK-8209031 > > thanks > > Tony > From jamil.j.nimeh at oracle.com Tue Aug 7 22:12:24 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 7 Aug 2018 15:12:24 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> Message-ID: <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> Hi Xuelei, mostly small stuff: * SSLEngineImpl.java o 717: Nit, inbout --> inbound * SSLEngineOutputRecord.java o 162, 169: Nit, applicatoin --> application o Same section: It looks like the "if" and "else if" clauses take the same actions with the same message.? Maybe just do "if (isClosed())" ?? Or were you planning to have different messages here? * SSLSocketOutputRecord.java o 58, 97, 204: Typo,? closedd --> closed * TLSEngineClosureTest.java o 2: Copyright date fix o 26: If this is a new test should the bug ID be different than 8085979? --Jamil On 08/07/2018 07:46 AM, Xuelei Fan wrote: > New webrev: > http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ > > Thanks for a find of Tim Brooks, that the SSLEngine inbound/outbound > status is incorrect if closing during handshake. The above webrev is > trying to fix the problems.? See more in the OpenJDK thread: > http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html > > > Please let me know your concerns before this Wednesday. > > Thanks, > Xuelei > > On 8/3/2018 1:55 PM, Xuelei Fan wrote: >> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >> >> In webrev.01, the socket close may be blocked by super class close >> synchronization.? Updated the SSLSocketImpl.java to use handshake >> only lock in the startHandshake() implementation. >> >> Thanks, >> Xuelei >> >> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>> >>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>> renegotiation fails if Java client allows TLSv1.3". >>> SSLHandshake.java is updated to use negotiated version so that TLS >>> 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>> >>>> Please let me know your concerns by the end of August 1st, 2018. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review the update for the TLS 1.3 half-close and >>>>> synchronization implementation: >>>>> ??? http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>> >>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify >>>>> is use to close the local write side and peer read side only.? >>>>> After the close_notify get handles, the local read side and peer >>>>> write side may still be open. >>>>> >>>>> In this update, if an application calls >>>>> SSLEngine.closeInbound/Outbound() or >>>>> SSLSocket.shutdownInput/Output(), half-close will be used.? For >>>>> compatibility, if SSLSocket.close() get called, a duplex close >>>>> will be tried.? In order to support duplex close, JDK will use the >>>>> user_canceled warning alert even the handshake complete. >>>>> >>>>> In practice, an application may only close outbound even it is >>>>> intended to close the inbound as well, or close the connection >>>>> completely.? It works for TLS 1.2 and prior versions.? But no more >>>>> for TLS 1.3 because of the close_notify behavior change in the TLS >>>>> 1.3 specification.? The application may be hung and dead-waiting >>>>> for read/close.? It could be solved by closing the inbound >>>>> explicitly. In order to mitigate the impact, a new System Property >>>>> is introduced, "jdk.tls.acknowledgeCloseNotify" if source code >>>>> update is not available. ??If the System Property is set to >>>>> "true", if receiving the close_notify, a close_notify alert will >>>>> be responded.? It is a countermeasure of the TLS 1.3 half-close >>>>> issues. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Aug 7 23:14:20 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Aug 2018 16:14:20 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> Message-ID: Hi Xuelei, I have updated the csr and I believe I have addressed your comments. thanks Tony On 08/07/2018 01:43 PM, Xuelei Fan wrote: > Hi Tony, > > Would you mind make it clear that this impact the JDK JSSE provider > only?? Third party's provider may be able to support DTLS with SSLSocket. > > I think there may be no specification change.? The > SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory() > defines the spec if the algorithm is not supported by the underlying > provider, "UnsupportedOperationException - if the underlying provider > does not implement the operation.".? I may prefer to make it clear that > this is just a behavior change of the JDK JSSE provider (SunJSSE).? The > SunJSSE provider now throws UnsupportedOperationException for creating > SSL(Server)SocketFactory with DTLS SSLContext, because it does not > actually support DTLS SSLSocket. > > In Solution section, "Throwing a UnsupportedOperationException when > getting a socket from the SSLServerSocketFactory or SSLSocketFactory for > DTLS."?? I guess you meant, throwing a UOE when calling > SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? > > Thanks, > Xuelei > > On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >> I need a review of a CSR for SSLSocket should throw an exception when >> configuring DTLS.? We are targeting this for 12 right now. >> >> https://bugs.openjdk.java.net/browse/JDK-8209031 >> >> thanks >> >> Tony >> From xuelei.fan at oracle.com Wed Aug 8 00:05:01 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Aug 2018 17:05:01 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> Message-ID: <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> Hi Tony, The Specification section looks more like the implementation details. We may change the implementation details again in the future. It may be more suitable to move it to the Solution section, or just remove it. In the Specification section, I may just say something like, "No APIs changes. The SunJSSE provider is updated to throw UnsupportedOperationException if SSLContext.SSLServerSocketFactory() or SSLContext.SSLSocketFactory() get called for DTLS algorithms SSLContext". Thanks, Xuelei On 8/7/2018 4:14 PM, Anthony Scarpino wrote: > Hi Xuelei, > > I have updated the csr and I believe I have addressed your comments. > > thanks > > Tony > > On 08/07/2018 01:43 PM, Xuelei Fan wrote: >> Hi Tony, >> >> Would you mind make it clear that this impact the JDK JSSE provider >> only?? Third party's provider may be able to support DTLS with SSLSocket. >> >> I think there may be no specification change.? The >> SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory() >> defines the spec if the algorithm is not supported by the underlying >> provider, "UnsupportedOperationException - if the underlying provider >> does not implement the operation.".? I may prefer to make it clear >> that this is just a behavior change of the JDK JSSE provider >> (SunJSSE).? The SunJSSE provider now throws >> UnsupportedOperationException for creating SSL(Server)SocketFactory >> with DTLS SSLContext, because it does not actually support DTLS >> SSLSocket. >> >> In Solution section, "Throwing a UnsupportedOperationException when >> getting a socket from the SSLServerSocketFactory or SSLSocketFactory >> for DTLS."?? I guess you meant, throwing a UOE when calling >> SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? >> >> Thanks, >> Xuelei >> >> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>> I need a review of a CSR for SSLSocket should throw an exception when >>> configuring DTLS.? We are targeting this for 12 right now. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>> >>> thanks >>> >>> Tony >>> > From xuelei.fan at oracle.com Wed Aug 8 00:24:04 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Aug 2018 17:24:04 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> Message-ID: <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> Hi Jamil, Thanks for comments. Here is the updated webrev: http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/ Thanks, Xuelei On 8/7/2018 3:12 PM, Jamil Nimeh wrote: > Hi Xuelei, mostly small stuff: > > * SSLEngineImpl.java > o 717: Nit, inbout --> inbound > * SSLEngineOutputRecord.java > o 162, 169: Nit, applicatoin --> application > o Same section: It looks like the "if" and "else if" clauses take > the same actions with the same message.? Maybe just do "if > (isClosed())" ?? Or were you planning to have different messages > here? > * SSLSocketOutputRecord.java > o 58, 97, 204: Typo,? closedd --> closed > * TLSEngineClosureTest.java > o 2: Copyright date fix > o 26: If this is a new test should the bug ID be different than > 8085979? > > --Jamil > > > On 08/07/2018 07:46 AM, Xuelei Fan wrote: >> New webrev: >> http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ >> >> Thanks for a find of Tim Brooks, that the SSLEngine inbound/outbound >> status is incorrect if closing during handshake. The above webrev is >> trying to fix the problems.? See more in the OpenJDK thread: >> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html >> >> >> Please let me know your concerns before this Wednesday. >> >> Thanks, >> Xuelei >> >> On 8/3/2018 1:55 PM, Xuelei Fan wrote: >>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >>> >>> In webrev.01, the socket close may be blocked by super class close >>> synchronization.? Updated the SSLSocketImpl.java to use handshake >>> only lock in the startHandshake() implementation. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>>> >>>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>>> renegotiation fails if Java client allows TLSv1.3". >>>> SSLHandshake.java is updated to use negotiated version so that TLS >>>> 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>>> >>>>> Please let me know your concerns by the end of August 1st, 2018. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the update for the TLS 1.3 half-close and >>>>>> synchronization implementation: >>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>>> >>>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify >>>>>> is use to close the local write side and peer read side only. >>>>>> After the close_notify get handles, the local read side and peer >>>>>> write side may still be open. >>>>>> >>>>>> In this update, if an application calls >>>>>> SSLEngine.closeInbound/Outbound() or >>>>>> SSLSocket.shutdownInput/Output(), half-close will be used.? For >>>>>> compatibility, if SSLSocket.close() get called, a duplex close >>>>>> will be tried.? In order to support duplex close, JDK will use the >>>>>> user_canceled warning alert even the handshake complete. >>>>>> >>>>>> In practice, an application may only close outbound even it is >>>>>> intended to close the inbound as well, or close the connection >>>>>> completely.? It works for TLS 1.2 and prior versions.? But no more >>>>>> for TLS 1.3 because of the close_notify behavior change in the TLS >>>>>> 1.3 specification.? The application may be hung and dead-waiting >>>>>> for read/close.? It could be solved by closing the inbound >>>>>> explicitly. In order to mitigate the impact, a new System Property >>>>>> is introduced, "jdk.tls.acknowledgeCloseNotify" if source code >>>>>> update is not available. ??If the System Property is set to >>>>>> "true", if receiving the close_notify, a close_notify alert will >>>>>> be responded.? It is a countermeasure of the TLS 1.3 half-close >>>>>> issues. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> >>>>>> > From valerie.peng at oracle.com Wed Aug 8 00:41:55 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 7 Aug 2018 17:41:55 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: Message-ID: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> Hi Martin, Thanks for the update, I will resume the review on this one with your latest webrev. BTW, there is no webrev.07 for your other fix, i.e. JDK-8029661, right? Just checking. Regards, Valerie On 8/3/2018 2:13 PM, Martin Balao wrote: > Hi Valerie, > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip > > > New in webrev 10: > > ?* Bug fix when private DSA/EC keys are sensitive > ? * I found this bug removing "attributes = compatibility" entry in > NSS configuration file so keys were CKA_SENSITIVE. > ? * This is really an NSS bug when unwrapping ephemeral keys > (NSC_UnwrapKey function), because CKA_NETSCAPE_DB attribute is > required but not used/needed. There was a similar bug when creating > objects (NSC_CreateObject function), fixed many years ago [1]. > ? * In those cases in which the bug occurs (private keys, of DSA/EC > type, sensitive and without CKA_NETSCAPE_DB attribute set), I store an > empty CKA_NETSCAPE_DB attribute in the buffer that will later be used > for key unwrapping. I'm not doing a C_SetAttributeValue call because > keys are read-only. We can let users set CKA_NETSCAPE_DB attribute in > NSS configuration file [2] but this would be a workaround on users side. > ? * Changes in: > ? ?* p11_keymgmt.c > ? ? * L175-187, L212-214 and L275-278 > > ?* Bug fix when storing sensitive RSA keys in a keystore > ? * CKA_NETSCAPE_DB attribute is not needed so we return it as null > (instead of failing with an "Invalid algorithm" message) > ? * Changes in: > ? ?* P11KeyStore.java > ? ? * L1909-1914 > > ?* Lines length was cut to improve code readability > > Regression tests on jdk/sun/security/pkcs11 category passed. I ran my > internal test suite too, that covers the following services (with > SunPKCS11 provider): Cipher, Signature, KeyAgreement, Digest, Mac, > KeyGenerator, KeyPairGenerator and Keystore. > > Kind regards, > Martin.- > > -- > [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=309701#c6 > > [2] - > https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/test/sun/security/pkcs11/fips/fips.cfg.shtml > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Wed Aug 8 00:45:41 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 7 Aug 2018 17:45:41 -0700 Subject: Exception Reporting Difference Message-ID: <57d7fd74-3c2c-67d6-a8bd-8c30f32ce1e3@oracle.com> Hi Xuelei, We've noticed a significant difference in the way exceptions are being reported/consumed post TLSv1.3 integration. In the original SSLEngine API/implementation, my design was to fail-fast and let the application know of problems immediately, then the app could recover and close by doing the necessary I/O. If some call generated a Exception/Alert (from a warning (connection stays open) or fatal (connection must close)), the Exception would be reported immediately, and then the SSLEngine could continue on and continue to consume/produce as required, closing/alerting if necessary, or just carrying on if it's only a warning. You'd wrap the outbound alert later. For example, in the case of a failed ALPN negotiation, say the client server set the ALPN values to something that doesn't intersect, and the connection will fail: // produce CH+ALPN ext. client.wrap(); // OK/NEED_UNWRAP // consume CH+ALPN ext. server.unwrap(); // OK/NEED_TASK // Generate Exception/Alert which is placed in outbound queue. serverTask.run(); // no output/exception yet // Let caller immediately know server is in trouble. server.wrap(); // throws SSLHandshakeException (No matching // ALPN), server.getHandshakeStatus() = NEED_WRAP // produce the alert for client. server.unwrap(); // optional: CLOSED/NEED_WRAP server.wrap(); // wraps alert (7 bytes), CLOSED/NEED_UNWRAP // // I think the NEED_UNWRAP is an existing bug. // A fatal alert should be close the connection, // with no more handshaking possible. // Client receives alert, report trouble. client.unwrap(); // throws SSLHandshakeException // (no task necessary) // getHandshakeStatus() = NOT_HANDSHAKING both isInboundDone()/isOutboundDone() are true. At this point, both sides are closed. In the new code we have: // produce CH+ALPN ext. client.wrap(); // OK/NEED_UNWRAP // consume CH+ALPN ext. server.unwrap(); // OK/NEED_TASK // Generate Exception/Alert which is placed in outbound queue. serverTask.run(); // no output/exception yet *DIFFERENCE starts here* // Does not let caller immediately know that server had trouble. // Just quietly succeeds. server.wrap(); // wraps alert, returns CLOSED/NOT_HANDSHAKING // Client receives alert, parses client.unwrap(); // Reports SSLSHandshakeException // getHandshakeStatus() = NOT_HANDSHAKING server.unwrap(); // throws SSLHandshakeException (No matching // ALPN) // server.getHandshakeStatus() = NOT_HANDSHAKING both isInboundDone()/isOutboundDone() are true. While ultimately the final state eventually becomes the same, it's strange to me that the caller can suddenly transition from a seemingly fine state to closed and NOT_HANDSHAKING with no warning. Existing apps closely following the handshake (isIn/OutboundDone()) state may be surprised to see this, and may not know that an extra wrap()/unwrap() after the engine is CLOSED/NOT_HANDSHAKING is now needed to get the true underlying cause of the error. The attached test passes with both implementations only because of the way it was written (client.wrap/server.wrap/client.unwrap/server.unwrap), but it wouldn't if the loop was just looking for isIn/OutboundClosed(), and the exception would go missing. I'm just not comfortable with the new implementation. Thanks, Brad -------------- next part -------------- import static javax.net.ssl.SSLEngineResult.HandshakeStatus; import javax.net.ssl.*; import java.io.FileInputStream; import java.io.UnsupportedEncodingException; import java.nio.ByteBuffer; import java.nio.charset.Charset; import java.security.KeyStore; import java.security.SecureRandom; public class TestSSLEngineALPN { private KeyStore ks = null; private String keystore = "D:\\intellij\\JCK11\\api\\tests\\api\\javax_net\\ssl\\testkeyspkcs"; private String ksPassword = "DukesSecretPassword"; private char[] passphrase = ksPassword.toCharArray(); private ByteBuffer clientIn; private ByteBuffer serverIn; private ByteBuffer clientToServer; private ByteBuffer serverToClient; private ByteBuffer clientOut; private ByteBuffer serverOut; private static boolean resultOnce = true; private SSLEngineResult clientResult; private SSLEngineResult serverResult; public static void main(String[] args) throws Exception{ new TestSSLEngineALPN().test(); } private void test() throws Exception { String[] clientStrings = { "placeholder", "http/1.1" }; String[] serverStrings = { "h2" }; SSLContext sslContext = createInitSSLContext(); SSLEngine clientEngine = sslContext.createSSLEngine(); SSLEngine serverEngine = sslContext.createSSLEngine(); createBuffers(clientEngine); clientEngine.setUseClientMode(true); serverEngine.setUseClientMode(false); serverEngine.setNeedClientAuth(true); //set client and server application protocol. SSLParameters paramsClient = clientEngine.getSSLParameters(); paramsClient.setApplicationProtocols(clientStrings); clientEngine.setSSLParameters(paramsClient); SSLParameters paramsServer = serverEngine.getSSLParameters(); paramsServer.setApplicationProtocols(serverStrings); serverEngine.setSSLParameters(paramsServer); clientResult = clientEngine.unwrap(serverToClient, clientIn); serverResult = serverEngine.wrap(serverOut, clientToServer); checkHandshakeResult(clientResult,HandshakeStatus.NEED_WRAP,0,0,false); checkHandshakeResult(serverResult,HandshakeStatus.NEED_UNWRAP,0,0,false); //complete handshake and exchange some data if(!doHandShakeAppData(clientEngine, serverEngine)){ System.out.println("********************************************************"); System.out.println("Handshake failed with SSLException during SSLEngine#wrap, This is OK, when " + "negotiation fail"); System.out.println("********************************************************"); return; } try { // No common application protocols. Underlying protocol can determine what to do. // It is very possible that the handshake throws an exception and we never get here String negotiatedALPN = clientEngine.getApplicationProtocol(); // If we do get here, the negotiated application protocols should be an empty string assert "".equals(negotiatedALPN); } catch (UnsupportedOperationException uoe) { System.out.println("UnsupportedOperationException Caught - expected if provider does not support " + "getApplicationProtocol()"); } } private boolean doHandShakeAppData(SSLEngine clientEngine, SSLEngine serverEngine) throws Exception { System.out.println("============HANDSHAKE STARTED============"); clientEngine.beginHandshake(); serverEngine.beginHandshake(); while(!isNotHandshaking()){ System.out.println("================"); clientResult = clientEngine.wrap(clientOut, clientToServer); log("client wrap: ", clientResult); runDelegatedTasks(clientResult, clientEngine); try{ serverResult = serverEngine.wrap(serverOut, serverToClient); log("server wrap: ", serverResult); if(serverResult.getStatus() == SSLEngineResult.Status.CLOSED){ System.out.println("********************************************************************************"); System.out.println("SSLEngine#wrap does not throw SSLException with JDKb20 , it closed the server, " + "Please run with JDKb15 and you will receive SSLException "); serverToClient.flip(); byte[] sToCBytes = new byte[serverToClient.limit()]; serverToClient.get(sToCBytes, 0, sToCBytes.length); System.out.println("Generated bytes during the closure is :"+ new String(sToCBytes)); System.out.println("********************************************************************************"); //System.exit(-1); } }catch (SSLException e){ //e.printStackTrace(); return false; } runDelegatedTasks(serverResult, serverEngine); clientToServer.flip(); serverToClient.flip(); //Handshake ends here,hence below unwrap is missed , // so additional unwrap needs to be done after handshake if(isNotHandshaking()){ System.out.println("Breaking..."); break; } System.out.println("----"); clientResult = clientEngine.unwrap(serverToClient, clientIn); log("client unwrap: ", clientResult); runDelegatedTasks(clientResult, clientEngine); serverResult = serverEngine.unwrap(clientToServer, serverIn); log("server unwrap: ", serverResult); runDelegatedTasks(serverResult, serverEngine); clientToServer.compact(); serverToClient.compact(); } System.out.println("============HANDSHAKE COMPLETE============"); return true; } /* * If the result indicates that we have outstanding tasks to do, * go ahead and run them in this thread. */ private static void runDelegatedTasks(SSLEngineResult result, SSLEngine engine) throws Exception { if (result.getHandshakeStatus() == HandshakeStatus.NEED_TASK) { Runnable runnable; while ((runnable = engine.getDelegatedTask()) != null) { System.out.println("\trunning delegated task..."); runnable.run(); } HandshakeStatus hsStatus = engine.getHandshakeStatus(); if (hsStatus == HandshakeStatus.NEED_TASK) { throw new Exception( "handshake shouldn't need additional tasks"); } System.out.println("\tnew HandshakeStatus: " + hsStatus); } } private static void log(String str, SSLEngineResult result) { if (resultOnce) { resultOnce = false; System.out.println("The format of the SSLEngineResult is: \n" + "\t\"getStatus() / getHandshakeStatus()\" +\n" + "\t\"bytesConsumed() / bytesProduced()\"\n"); } HandshakeStatus hsStatus = result.getHandshakeStatus(); System.out.println(str + result.getStatus() + "/" + hsStatus + ", " + result.bytesConsumed() + "/" + result.bytesProduced() + " bytes"); if (hsStatus == HandshakeStatus.FINISHED) { System.out.println("\t...ready for application data"); } } private boolean isNotHandshaking() { return clientResult.getHandshakeStatus() == HandshakeStatus.NOT_HANDSHAKING && serverResult.getHandshakeStatus() == HandshakeStatus.NOT_HANDSHAKING; } private void createBuffers(SSLEngine sse1) { SSLSession session = sse1.getSession(); int appBufferMax = session.getApplicationBufferSize(); int netBufferMax = session.getPacketBufferSize(); clientIn = ByteBuffer.allocateDirect(appBufferMax); serverIn = ByteBuffer.allocateDirect(appBufferMax); clientToServer = ByteBuffer.allocateDirect(netBufferMax); serverToClient = ByteBuffer.allocateDirect(netBufferMax); try { String clientMessae = "Good Morning Server, I'm Client"; clientOut = ByteBuffer.wrap(clientMessae.getBytes("ISO-8859-1")); String serverMesage = "Greetings from Server"; serverOut = ByteBuffer.wrap(serverMesage.getBytes("ISO-8859-1")); } catch (UnsupportedEncodingException uee) { // Should never happen throw new RuntimeException("getBytes(ISO-8859-1) threw an UnsupportedEncodingException", uee); } } void checkHandshakeResult(SSLEngineResult result, HandshakeStatus status, int consumed, int produced, boolean done) { boolean returnCode = true; if ((status != null) && (result.getHandshakeStatus() != status)) { returnCode = false; System.err.println("Unexpected Status: need = " + status + " got = " + result.getStatus()); System.exit(1); } if ((consumed != -1) && (consumed != result.bytesConsumed())) { returnCode = false; System.err.println("Unexpected consumed: need = " + consumed + " got = " + result.bytesConsumed()); System.exit(1); } if ((produced != -1) && (produced != result.bytesProduced())) { returnCode = false; System.err.println("Unexpected produced: need = " + produced + " got = " + result.bytesProduced()); System.exit(1); } if (done && (status == HandshakeStatus.FINISHED)) { returnCode = false; System.err.println("Handshake already reported finished"); System.exit(1); } } private SSLContext createInitSSLContext() throws Exception { SSLContext sslContext = SSLContext.getInstance("TLSv1.2"); KeyManagerFactory kmf = null; TrustManagerFactory tmf = null; kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()); tmf = TrustManagerFactory.getInstance("PKIX"); ks = KeyStore.getInstance("PKCS12"); ks.load(new FileInputStream(keystore), passphrase); kmf.init(ks, passphrase); tmf.init(ks); sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), new SecureRandom()); return sslContext; } } From weijun.wang at oracle.com Wed Aug 8 03:53:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 8 Aug 2018 11:53:16 +0800 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: <5426b607-1a45-02bb-f2ce-61a71ea36c16@oracle.com> References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> <5426b607-1a45-02bb-f2ce-61a71ea36c16@oracle.com> Message-ID: > On Aug 8, 2018, at 12:58 AM, Sean Mullan wrote: > > On 8/6/18 8:20 PM, Weijun Wang wrote: >>> I'm not seeing how this would be a behavior change if it is a new option, can you add more details on that? If I specify -providerName, intuitively I would expect it would be used, at least as the first one. >> Before this change when "keytool -importcert" is called, KeyStore.getInstance() uses "-providername" but CertificateFactory.getInstance()*does not*. Now CertificateFactory.getInstance() is using it. If it's preferred than the default provider, then it's a behavior change. > > Ok, I see. But this is the first time we have had issues with CertificateFactory. And we probably want to avoid having multiple -providerName options for each JCA engine that is used. > > But keytool -printcert does not interact with a KeyStore at all. Couldn't you distinguish between the two options and always use -providerName for CertificateFactory for -printcert? But in a real world people usually run keytool -printcert and then -importcert. -importcert would show the content of the cert if it's not trusted by existing CAs and ask for a yes/no. If people see different output (i.e. toString() of the X509Certificate child in a provider), will that be a little strange? --Max > > --Sean From Yang.Zhang at arm.com Wed Aug 8 04:18:56 2018 From: Yang.Zhang at arm.com (Yang Zhang) Date: Wed, 8 Aug 2018 04:18:56 +0000 Subject: RFR: 8209011: [TESTBUG] AArch64: sun/security/pkcs11/Secmod/TestNssDbSqlite.java fails in aarch64 platforms Message-ID: Hi, Could you please help review the small fix to jtreg test case in jdk "sun/security/pkcs11/Secmod/TestNssDbSqlite.java" ? The failure happens in aarch64 platforms. The path of libnss3.so isn't set correctly. JBS: https://bugs.openjdk.java.net/browse/JDK-8209011 Webrev: http://cr.openjdk.java.net/~yzhang/8209011/webrev.00/ Regards, Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Aug 8 05:35:07 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 8 Aug 2018 13:35:07 +0800 Subject: RFR: 8209011: [TESTBUG] AArch64: sun/security/pkcs11/Secmod/TestNssDbSqlite.java fails in aarch64 platforms In-Reply-To: References: Message-ID: <0F2C0F7B-A706-48D9-A5B6-C5F0B4DB62C4@oracle.com> Change looks good. Do you need me to push the change for you? If yes, show me what changeset comment you'd like. Thanks Max > On Aug 8, 2018, at 12:18 PM, Yang Zhang wrote: > > Hi, > > Could you please help review the small fix to jtreg test case in jdk "sun/security/pkcs11/Secmod/TestNssDbSqlite.java" ? > The failure happens in aarch64 platforms. The path of libnss3.so isn't set correctly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209011 > Webrev: http://cr.openjdk.java.net/~yzhang/8209011/webrev.00/ > > Regards, > Yang From Yang.Zhang at arm.com Wed Aug 8 05:56:41 2018 From: Yang.Zhang at arm.com (Yang Zhang) Date: Wed, 8 Aug 2018 05:56:41 +0000 Subject: RFR: 8209011: [TESTBUG] AArch64: sun/security/pkcs11/Secmod/TestNssDbSqlite.java fails in aarch64 platforms In-Reply-To: <0F2C0F7B-A706-48D9-A5B6-C5F0B4DB62C4@oracle.com> References: <0F2C0F7B-A706-48D9-A5B6-C5F0B4DB62C4@oracle.com> Message-ID: Hi Weijun Thanks for your review and help of pushing the change for me. I have updated the reviewer. http://cr.openjdk.java.net/~yzhang/8209011/webrev.01/ 8209011: [TESTBUG] AArch64: sun/security/pkcs11/Secmod/TestNssDbSqlite.java fails in aarch64 platforms Summary: Add the path of libnss3.so for aarch64 platform. Reviewed-by: weijun Regards Yang -----Original Message----- From: Weijun Wang Sent: Wednesday, August 8, 2018 1:35 PM To: Yang Zhang Cc: security-dev at openjdk.java.net; nd Subject: Re: RFR: 8209011: [TESTBUG] AArch64: sun/security/pkcs11/Secmod/TestNssDbSqlite.java fails in aarch64 platforms Change looks good. Do you need me to push the change for you? If yes, show me what changeset comment you'd like. Thanks Max > On Aug 8, 2018, at 12:18 PM, Yang Zhang wrote: > > Hi, > > Could you please help review the small fix to jtreg test case in jdk "sun/security/pkcs11/Secmod/TestNssDbSqlite.java" ? > The failure happens in aarch64 platforms. The path of libnss3.so isn't set correctly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209011 > Webrev: http://cr.openjdk.java.net/~yzhang/8209011/webrev.00/ > > Regards, > Yang From sean.coffey at oracle.com Wed Aug 8 08:35:17 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 8 Aug 2018 09:35:17 +0100 Subject: JDK-6782021 In-Reply-To: References: Message-ID: <972ae00c-f669-7816-fbb0-44f8f48c9f54@oracle.com> Vinnie is not working on security-libs any more and I think the JBS report should be marked as unassigned.? If any contributors want to suggest a patch, then I think it can be reviewed on this list! regards, Sean. On 07/08/2018 06:36, Oddbj?rn Kvalsund wrote: > Hi, > > I was just bit by this issue [JDK-6782021] It is not possible to read > local computer certificates with the SunMSCAPI provider > ?and from > StackOverflow I notice that several other people (see [1][2][3]) have > come across the same problem. Coming up on the 10th anniversary for > this issue; any chance we'll see some love for it? Or at least a > comment on the issue on what timeline to expect and a list of > workaround/alternative solutions for the meantime? > > Background: I'm working with a company having primarily Microsoft > infrastructure and they have a routine where all Windows servers > automatically receive new certificates/keys when the old ones expire. > These certificates are installed in the "Local Computer ? Private" > certificate store. They're quite fond of this system and hesitant to > diverge from it, so my preferred option is to just "get with the > program". To temporarily get around?JDK-6782021 I created a small > utility [5] that intercepts the JDKs call to 'CertOpenSystemStore' [4] > and presents a read-only virtual certificate store combining all > certificates and keys from the "Current User" and "Local Computer" > certificate stores, but this may have unexpected implications that > I've not yet uncovered, so I'd much prefer not having to do this. A > more thorough solution would be to use the commercial Pheox JCAPI [6] > product, but this is rather expensive and way overkill for what I (and > most others, it seems) need. > > References: > [1] > https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java/51708360 > [2] > https://stackoverflow.com/questions/51205158/access-windows-local-machine-personal-keystore-with-java-sunmscapi > [3] > https://stackoverflow.com/questions/51193143/use-jna-to-get-local-machine-certificate > [4] > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp > [5] https://github.com/oddbjornkvalsund/wcsa > [6] https://pheox.com/products/jcapi/ > > Best regards, > Oddbj?rn Kvalsund -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Wed Aug 8 12:04:24 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 8 Aug 2018 12:04:24 +0000 Subject: JDK-6782021 In-Reply-To: <972ae00c-f669-7816-fbb0-44f8f48c9f54@oracle.com> References: , <972ae00c-f669-7816-fbb0-44f8f48c9f54@oracle.com> Message-ID: Hello, What also should be mentioned is that the old CAPI clients cannot access CNG Keys. Which is especially a pity since only the new keys benefit from the cryptographic process isolation (not to mention the confusion that it?s hard to see which provide hosts them) Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: -980814368m Auftrag von Gesendet: Mittwoch, August 8, 2018 12:35 PM An: Oddbj?rn Kvalsund; security-dev at openjdk.java.net Betreff: Re: JDK-6782021 Vinnie is not working on security-libs any more and I think the JBS report should be marked as unassigned. If any contributors want to suggest a patch, then I think it can be reviewed on this list! regards, Sean. On 07/08/2018 06:36, Oddbj?rn Kvalsund wrote: Hi, I was just bit by this issue [JDK-6782021] It is not possible to read local computer certificates with the SunMSCAPI provider and from StackOverflow I notice that several other people (see [1][2][3]) have come across the same problem. Coming up on the 10th anniversary for this issue; any chance we'll see some love for it? Or at least a comment on the issue on what timeline to expect and a list of workaround/alternative solutions for the meantime? Background: I'm working with a company having primarily Microsoft infrastructure and they have a routine where all Windows servers automatically receive new certificates/keys when the old ones expire. These certificates are installed in the "Local Computer ? Private" certificate store. They're quite fond of this system and hesitant to diverge from it, so my preferred option is to just "get with the program". To temporarily get around JDK-6782021 I created a small utility [5] that intercepts the JDKs call to 'CertOpenSystemStore' [4] and presents a read-only virtual certificate store combining all certificates and keys from the "Current User" and "Local Computer" certificate stores, but this may have unexpected implications that I've not yet uncovered, so I'd much prefer not having to do this. A more thorough solution would be to use the commercial Pheox JCAPI [6] product, but this is rather expensive and way overkill for what I (and most others, it seems) need. References: [1] https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java/51708360 [2] https://stackoverflow.com/questions/51205158/access-windows-local-machine-personal-keystore-with-java-sunmscapi [3] https://stackoverflow.com/questions/51193143/use-jna-to-get-local-machine-certificate [4] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp [5] https://github.com/oddbjornkvalsund/wcsa [6] https://pheox.com/products/jcapi/ Best regards, Oddbj?rn Kvalsund -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Aug 8 14:46:07 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Aug 2018 10:46:07 -0400 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> Message-ID: <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> On 8/7/18 8:05 PM, Xuelei Fan wrote: > Hi Tony, > > The Specification section looks more like the implementation details. We > may change the implementation details again in the future.? It may be > more suitable to move it to the Solution section, or just remove it. I agree, I would omit the diffs and put N/A for the Specification section. > In > the Specification section, I may just say something like, "No APIs > changes.? The SunJSSE provider is updated to throw > UnsupportedOperationException if? SSLContext.SSLServerSocketFactory() or > SSLContext.SSLSocketFactory() get called for DTLS algorithms SSLContext". I think the CSR should also say that the SunJSSE implementation of the engineGetSocketFactory and engineGetServerSocketFactory methods of SSLContextSpi have been changed to throw UnsupportedOperationException. That is the specific API behavior change. A few other comments on the CSR: "SSLContext.getSSLSocketFactory() and SSLContext.getSSLServerSocketFactory()" Typo, there is no "SSL" in the method names. The Compatibility Risk field has several typos ("there" -> "their", "how -> now", ...) and is a bit hard to understand. Wasn't TLS being used before instead of DTLS in certain scenarios? Because the API silently passed in certain cases, and now we will be throwing an Exception, maybe it might be better to say the risk is low. In the Summary section, it says "..., but it is not documented." I suggest opening a docs bug to improve the DTLS documentation so that it is more clear this scenario is not supported. I think the Interface Kind should be Java API since we are changing the behavior of an implementation of a standard API. I asked Joe Darcy this question yesterday, and he agreed. --Sean > > Thanks, > Xuelei > > On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >> Hi Xuelei, >> >> I have updated the csr and I believe I have addressed your comments. >> >> thanks >> >> Tony >> >> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>> Hi Tony, >>> >>> Would you mind make it clear that this impact the JDK JSSE provider >>> only?? Third party's provider may be able to support DTLS with >>> SSLSocket. >>> >>> I think there may be no specification change.? The >>> SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory() >>> defines the spec if the algorithm is not supported by the underlying >>> provider, "UnsupportedOperationException - if the underlying provider >>> does not implement the operation.".? I may prefer to make it clear >>> that this is just a behavior change of the JDK JSSE provider >>> (SunJSSE).? The SunJSSE provider now throws >>> UnsupportedOperationException for creating SSL(Server)SocketFactory >>> with DTLS SSLContext, because it does not actually support DTLS >>> SSLSocket. >>> >>> In Solution section, "Throwing a UnsupportedOperationException when >>> getting a socket from the SSLServerSocketFactory or SSLSocketFactory >>> for DTLS."?? I guess you meant, throwing a UOE when calling >>> SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? >>> >>> Thanks, >>> Xuelei >>> >>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>> I need a review of a CSR for SSLSocket should throw an exception >>>> when configuring DTLS.? We are targeting this for 12 right now. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>> >>>> thanks >>>> >>>> Tony >>>> >> From sean.mullan at oracle.com Wed Aug 8 15:00:38 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Aug 2018 11:00:38 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <9bb8b30850aa48e493a15d48cfd79efa@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> Message-ID: Cross-posting to security-dev since this fix is security related and should also be reviewed there. --Sean On 8/7/18 11:00 AM, Baesken, Matthias wrote: > Ping .... ? , any reviews / comments ? > > Thanks , Matthias > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Dienstag, 31. Juli 2018 12:28 >> To: 'Chris Hegarty' ; Alan Bateman >> >> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz >> ; Langer, Christoph >> >> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest >> parsing of jar archives >> >> Hello , >> looks like the generalization of the `includeInExceptions` security property >> is now in jdk/jdk after >> >> "8207846: Generalize the jdk.net.includeInExceptions security property" >> >> was added, great news and thanks to Chris for driving this ! >> >> I use this security property now as well , and updated the change : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/ >> >> I updated the CSR as well : >> >> https://bugs.openjdk.java.net/browse/JDK-8207768 >> >> >> Best regards, Matthias >> >> >> >>> -----Original Message----- >>> From: Chris Hegarty >>> Sent: Donnerstag, 19. Juli 2018 14:54 >>> To: Alan Bateman ; Baesken, Matthias >>> >>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz >>> >>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest >>> parsing of jar archives >>> >>> >>>> On 19 Jul 2018, at 11:46, Alan Bateman >>> wrote: >>>> >>>> On 19/07/2018 09:07, Baesken, Matthias wrote: >>>>> Hello, in the meantime I prepared a CSR : >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8207768 >>>>> >>>>> >>>>>> jdk.includeInExceptions expands the scope. That might be okay but we >>>>>> will need to re-visit jdk.net.includeInExceptions and also move the >>>>>> support to somewhere in jdk.internal so that it can be used by other >>>>>> code in java.base. >>>>> Is there some support code for " jdk.net.includeInExceptions " or do >>> you just mean the name of the property ? >>>>> >>>> Chris is right that it's a bit premature to submit a CSR while the question >> on >>> whether to rename the existing security property is on the table. I have no >>> objection to doing that. >>> >>> I filed the following issue to generalize the `includeInExceptions` security >>> property: >>> https://bugs.openjdk.java.net/browse/JDK-8207846 >>> >>> I would like to resolve 8207846 first, then 8205525 can propose to add the >>> new argument value, `jarPath`. >>> >>> -Chris. From chris.hegarty at oracle.com Wed Aug 8 15:52:16 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 8 Aug 2018 16:52:16 +0100 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> Message-ID: +1 to everything Sean said, and just to add ... This change will prevent an SSLContext from giving out socket factories when it has been configured with DTLS. What about SSL[Server]SocketFactory::getDefault when the default SSL context is DTLS? I don?t see that getDefault can throw an UOE, should it? Or should / could this be resolved at the socket factory level, when trying to create new sockets rather than at the factory retrieval time? -Chris. > On 8 Aug 2018, at 15:46, Sean Mullan wrote: > > On 8/7/18 8:05 PM, Xuelei Fan wrote: >> Hi Tony, >> The Specification section looks more like the implementation details. We may change the implementation details again in the future. It may be more suitable to move it to the Solution section, or just remove it. > > I agree, I would omit the diffs and put N/A for the Specification section. > >> In the Specification section, I may just say something like, "No APIs changes. The SunJSSE provider is updated to throw UnsupportedOperationException if SSLContext.SSLServerSocketFactory() or SSLContext.SSLSocketFactory() get called for DTLS algorithms SSLContext". > > I think the CSR should also say that the SunJSSE implementation of the engineGetSocketFactory and engineGetServerSocketFactory methods of SSLContextSpi have been changed to throw UnsupportedOperationException. That is the specific API behavior change. > > A few other comments on the CSR: > > "SSLContext.getSSLSocketFactory() and SSLContext.getSSLServerSocketFactory()" > > Typo, there is no "SSL" in the method names. > > The Compatibility Risk field has several typos ("there" -> "their", "how -> now", ...) and is a bit hard to understand. Wasn't TLS being used before instead of DTLS in certain scenarios? Because the API silently passed in certain cases, and now we will be throwing an Exception, maybe it might be better to say the risk is low. > > In the Summary section, it says "..., but it is not documented." I suggest opening a docs bug to improve the DTLS documentation so that it is more clear this scenario is not supported. > > I think the Interface Kind should be Java API since we are changing the behavior of an implementation of a standard API. I asked Joe Darcy this question yesterday, and he agreed. > > --Sean > >> Thanks, >> Xuelei >> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>> Hi Xuelei, >>> >>> I have updated the csr and I believe I have addressed your comments. >>> >>> thanks >>> >>> Tony >>> >>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>> Hi Tony, >>>> >>>> Would you mind make it clear that this impact the JDK JSSE provider only? Third party's provider may be able to support DTLS with SSLSocket. >>>> >>>> I think there may be no specification change. The SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory() defines the spec if the algorithm is not supported by the underlying provider, "UnsupportedOperationException - if the underlying provider does not implement the operation.". I may prefer to make it clear that this is just a behavior change of the JDK JSSE provider (SunJSSE). The SunJSSE provider now throws UnsupportedOperationException for creating SSL(Server)SocketFactory with DTLS SSLContext, because it does not actually support DTLS SSLSocket. >>>> >>>> In Solution section, "Throwing a UnsupportedOperationException when getting a socket from the SSLServerSocketFactory or SSLSocketFactory for DTLS." I guess you meant, throwing a UOE when calling SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>> I need a review of a CSR for SSLSocket should throw an exception when configuring DTLS. We are targeting this for 12 right now. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>> >>>>> thanks >>>>> >>>>> Tony >>>>> >>> From anthony.scarpino at oracle.com Wed Aug 8 17:58:28 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 8 Aug 2018 10:58:28 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> Message-ID: <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> I don't see where your example of getDefault() is any different than the current code path. A user has to define a SSLContext when using getDefault() which as far as I can tell goes through the code path of SSLContext.get[Server]SocketFactory() Tony On 08/08/2018 08:52 AM, Chris Hegarty wrote: > +1 to everything Sean said, and just to add ... > > This change will prevent an SSLContext from giving out socket > factories when it has been configured with DTLS. What about > SSL[Server]SocketFactory::getDefault when the default SSL > context is DTLS? I don?t see that getDefault can throw an UOE, > should it? Or should / could this be resolved at the socket > factory level, when trying to create new sockets rather than at > the factory retrieval time? > > -Chris. > >> On 8 Aug 2018, at 15:46, Sean Mullan wrote: >> >> On 8/7/18 8:05 PM, Xuelei Fan wrote: >>> Hi Tony, >>> The Specification section looks more like the implementation details. We may change the implementation details again in the future. It may be more suitable to move it to the Solution section, or just remove it. >> >> I agree, I would omit the diffs and put N/A for the Specification section. >> >>> In the Specification section, I may just say something like, "No APIs changes. The SunJSSE provider is updated to throw UnsupportedOperationException if SSLContext.SSLServerSocketFactory() or SSLContext.SSLSocketFactory() get called for DTLS algorithms SSLContext". >> >> I think the CSR should also say that the SunJSSE implementation of the engineGetSocketFactory and engineGetServerSocketFactory methods of SSLContextSpi have been changed to throw UnsupportedOperationException. That is the specific API behavior change. >> >> A few other comments on the CSR: >> >> "SSLContext.getSSLSocketFactory() and SSLContext.getSSLServerSocketFactory()" >> >> Typo, there is no "SSL" in the method names. >> >> The Compatibility Risk field has several typos ("there" -> "their", "how -> now", ...) and is a bit hard to understand. Wasn't TLS being used before instead of DTLS in certain scenarios? Because the API silently passed in certain cases, and now we will be throwing an Exception, maybe it might be better to say the risk is low. >> >> In the Summary section, it says "..., but it is not documented." I suggest opening a docs bug to improve the DTLS documentation so that it is more clear this scenario is not supported. >> >> I think the Interface Kind should be Java API since we are changing the behavior of an implementation of a standard API. I asked Joe Darcy this question yesterday, and he agreed. >> >> --Sean >> >>> Thanks, >>> Xuelei >>> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>>> Hi Xuelei, >>>> >>>> I have updated the csr and I believe I have addressed your comments. >>>> >>>> thanks >>>> >>>> Tony >>>> >>>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>>> Hi Tony, >>>>> >>>>> Would you mind make it clear that this impact the JDK JSSE provider only? Third party's provider may be able to support DTLS with SSLSocket. >>>>> >>>>> I think there may be no specification change. The SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory() defines the spec if the algorithm is not supported by the underlying provider, "UnsupportedOperationException - if the underlying provider does not implement the operation.". I may prefer to make it clear that this is just a behavior change of the JDK JSSE provider (SunJSSE). The SunJSSE provider now throws UnsupportedOperationException for creating SSL(Server)SocketFactory with DTLS SSLContext, because it does not actually support DTLS SSLSocket. >>>>> >>>>> In Solution section, "Throwing a UnsupportedOperationException when getting a socket from the SSLServerSocketFactory or SSLSocketFactory for DTLS." I guess you meant, throwing a UOE when calling SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>>> I need a review of a CSR for SSLSocket should throw an exception when configuring DTLS. We are targeting this for 12 right now. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>>> >>>>>> thanks >>>>>> >>>>>> Tony >>>>>> >>>> > From Alan.Bateman at oracle.com Wed Aug 8 18:29:46 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Aug 2018 19:29:46 +0100 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <9bb8b30850aa48e493a15d48cfd79efa@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> Message-ID: <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com> On 07/08/2018 16:00, Baesken, Matthias wrote: > Ping .... ? , any reviews / comments ? Did we get to a conclusion on whether to have central infrastructure to read/parse the security property? As I recall, this one was originally proposed before the generalization of the networking solution. There are details related to trimming that would be better not to duplicate if possible. Also, I think one of my comments on the original patch is that we should get the style and line lengths a bit more consistent with the existing code (the patch added excessively long lines for example). -Alan. From anthony.scarpino at oracle.com Wed Aug 8 18:27:28 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 8 Aug 2018 11:27:28 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> Message-ID: <8269a21f-5a4a-7a40-b80e-faa5e514b478@oracle.com> On 08/08/2018 07:46 AM, Sean Mullan wrote: > On 8/7/18 8:05 PM, Xuelei Fan wrote: >> Hi Tony, >> >> The Specification section looks more like the implementation details. >> We may change the implementation details again in the future.? It may >> be more suitable to move it to the Solution section, or just remove it. > > I agree, I would omit the diffs and put N/A for the Specification section. > >> In the Specification section, I may just say something like, "No APIs >> changes.? The SunJSSE provider is updated to throw >> UnsupportedOperationException if? SSLContext.SSLServerSocketFactory() >> or SSLContext.SSLSocketFactory() get called for DTLS algorithms >> SSLContext". > > I think the CSR should also say that the SunJSSE implementation of the > engineGetSocketFactory and engineGetServerSocketFactory methods of > SSLContextSpi have been changed to throw UnsupportedOperationException. > That is the specific API behavior change. > > A few other comments on the CSR: > > "SSLContext.getSSLSocketFactory() and > SSLContext.getSSLServerSocketFactory()" > > Typo, there is no "SSL" in the method names. > > The Compatibility Risk field has several typos ("there" -> "their", "how > -> now", ...) and is a bit hard to understand. Wasn't TLS being used > before instead of DTLS in certain scenarios? Because the API silently > passed in certain cases, and now we will be throwing an Exception, maybe > it might be better to say the risk is low. I fixed the typos and redid the compatibility part that hopefully is more to the point. > > In the Summary section, it says "..., but it is not documented." I > suggest opening a docs bug to improve the DTLS documentation so that it > is more clear this scenario is not supported. > > I think the Interface Kind should be Java API since we are changing the > behavior of an implementation of a standard API. I asked Joe Darcy this > question yesterday, and he agreed. I thought about API, but since it was a behavior change, API didn't sound completely correct. But that's fine if that's what he wants. > > --Sean > >> >> Thanks, >> Xuelei >> >> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>> Hi Xuelei, >>> >>> I have updated the csr and I believe I have addressed your comments. >>> >>> thanks >>> >>> Tony >>> >>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>> Hi Tony, >>>> >>>> Would you mind make it clear that this impact the JDK JSSE provider >>>> only?? Third party's provider may be able to support DTLS with >>>> SSLSocket. >>>> >>>> I think there may be no specification change.? The >>>> SSLContext.getServerSocketFactory() and >>>> SSLContext.getSocketFactory() defines the spec if the algorithm is >>>> not supported by the underlying provider, >>>> "UnsupportedOperationException - if the underlying provider does not >>>> implement the operation.".? I may prefer to make it clear that this >>>> is just a behavior change of the JDK JSSE provider (SunJSSE).? The >>>> SunJSSE provider now throws UnsupportedOperationException for >>>> creating SSL(Server)SocketFactory with DTLS SSLContext, because it >>>> does not actually support DTLS SSLSocket. >>>> >>>> In Solution section, "Throwing a UnsupportedOperationException when >>>> getting a socket from the SSLServerSocketFactory or SSLSocketFactory >>>> for DTLS."?? I guess you meant, throwing a UOE when calling >>>> SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>> I need a review of a CSR for SSLSocket should throw an exception >>>>> when configuring DTLS.? We are targeting this for 12 right now. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>> >>>>> thanks >>>>> >>>>> Tony >>>>> >>> From sean.mullan at oracle.com Wed Aug 8 20:28:11 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Aug 2018 16:28:11 -0400 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> Message-ID: On 8/8/18 1:58 PM, Anthony Scarpino wrote: > I don't see where your example of getDefault() is any different than the > current code path.? A user has to define a SSLContext when using > getDefault() which as far as I can tell goes through the code path of > SSLContext.get[Server]SocketFactory() SSL{Server}SocketFactory.getDefault() says: "Otherwise, this method returns SSLContext.getDefault().get{Server}SocketFactory(). If that call fails, an inoperative factory is returned." So it doesn't look like we have to do anything special for this case, but as part of this fix, we should check/test that an inoperative factory is returned if a DTLS context is the default. --Sean > > Tony > > On 08/08/2018 08:52 AM, Chris Hegarty wrote: >> +1 to everything Sean said, and just to add ... >> >> This change will prevent an SSLContext from giving out socket >> factories when it has been configured with DTLS. What about >> SSL[Server]SocketFactory::getDefault when the default SSL >> context is DTLS? I don?t see that getDefault can throw an UOE, >> should it???? Or should / could this be resolved at the socket >> factory level, when trying to create new sockets rather than at >> the factory retrieval time? >> >> -Chris. >> >>> On 8 Aug 2018, at 15:46, Sean Mullan wrote: >>> >>> On 8/7/18 8:05 PM, Xuelei Fan wrote: >>>> Hi Tony, >>>> The Specification section looks more like the implementation >>>> details. We may change the implementation details again in the >>>> future.? It may be more suitable to move it to the Solution section, >>>> or just remove it. >>> >>> I agree, I would omit the diffs and put N/A for the Specification >>> section. >>> >>>> In the Specification section, I may just say something like, "No >>>> APIs changes.? The SunJSSE provider is updated to throw >>>> UnsupportedOperationException if >>>> SSLContext.SSLServerSocketFactory() or SSLContext.SSLSocketFactory() >>>> get called for DTLS algorithms SSLContext". >>> >>> I think the CSR should also say that the SunJSSE implementation of >>> the engineGetSocketFactory and engineGetServerSocketFactory methods >>> of SSLContextSpi have been changed to throw >>> UnsupportedOperationException. That is the specific API behavior change. >>> >>> A few other comments on the CSR: >>> >>> "SSLContext.getSSLSocketFactory() and >>> SSLContext.getSSLServerSocketFactory()" >>> >>> Typo, there is no "SSL" in the method names. >>> >>> The Compatibility Risk field has several typos ("there" -> "their", >>> "how -> now", ...) and is a bit hard to understand. Wasn't TLS being >>> used before instead of DTLS in certain scenarios? Because the API >>> silently passed in certain cases, and now we will be throwing an >>> Exception, maybe it might be better to say the risk is low. >>> >>> In the Summary section, it says "..., but it is not documented." I >>> suggest opening a docs bug to improve the DTLS documentation so that >>> it is more clear this scenario is not supported. >>> >>> I think the Interface Kind should be Java API since we are changing >>> the behavior of an implementation of a standard API. I asked Joe >>> Darcy this question yesterday, and he agreed. >>> >>> --Sean >>> >>>> Thanks, >>>> Xuelei >>>> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>>>> Hi Xuelei, >>>>> >>>>> I have updated the csr and I believe I have addressed your comments. >>>>> >>>>> thanks >>>>> >>>>> Tony >>>>> >>>>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>>>> Hi Tony, >>>>>> >>>>>> Would you mind make it clear that this impact the JDK JSSE >>>>>> provider only?? Third party's provider may be able to support DTLS >>>>>> with SSLSocket. >>>>>> >>>>>> I think there may be no specification change.? The >>>>>> SSLContext.getServerSocketFactory() and >>>>>> SSLContext.getSocketFactory() defines the spec if the algorithm is >>>>>> not supported by the underlying provider, >>>>>> "UnsupportedOperationException - if the underlying provider does >>>>>> not implement the operation.".? I may prefer to make it clear that >>>>>> this is just a behavior change of the JDK JSSE provider >>>>>> (SunJSSE).? The SunJSSE provider now throws >>>>>> UnsupportedOperationException for creating >>>>>> SSL(Server)SocketFactory with DTLS SSLContext, because it does not >>>>>> actually support DTLS SSLSocket. >>>>>> >>>>>> In Solution section, "Throwing a UnsupportedOperationException >>>>>> when getting a socket from the SSLServerSocketFactory or >>>>>> SSLSocketFactory for DTLS."?? I guess you meant, throwing a UOE >>>>>> when calling SSLContext.getServerSocketFactory() and >>>>>> SSLContext.getSocketFactory()? >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>>>> I need a review of a CSR for SSLSocket should throw an exception >>>>>>> when configuring DTLS.? We are targeting this for 12 right now. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Tony >>>>>>> >>>>> >> > From oddbjornkvalsund at gmail.com Wed Aug 8 21:19:05 2018 From: oddbjornkvalsund at gmail.com (=?UTF-8?Q?Oddbj=C3=B8rn_Kvalsund?=) Date: Wed, 8 Aug 2018 23:19:05 +0200 Subject: JDK-6782021 In-Reply-To: References: <972ae00c-f669-7816-fbb0-44f8f48c9f54@oracle.com> Message-ID: Thanks for the input, Bernd and Sean! I'm afraid submitting a patch for this directly is a bit beyond my ability, but I'll happily discuss the design of such a patch. Nelson D'Costa proposed a couple of possible solutions in JDK-6782021: > Either define a new store type like Windows-LOCALCOMPUTER, > or also list the computer local certificates when using the Windows-MY store type. My rudimentary understanding of the Windows certificate store architecture after reading [1] is that Windows comes with a predefined set of "collection stores" that can be opened with the WinCrypt function CertOpenStore() using identifier tuples such as CERT_SYSTEM_STORE_CURRENT_USER+MY, CERT_SYSTEM_STORE_LOCAL_MACHINE+CA etc. and that these collection stores aggregate a set of "physical stores", typically in the Windows registry. This model is thoroughly documented in [1] (although complex), but mapping this identifier scheme to something that can be used by JCA and KeyStore.getInstance() is slightly tricky because of at least two concerns: 1) The SunMSCAPI JCA provider is widely used and although its "Windows-MY" certificate store identifier scheme is flawed (it should have been something like "Windows-CurrentUser-MY") we can't easily change it without breaking things. 2) Opening any certificate stores involving the CERT_SYSTEM_STORE_LOCAL_MACHINE identifier (and most likely other identifiers) requires administrator privileges or specifically opening the store as read-only by passing CERT_STORE_READONLY_FLAG to CertOpenStore [2]. To offer the full flexibility of CertOpenStore() through KeyStore.getInstance() seems like a grand undertaking involving an almost infinite number of magic string identifiers, so my suggestion is as follows: 1) Introduce the new identifiers Windows-CurrentUser-MY, Windows-CurrentUser-ROOT, Windows-LocalMachine-MY and Windows-LocalMachine-ROOT. These seem to be the most requested, but the identifier scheme allows for more esoteric additions such as Windows-Services--MY down the line. 2) Make Windows-MY and Windows-ROOT be aliases for Windows-CurrentUser-MY and Windows-CurrentUser-ROOT to maintain backward compatibility. 3) Attempt to open Windows-LocalMachine-MY and Windows-LocalMachine-ROOT in the default read-write mode, but fallback to read-only if read-write mode fails. This will transparently enable write operations for privileged users, while unprivileged users will get an exception when attempting to write to the store. References: [1] https://docs.microsoft.com/en-us/windows/desktop/seccrypto/system-store-locations [2] https://docs.microsoft.com/en-us/windows/desktop/api/wincrypt/nf-wincrypt-certopenstore Best regards, Oddbj?rn Kvalsund ons. 8. aug. 2018 kl. 14:04 skrev Bernd Eckenfels : > Hello, > > What also should be mentioned is that the old CAPI clients cannot access > CNG Keys. Which is especially a pity since only the new keys benefit from > the cryptographic process isolation (not to mention the confusion that it?s > hard to see which provide hosts them) > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ------------------------------ > *Von:* -980814368m Auftrag von > *Gesendet:* Mittwoch, August 8, 2018 12:35 PM > *An:* Oddbj?rn Kvalsund; security-dev at openjdk.java.net > *Betreff:* Re: JDK-6782021 > > Vinnie is not working on security-libs any more and I think the JBS report > should be marked as unassigned. If any contributors want to suggest a > patch, then I think it can be reviewed on this list! > > regards, > Sean. > > On 07/08/2018 06:36, Oddbj?rn Kvalsund wrote: > > Hi, > > I was just bit by this issue [JDK-6782021] It is not possible to read > local computer certificates with the SunMSCAPI provider > and from StackOverflow > I notice that several other people (see [1][2][3]) have come across the > same problem. Coming up on the 10th anniversary for this issue; any chance > we'll see some love for it? Or at least a comment on the issue on what > timeline to expect and a list of workaround/alternative solutions for the > meantime? > > Background: I'm working with a company having primarily Microsoft > infrastructure and they have a routine where all Windows servers > automatically receive new certificates/keys when the old ones expire. These > certificates are installed in the "Local Computer ? Private" certificate > store. They're quite fond of this system and hesitant to diverge from it, > so my preferred option is to just "get with the program". To temporarily > get around JDK-6782021 I created a small utility [5] that intercepts the > JDKs call to 'CertOpenSystemStore' [4] and presents a read-only virtual > certificate store combining all certificates and keys from the "Current > User" and "Local Computer" certificate stores, but this may have unexpected > implications that I've not yet uncovered, so I'd much prefer not having to > do this. A more thorough solution would be to use the commercial Pheox > JCAPI [6] product, but this is rather expensive and way overkill for what I > (and most others, it seems) need. > > References: > [1] > https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java/51708360 > [2] > https://stackoverflow.com/questions/51205158/access-windows-local-machine-personal-keystore-with-java-sunmscapi > [3] > https://stackoverflow.com/questions/51193143/use-jna-to-get-local-machine-certificate > [4] > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp > [5] https://github.com/oddbjornkvalsund/wcsa > [6] https://pheox.com/products/jcapi/ > > Best regards, > Oddbj?rn Kvalsund > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Aug 8 21:29:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 Aug 2018 14:29:44 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> Message-ID: <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> The "Default" algorithm defined in the SunJSSE provider is for TLS protocols. Xuelei On 8/8/2018 1:28 PM, Sean Mullan wrote: > On 8/8/18 1:58 PM, Anthony Scarpino wrote: >> I don't see where your example of getDefault() is any different than >> the current code path.? A user has to define a SSLContext when using >> getDefault() which as far as I can tell goes through the code path of >> SSLContext.get[Server]SocketFactory() > > SSL{Server}SocketFactory.getDefault() says: "Otherwise, this method > returns SSLContext.getDefault().get{Server}SocketFactory(). If that call > fails, an inoperative factory is returned." > > So it doesn't look like we have to do anything special for this case, > but as part of this fix, we should check/test that an inoperative > factory is returned if a DTLS context is the default. > > --Sean > >> >> Tony >> >> On 08/08/2018 08:52 AM, Chris Hegarty wrote: >>> +1 to everything Sean said, and just to add ... >>> >>> This change will prevent an SSLContext from giving out socket >>> factories when it has been configured with DTLS. What about >>> SSL[Server]SocketFactory::getDefault when the default SSL >>> context is DTLS? I don?t see that getDefault can throw an UOE, >>> should it???? Or should / could this be resolved at the socket >>> factory level, when trying to create new sockets rather than at >>> the factory retrieval time? >>> >>> -Chris. >>> >>>> On 8 Aug 2018, at 15:46, Sean Mullan wrote: >>>> >>>> On 8/7/18 8:05 PM, Xuelei Fan wrote: >>>>> Hi Tony, >>>>> The Specification section looks more like the implementation >>>>> details. We may change the implementation details again in the >>>>> future.? It may be more suitable to move it to the Solution >>>>> section, or just remove it. >>>> >>>> I agree, I would omit the diffs and put N/A for the Specification >>>> section. >>>> >>>>> In the Specification section, I may just say something like, "No >>>>> APIs changes.? The SunJSSE provider is updated to throw >>>>> UnsupportedOperationException if >>>>> SSLContext.SSLServerSocketFactory() or >>>>> SSLContext.SSLSocketFactory() get called for DTLS algorithms >>>>> SSLContext". >>>> >>>> I think the CSR should also say that the SunJSSE implementation of >>>> the engineGetSocketFactory and engineGetServerSocketFactory methods >>>> of SSLContextSpi have been changed to throw >>>> UnsupportedOperationException. That is the specific API behavior >>>> change. >>>> >>>> A few other comments on the CSR: >>>> >>>> "SSLContext.getSSLSocketFactory() and >>>> SSLContext.getSSLServerSocketFactory()" >>>> >>>> Typo, there is no "SSL" in the method names. >>>> >>>> The Compatibility Risk field has several typos ("there" -> "their", >>>> "how -> now", ...) and is a bit hard to understand. Wasn't TLS being >>>> used before instead of DTLS in certain scenarios? Because the API >>>> silently passed in certain cases, and now we will be throwing an >>>> Exception, maybe it might be better to say the risk is low. >>>> >>>> In the Summary section, it says "..., but it is not documented." I >>>> suggest opening a docs bug to improve the DTLS documentation so that >>>> it is more clear this scenario is not supported. >>>> >>>> I think the Interface Kind should be Java API since we are changing >>>> the behavior of an implementation of a standard API. I asked Joe >>>> Darcy this question yesterday, and he agreed. >>>> >>>> --Sean >>>> >>>>> Thanks, >>>>> Xuelei >>>>> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>>>>> Hi Xuelei, >>>>>> >>>>>> I have updated the csr and I believe I have addressed your comments. >>>>>> >>>>>> thanks >>>>>> >>>>>> Tony >>>>>> >>>>>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>>>>> Hi Tony, >>>>>>> >>>>>>> Would you mind make it clear that this impact the JDK JSSE >>>>>>> provider only?? Third party's provider may be able to support >>>>>>> DTLS with SSLSocket. >>>>>>> >>>>>>> I think there may be no specification change.? The >>>>>>> SSLContext.getServerSocketFactory() and >>>>>>> SSLContext.getSocketFactory() defines the spec if the algorithm >>>>>>> is not supported by the underlying provider, >>>>>>> "UnsupportedOperationException - if the underlying provider does >>>>>>> not implement the operation.".? I may prefer to make it clear >>>>>>> that this is just a behavior change of the JDK JSSE provider >>>>>>> (SunJSSE).? The SunJSSE provider now throws >>>>>>> UnsupportedOperationException for creating >>>>>>> SSL(Server)SocketFactory with DTLS SSLContext, because it does >>>>>>> not actually support DTLS SSLSocket. >>>>>>> >>>>>>> In Solution section, "Throwing a UnsupportedOperationException >>>>>>> when getting a socket from the SSLServerSocketFactory or >>>>>>> SSLSocketFactory for DTLS."?? I guess you meant, throwing a UOE >>>>>>> when calling SSLContext.getServerSocketFactory() and >>>>>>> SSLContext.getSocketFactory()? >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>>>>> I need a review of a CSR for SSLSocket should throw an exception >>>>>>>> when configuring DTLS.? We are targeting this for 12 right now. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>>>>> >>>>>>>> thanks >>>>>>>> >>>>>>>> Tony >>>>>>>> >>>>>> >>> >> From matthias.baesken at sap.com Thu Aug 9 07:07:45 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 Aug 2018 07:07:45 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com> Message-ID: > Did we get to a conclusion on whether to have central infrastructure to > read/parse the security property? As I recall, this one was originally > proposed before the generalization of the networking solution. There are > details related to trimming that would be better not to duplicate if > possible. Hi Alan / Chris , I am aware of https://bugs.openjdk.java.net/browse/JDK-8207846 where jdk.net.includeInExceptions has been generalized to be used for other use cases than exceptions in the networking area . This has been pushed in the meantine. Could you point me to the other discussion, is there already a webrev posted for this ? > > Also, I think one of my comments on the original patch is that we should > get the style and line lengths a bit more consistent with the existing > code (the patch added excessively long lines for example). > Sure I'll look into it ! Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Mittwoch, 8. August 2018 20:30 > To: Baesken, Matthias ; Chris Hegarty > > Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz > ; Langer, Christoph > ; OpenJDK Dev list dev at openjdk.java.net> > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > On 07/08/2018 16:00, Baesken, Matthias wrote: > > Ping .... ? , any reviews / comments ? > Did we get to a conclusion on whether to have central infrastructure to > read/parse the security property? As I recall, this one was originally > proposed before the generalization of the networking solution. There are > details related to trimming that would be better not to duplicate if > possible. > > Also, I think one of my comments on the original patch is that we should > get the style and line lengths a bit more consistent with the existing > code (the patch added excessively long lines for example). > > -Alan. From chris.hegarty at oracle.com Thu Aug 9 08:50:01 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 9 Aug 2018 09:50:01 +0100 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> Message-ID: Ok, thanks. Looks like the ?Default? case is not-an-issue. -Chris. > On 8 Aug 2018, at 22:29, Xuelei Fan wrote: > > The "Default" algorithm defined in the SunJSSE provider is for TLS protocols. > > Xuelei > > On 8/8/2018 1:28 PM, Sean Mullan wrote: >> On 8/8/18 1:58 PM, Anthony Scarpino wrote: >>> I don't see where your example of getDefault() is any different than the current code path. A user has to define a SSLContext when using getDefault() which as far as I can tell goes through the code path of SSLContext.get[Server]SocketFactory() >> SSL{Server}SocketFactory.getDefault() says: "Otherwise, this method returns SSLContext.getDefault().get{Server}SocketFactory(). If that call fails, an inoperative factory is returned." >> So it doesn't look like we have to do anything special for this case, but as part of this fix, we should check/test that an inoperative factory is returned if a DTLS context is the default. >> --Sean >>> >>> Tony >>> >>> On 08/08/2018 08:52 AM, Chris Hegarty wrote: >>>> +1 to everything Sean said, and just to add ... >>>> >>>> This change will prevent an SSLContext from giving out socket >>>> factories when it has been configured with DTLS. What about >>>> SSL[Server]SocketFactory::getDefault when the default SSL >>>> context is DTLS? I don?t see that getDefault can throw an UOE, >>>> should it? Or should / could this be resolved at the socket >>>> factory level, when trying to create new sockets rather than at >>>> the factory retrieval time? >>>> >>>> -Chris. >>>> >>>>> On 8 Aug 2018, at 15:46, Sean Mullan wrote: >>>>> >>>>> On 8/7/18 8:05 PM, Xuelei Fan wrote: >>>>>> Hi Tony, >>>>>> The Specification section looks more like the implementation details. We may change the implementation details again in the future. It may be more suitable to move it to the Solution section, or just remove it. >>>>> >>>>> I agree, I would omit the diffs and put N/A for the Specification section. >>>>> >>>>>> In the Specification section, I may just say something like, "No APIs changes. The SunJSSE provider is updated to throw UnsupportedOperationException if SSLContext.SSLServerSocketFactory() or SSLContext.SSLSocketFactory() get called for DTLS algorithms SSLContext". >>>>> >>>>> I think the CSR should also say that the SunJSSE implementation of the engineGetSocketFactory and engineGetServerSocketFactory methods of SSLContextSpi have been changed to throw UnsupportedOperationException. That is the specific API behavior change. >>>>> >>>>> A few other comments on the CSR: >>>>> >>>>> "SSLContext.getSSLSocketFactory() and SSLContext.getSSLServerSocketFactory()" >>>>> >>>>> Typo, there is no "SSL" in the method names. >>>>> >>>>> The Compatibility Risk field has several typos ("there" -> "their", "how -> now", ...) and is a bit hard to understand. Wasn't TLS being used before instead of DTLS in certain scenarios? Because the API silently passed in certain cases, and now we will be throwing an Exception, maybe it might be better to say the risk is low. >>>>> >>>>> In the Summary section, it says "..., but it is not documented." I suggest opening a docs bug to improve the DTLS documentation so that it is more clear this scenario is not supported. >>>>> >>>>> I think the Interface Kind should be Java API since we are changing the behavior of an implementation of a standard API. I asked Joe Darcy this question yesterday, and he agreed. >>>>> >>>>> --Sean >>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>>>>>> Hi Xuelei, >>>>>>> >>>>>>> I have updated the csr and I believe I have addressed your comments. >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Tony >>>>>>> >>>>>>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>>>>>> Hi Tony, >>>>>>>> >>>>>>>> Would you mind make it clear that this impact the JDK JSSE provider only? Third party's provider may be able to support DTLS with SSLSocket. >>>>>>>> >>>>>>>> I think there may be no specification change. The SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory() defines the spec if the algorithm is not supported by the underlying provider, "UnsupportedOperationException - if the underlying provider does not implement the operation.". I may prefer to make it clear that this is just a behavior change of the JDK JSSE provider (SunJSSE). The SunJSSE provider now throws UnsupportedOperationException for creating SSL(Server)SocketFactory with DTLS SSLContext, because it does not actually support DTLS SSLSocket. >>>>>>>> >>>>>>>> In Solution section, "Throwing a UnsupportedOperationException when getting a socket from the SSLServerSocketFactory or SSLSocketFactory for DTLS." I guess you meant, throwing a UOE when calling SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>>>>>> I need a review of a CSR for SSLSocket should throw an exception when configuring DTLS. We are targeting this for 12 right now. >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> >>>>>>>>> Tony >>>>>>>>> >>>>>>> >>>> >>> From chris.hegarty at oracle.com Thu Aug 9 09:02:28 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 9 Aug 2018 10:02:28 +0100 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com> Message-ID: Matthias, > On 9 Aug 2018, at 08:07, Baesken, Matthias wrote: > >> Did we get to a conclusion on whether to have central infrastructure to >> read/parse the security property? As I recall, this one was originally >> proposed before the generalization of the networking solution. There are >> details related to trimming that would be better not to duplicate if >> possible. > > Hi Alan / Chris , > > I am aware of > > https://bugs.openjdk.java.net/browse/JDK-8207846 > > where jdk.net.includeInExceptions has been generalized to be used for other use cases than exceptions in the networking area . > This has been pushed in the meantine. > > Could you point me to the other discussion, is there already a webrev posted for this ? Given that 8207846 was being targeted to JDK 11, during RDP 1, it was decided to keep the changes as minimal as possible. The supporting implementation, that reads and parses the property, remains in src/java.base/share/classes/sun/net/util/SocketExceptions.java. Alan referred to this in one of the review comments for 8207846 [1]. If this mechanism is to be used outside of the networking area, and I think it can, then the implementation in SocketExceptions should probably be moved to some other more appropriate internal package. >> >> Also, I think one of my comments on the original patch is that we should >> get the style and line lengths a bit more consistent with the existing >> code (the patch added excessively long lines for example). >> > > Sure I'll look into it ! -Chris. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054501.html > Best regards, Matthias > > >> -----Original Message----- >> From: Alan Bateman >> Sent: Mittwoch, 8. August 2018 20:30 >> To: Baesken, Matthias ; Chris Hegarty >> >> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz >> ; Langer, Christoph >> ; OpenJDK Dev list > dev at openjdk.java.net> >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest >> parsing of jar archives >> >> On 07/08/2018 16:00, Baesken, Matthias wrote: >>> Ping .... ? , any reviews / comments ? >> Did we get to a conclusion on whether to have central infrastructure to >> read/parse the security property? As I recall, this one was originally >> proposed before the generalization of the networking solution. There are >> details related to trimming that would be better not to duplicate if >> possible. >> >> Also, I think one of my comments on the original patch is that we should >> get the style and line lengths a bit more consistent with the existing >> code (the patch added excessively long lines for example). >> >> -Alan. From weijun.wang at oracle.com Thu Aug 9 09:55:22 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 Aug 2018 17:55:22 +0800 Subject: RFR 8076190: Support passwordless access to PKCS12 keystores In-Reply-To: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> Message-ID: <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.02 The only change is in keytool/Main and the test. keytool will not prompt for store password if it detects a password-less keystore. This is 3) below. Thanks Max > On Jul 24, 2018, at 6:49 PM, Weijun Wang wrote: > > Please review the code change and CSR at > > webrev: http://cr.openjdk.java.net/~weijun/8076190/webrev.01/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8202590 > > The bug is at > > https://bugs.openjdk.java.net/browse/JDK-8076190 > > This is the 1st part of the process to make cacerts using pkcs12: > > 1. Support passwordless access to PKCS12 keystores > 2. Update default algorithms and params when creating a PKCS12 keystore > 3. Update keytool to support passwordless pkcs12 keystores > 4. Migrate cacerts to pkcs12 > > Thanks > Max > From sean.coffey at oracle.com Thu Aug 9 10:37:37 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 9 Aug 2018 11:37:37 +0100 Subject: JDK-8209129 :Further improvements to cipher buffer management Message-ID: I've been looking further at how private/temporary buffers are used in cipher/keystore management and identified some more areas that could benefit with a more aggressive nulling out of contents. I've been testing through use of stepping through debugging sessions while setting/getting keys and capturing process memory via tooling like gcore. JBS report : https://bugs.openjdk.java.net/browse/JDK-8209129 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8209129.v1/webrev/index.html TCK and regression tests are green. regards, Sean. From sean.coffey at oracle.com Thu Aug 9 10:42:17 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 9 Aug 2018 11:42:17 +0100 Subject: RFR: JDK-8209129 :Further improvements to cipher buffer management In-Reply-To: References: Message-ID: <1bd9e050-409a-3b6d-26e8-62b909d6a306@oracle.com> Adding RFR to title.. On 09/08/2018 11:37, Se?n Coffey wrote: > I've been looking further at how private/temporary buffers are used in > cipher/keystore management and identified some more areas that could > benefit with a more aggressive nulling out of contents. > > I've been testing through use of stepping through debugging sessions > while setting/getting keys and capturing process memory via tooling > like gcore. > > JBS report : https://bugs.openjdk.java.net/browse/JDK-8209129 > > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8209129.v1/webrev/index.html > > TCK and regression tests are green. > > regards, > Sean. > From sean.mullan at oracle.com Thu Aug 9 11:25:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 Aug 2018 07:25:10 -0400 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> Message-ID: <650ee21d-ec31-0ee0-ab2a-cf4fed2a21d4@oracle.com> On 8/8/18 5:29 PM, Xuelei Fan wrote: > The "Default" algorithm defined in the SunJSSE provider is for TLS > protocols. What if I set DTLS to be the default, though? Ex: SSLContext.setDefault(SSLContext.getInstance("DTLS")); --Sean > > Xuelei > > On 8/8/2018 1:28 PM, Sean Mullan wrote: >> On 8/8/18 1:58 PM, Anthony Scarpino wrote: >>> I don't see where your example of getDefault() is any different than >>> the current code path.? A user has to define a SSLContext when using >>> getDefault() which as far as I can tell goes through the code path of >>> SSLContext.get[Server]SocketFactory() >> >> SSL{Server}SocketFactory.getDefault() says: "Otherwise, this method >> returns SSLContext.getDefault().get{Server}SocketFactory(). If that >> call fails, an inoperative factory is returned." >> >> So it doesn't look like we have to do anything special for this case, >> but as part of this fix, we should check/test that an inoperative >> factory is returned if a DTLS context is the default. >> >> --Sean >> >>> >>> Tony >>> >>> On 08/08/2018 08:52 AM, Chris Hegarty wrote: >>>> +1 to everything Sean said, and just to add ... >>>> >>>> This change will prevent an SSLContext from giving out socket >>>> factories when it has been configured with DTLS. What about >>>> SSL[Server]SocketFactory::getDefault when the default SSL >>>> context is DTLS? I don?t see that getDefault can throw an UOE, >>>> should it???? Or should / could this be resolved at the socket >>>> factory level, when trying to create new sockets rather than at >>>> the factory retrieval time? >>>> >>>> -Chris. >>>> >>>>> On 8 Aug 2018, at 15:46, Sean Mullan wrote: >>>>> >>>>> On 8/7/18 8:05 PM, Xuelei Fan wrote: >>>>>> Hi Tony, >>>>>> The Specification section looks more like the implementation >>>>>> details. We may change the implementation details again in the >>>>>> future.? It may be more suitable to move it to the Solution >>>>>> section, or just remove it. >>>>> >>>>> I agree, I would omit the diffs and put N/A for the Specification >>>>> section. >>>>> >>>>>> In the Specification section, I may just say something like, "No >>>>>> APIs changes.? The SunJSSE provider is updated to throw >>>>>> UnsupportedOperationException if >>>>>> SSLContext.SSLServerSocketFactory() or >>>>>> SSLContext.SSLSocketFactory() get called for DTLS algorithms >>>>>> SSLContext". >>>>> >>>>> I think the CSR should also say that the SunJSSE implementation of >>>>> the engineGetSocketFactory and engineGetServerSocketFactory methods >>>>> of SSLContextSpi have been changed to throw >>>>> UnsupportedOperationException. That is the specific API behavior >>>>> change. >>>>> >>>>> A few other comments on the CSR: >>>>> >>>>> "SSLContext.getSSLSocketFactory() and >>>>> SSLContext.getSSLServerSocketFactory()" >>>>> >>>>> Typo, there is no "SSL" in the method names. >>>>> >>>>> The Compatibility Risk field has several typos ("there" -> "their", >>>>> "how -> now", ...) and is a bit hard to understand. Wasn't TLS >>>>> being used before instead of DTLS in certain scenarios? Because the >>>>> API silently passed in certain cases, and now we will be throwing >>>>> an Exception, maybe it might be better to say the risk is low. >>>>> >>>>> In the Summary section, it says "..., but it is not documented." I >>>>> suggest opening a docs bug to improve the DTLS documentation so >>>>> that it is more clear this scenario is not supported. >>>>> >>>>> I think the Interface Kind should be Java API since we are changing >>>>> the behavior of an implementation of a standard API. I asked Joe >>>>> Darcy this question yesterday, and he agreed. >>>>> >>>>> --Sean >>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>>>>>> Hi Xuelei, >>>>>>> >>>>>>> I have updated the csr and I believe I have addressed your comments. >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Tony >>>>>>> >>>>>>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>>>>>> Hi Tony, >>>>>>>> >>>>>>>> Would you mind make it clear that this impact the JDK JSSE >>>>>>>> provider only?? Third party's provider may be able to support >>>>>>>> DTLS with SSLSocket. >>>>>>>> >>>>>>>> I think there may be no specification change.? The >>>>>>>> SSLContext.getServerSocketFactory() and >>>>>>>> SSLContext.getSocketFactory() defines the spec if the algorithm >>>>>>>> is not supported by the underlying provider, >>>>>>>> "UnsupportedOperationException - if the underlying provider does >>>>>>>> not implement the operation.".? I may prefer to make it clear >>>>>>>> that this is just a behavior change of the JDK JSSE provider >>>>>>>> (SunJSSE).? The SunJSSE provider now throws >>>>>>>> UnsupportedOperationException for creating >>>>>>>> SSL(Server)SocketFactory with DTLS SSLContext, because it does >>>>>>>> not actually support DTLS SSLSocket. >>>>>>>> >>>>>>>> In Solution section, "Throwing a UnsupportedOperationException >>>>>>>> when getting a socket from the SSLServerSocketFactory or >>>>>>>> SSLSocketFactory for DTLS."?? I guess you meant, throwing a UOE >>>>>>>> when calling SSLContext.getServerSocketFactory() and >>>>>>>> SSLContext.getSocketFactory()? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>>>>>> I need a review of a CSR for SSLSocket should throw an >>>>>>>>> exception when configuring DTLS.? We are targeting this for 12 >>>>>>>>> right now. >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> >>>>>>>>> Tony >>>>>>>>> >>>>>>> >>>> >>> From xuelei.fan at oracle.com Thu Aug 9 13:49:21 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 9 Aug 2018 06:49:21 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <650ee21d-ec31-0ee0-ab2a-cf4fed2a21d4@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> <650ee21d-ec31-0ee0-ab2a-cf4fed2a21d4@oracle.com> Message-ID: <17372eb4-9006-2150-547d-87dcbbb90a2c@oracle.com> On 8/9/2018 4:25 AM, Sean Mullan wrote: > On 8/8/18 5:29 PM, Xuelei Fan wrote: >> The "Default" algorithm defined in the SunJSSE provider is for TLS >> protocols. > > What if I set DTLS to be the default, though? Ex: > > ??? SSLContext.setDefault(SSLContext.getInstance("DTLS")); > Good point! Maybe, we also need to update the SSLSocketFactory/SSLServerSocketFactory.getDefault() to return inoperative factory. Xuelei > --Sean > >> >> Xuelei >> >> On 8/8/2018 1:28 PM, Sean Mullan wrote: >>> On 8/8/18 1:58 PM, Anthony Scarpino wrote: >>>> I don't see where your example of getDefault() is any different than >>>> the current code path.? A user has to define a SSLContext when using >>>> getDefault() which as far as I can tell goes through the code path >>>> of SSLContext.get[Server]SocketFactory() >>> >>> SSL{Server}SocketFactory.getDefault() says: "Otherwise, this method >>> returns SSLContext.getDefault().get{Server}SocketFactory(). If that >>> call fails, an inoperative factory is returned." >>> >>> So it doesn't look like we have to do anything special for this case, >>> but as part of this fix, we should check/test that an inoperative >>> factory is returned if a DTLS context is the default. >>> >>> --Sean >>> >>>> >>>> Tony >>>> >>>> On 08/08/2018 08:52 AM, Chris Hegarty wrote: >>>>> +1 to everything Sean said, and just to add ... >>>>> >>>>> This change will prevent an SSLContext from giving out socket >>>>> factories when it has been configured with DTLS. What about >>>>> SSL[Server]SocketFactory::getDefault when the default SSL >>>>> context is DTLS? I don?t see that getDefault can throw an UOE, >>>>> should it???? Or should / could this be resolved at the socket >>>>> factory level, when trying to create new sockets rather than at >>>>> the factory retrieval time? >>>>> >>>>> -Chris. >>>>> >>>>>> On 8 Aug 2018, at 15:46, Sean Mullan wrote: >>>>>> >>>>>> On 8/7/18 8:05 PM, Xuelei Fan wrote: >>>>>>> Hi Tony, >>>>>>> The Specification section looks more like the implementation >>>>>>> details. We may change the implementation details again in the >>>>>>> future.? It may be more suitable to move it to the Solution >>>>>>> section, or just remove it. >>>>>> >>>>>> I agree, I would omit the diffs and put N/A for the Specification >>>>>> section. >>>>>> >>>>>>> In the Specification section, I may just say something like, "No >>>>>>> APIs changes.? The SunJSSE provider is updated to throw >>>>>>> UnsupportedOperationException if >>>>>>> SSLContext.SSLServerSocketFactory() or >>>>>>> SSLContext.SSLSocketFactory() get called for DTLS algorithms >>>>>>> SSLContext". >>>>>> >>>>>> I think the CSR should also say that the SunJSSE implementation of >>>>>> the engineGetSocketFactory and engineGetServerSocketFactory >>>>>> methods of SSLContextSpi have been changed to throw >>>>>> UnsupportedOperationException. That is the specific API behavior >>>>>> change. >>>>>> >>>>>> A few other comments on the CSR: >>>>>> >>>>>> "SSLContext.getSSLSocketFactory() and >>>>>> SSLContext.getSSLServerSocketFactory()" >>>>>> >>>>>> Typo, there is no "SSL" in the method names. >>>>>> >>>>>> The Compatibility Risk field has several typos ("there" -> >>>>>> "their", "how -> now", ...) and is a bit hard to understand. >>>>>> Wasn't TLS being used before instead of DTLS in certain scenarios? >>>>>> Because the API silently passed in certain cases, and now we will >>>>>> be throwing an Exception, maybe it might be better to say the risk >>>>>> is low. >>>>>> >>>>>> In the Summary section, it says "..., but it is not documented." I >>>>>> suggest opening a docs bug to improve the DTLS documentation so >>>>>> that it is more clear this scenario is not supported. >>>>>> >>>>>> I think the Interface Kind should be Java API since we are >>>>>> changing the behavior of an implementation of a standard API. I >>>>>> asked Joe Darcy this question yesterday, and he agreed. >>>>>> >>>>>> --Sean >>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>>>>>>> Hi Xuelei, >>>>>>>> >>>>>>>> I have updated the csr and I believe I have addressed your >>>>>>>> comments. >>>>>>>> >>>>>>>> thanks >>>>>>>> >>>>>>>> Tony >>>>>>>> >>>>>>>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>>>>>>> Hi Tony, >>>>>>>>> >>>>>>>>> Would you mind make it clear that this impact the JDK JSSE >>>>>>>>> provider only?? Third party's provider may be able to support >>>>>>>>> DTLS with SSLSocket. >>>>>>>>> >>>>>>>>> I think there may be no specification change.? The >>>>>>>>> SSLContext.getServerSocketFactory() and >>>>>>>>> SSLContext.getSocketFactory() defines the spec if the algorithm >>>>>>>>> is not supported by the underlying provider, >>>>>>>>> "UnsupportedOperationException - if the underlying provider >>>>>>>>> does not implement the operation.".? I may prefer to make it >>>>>>>>> clear that this is just a behavior change of the JDK JSSE >>>>>>>>> provider (SunJSSE).? The SunJSSE provider now throws >>>>>>>>> UnsupportedOperationException for creating >>>>>>>>> SSL(Server)SocketFactory with DTLS SSLContext, because it does >>>>>>>>> not actually support DTLS SSLSocket. >>>>>>>>> >>>>>>>>> In Solution section, "Throwing a UnsupportedOperationException >>>>>>>>> when getting a socket from the SSLServerSocketFactory or >>>>>>>>> SSLSocketFactory for DTLS."?? I guess you meant, throwing a UOE >>>>>>>>> when calling SSLContext.getServerSocketFactory() and >>>>>>>>> SSLContext.getSocketFactory()? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>>>>>>> I need a review of a CSR for SSLSocket should throw an >>>>>>>>>> exception when configuring DTLS.? We are targeting this for 12 >>>>>>>>>> right now. >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> >>>>>>>>>> Tony >>>>>>>>>> >>>>>>>> >>>>> >>>> From norman.maurer at googlemail.com Thu Aug 9 13:50:46 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 9 Aug 2018 15:50:46 +0200 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: <5DE48751-A893-4E0A-8F26-DAC64493101F@googlemail.com> References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> <41082F88-4626-4C64-A922-C697C38C4902@googlemail.com> <5DE48751-A893-4E0A-8F26-DAC64493101F@googlemail.com> Message-ID: <5DC8A9BF-F0DB-47D4-B198-F366643E7B15@googlemail.com> I there any idea when the patch will be merged and a release will be cut so we can enable testing with JDK11 again for netty ? > On 31. Jul 2018, at 07:19, Norman Maurer wrote: > > After digging more this morning I noticed the test code did made some wrong assumptions which just worked out of luck before. After fixing the test everything passes now. > > So +1 from me on the patch :) > > Also sorry for the false-alarm. > > Niorman > > >> On 30. Jul 2018, at 22:23, Xuelei Fan wrote: >> >> Would you mind send me the debug log (-Djavax.net.debug=all) and the exception stacks? The "renegotiation" in TLS 1.3 is different from TLS 1.2 and prior specifications. It would be helpful to me to find the cause of the test failure. >> >> Thanks, >> Xuelei >> >> On 7/30/2018 1:11 PM, Norman Maurer wrote: >>> Sorry but I just noticed we still have a another integration test failing which tests that client SSL renegotiation is failing. This seems to be not the case anymore with java11 + your patch (it was in ea20 tho). >>> https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java >>> Let me know if I need to dig more into it. >>> Bye >>> Norman >>>> On 30. Jul 2018, at 21:54, Norman Maurer > wrote: >>>> >>>> Hey Xuelei, >>>> >>>> I just re-ran our testsuite with your patch and everything pass except two tests. After digging a bit I found that we needed to add explicit calls to `SSLEngine.setUSeClientMode(false)` now in these test where we did not need to do this before. >>>> >>>> The tests in question are: >>>> >>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400 >>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418 >>>> >>>> Here we use SslContext.getDefault().createSSLEngine() and did not set the mode explicitly before. With the following patch to netty all works when using your patch: >>>> >>>> diff --git a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>>> index e982b6a63..40d6e7b59 100644 >>>> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>>> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>>> @@ -398,7 +398,9 @@ public class SslHandlerTest { >>>> @Test >>>> public void testCloseFutureNotified() throws Exception { >>>> - SslHandler handler = new SslHandler(SSLContext.getDefault().createSSLEngine()); >>>> + SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>>> + engine.setUseClientMode(false); >>>> + SslHandler handler = new SslHandler(engine); >>>> EmbeddedChannel ch = new EmbeddedChannel(handler); >>>> ch.close(); >>>> @@ -417,6 +419,7 @@ public class SslHandlerTest { >>>> @Test(timeout = 5000) >>>> public void testEventsFired() throws Exception { >>>> SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>>> + engine.setUseClientMode(false); >>>> final BlockingQueue events = new LinkedBlockingQueue(); >>>> EmbeddedChannel channel = new EmbeddedChannel(new SslHandler(engine), new ChannelInboundHandlerAdapter() { >>>> @Override >>>> >>>> >>>> The exception we see without the patch is: >>>> >>>> java.lang.IllegalStateException: Client/Server mode has not yet been set. >>>> at java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98) >>>> at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731) >>>> at io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644) >>>> at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634) >>>> at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >>>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235) >>>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409) >>>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396) >>>> at io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203) >>>> at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) >>>> at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) >>>> at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >>>> at io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46) >>>> at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487) >>>> at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161) >>>> at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686) >>>> at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510) >>>> at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476) >>>> at io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773) >>>> at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130) >>>> at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124) >>>> at io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208) >>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:167) >>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:148) >>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:135) >>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:100) >>>> at io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404) >>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >>>> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>>> at org.junit.runner.JUnitCore.run(JUnitCore.java:137) >>>> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) >>>> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) >>>> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) >>>> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) >>>> >>>> >>>> So I have no problem to patch our test-case but I wondered if this may break others in other cases and so is a regression. >>>> >>>> Let me know what you think. >>>> Norman >>>> >>>>> On 30. Jul 2018, at 20:06, Norman Maurer > wrote: >>>>> >>>>> Will do and report back as soon as possible. >>>>> >>>>> Thanks >>>>> Norman >>>>> >>>>> >>>>>> On 30. Jul 2018, at 19:57, Xuelei Fan > wrote: >>>>>> >>>>>> Hi Norman, >>>>>> >>>>>> Would you mind look at the code I posted in the following thread: >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>>>>> >>>>>> I appreciate if you could have a test by the end of this week. >>>>>> >>>>>> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 7/25/2018 11:22 PM, Norman Maurer wrote: >>>>>>> Just FYI? I tested this patch via the netty ssl tests and we no longer see the class-cast-exception problems I reported before dso I think this solves the issue. >>>>>>> That said we still encounter a few test-failures for tests that test behaviour of closing outbound of the SSLEngine but I think these are more related to http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html and http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html . >>>>>>> Bye >>>>>>> Norman >>>>>>>> On 25. Jul 2018, at 20:30, Xuelei Fan > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the update for JDK-8208166: >>>>>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>> >>>> > From xuelei.fan at oracle.com Thu Aug 9 13:53:56 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 9 Aug 2018 06:53:56 -0700 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: <5DC8A9BF-F0DB-47D4-B198-F366643E7B15@googlemail.com> References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> <41082F88-4626-4C64-A922-C697C38C4902@googlemail.com> <5DE48751-A893-4E0A-8F26-DAC64493101F@googlemail.com> <5DC8A9BF-F0DB-47D4-B198-F366643E7B15@googlemail.com> Message-ID: I'm waiting for the CSR approval for JDK 11: https://bugs.openjdk.java.net/browse/JDK-8208526 Thanks, Xuelei On 8/9/2018 6:50 AM, Norman Maurer wrote: > I there any idea when the patch will be merged and a release will be cut so we can enable testing with JDK11 again for netty ? > > >> On 31. Jul 2018, at 07:19, Norman Maurer wrote: >> >> After digging more this morning I noticed the test code did made some wrong assumptions which just worked out of luck before. After fixing the test everything passes now. >> >> So +1 from me on the patch :) >> >> Also sorry for the false-alarm. >> >> Niorman >> >> >>> On 30. Jul 2018, at 22:23, Xuelei Fan wrote: >>> >>> Would you mind send me the debug log (-Djavax.net.debug=all) and the exception stacks? The "renegotiation" in TLS 1.3 is different from TLS 1.2 and prior specifications. It would be helpful to me to find the cause of the test failure. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/30/2018 1:11 PM, Norman Maurer wrote: >>>> Sorry but I just noticed we still have a another integration test failing which tests that client SSL renegotiation is failing. This seems to be not the case anymore with java11 + your patch (it was in ea20 tho). >>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java >>>> Let me know if I need to dig more into it. >>>> Bye >>>> Norman >>>>> On 30. Jul 2018, at 21:54, Norman Maurer > wrote: >>>>> >>>>> Hey Xuelei, >>>>> >>>>> I just re-ran our testsuite with your patch and everything pass except two tests. After digging a bit I found that we needed to add explicit calls to `SSLEngine.setUSeClientMode(false)` now in these test where we did not need to do this before. >>>>> >>>>> The tests in question are: >>>>> >>>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400 >>>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418 >>>>> >>>>> Here we use SslContext.getDefault().createSSLEngine() and did not set the mode explicitly before. With the following patch to netty all works when using your patch: >>>>> >>>>> diff --git a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>>>> index e982b6a63..40d6e7b59 100644 >>>>> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>>>> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>>>> @@ -398,7 +398,9 @@ public class SslHandlerTest { >>>>> @Test >>>>> public void testCloseFutureNotified() throws Exception { >>>>> - SslHandler handler = new SslHandler(SSLContext.getDefault().createSSLEngine()); >>>>> + SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>>>> + engine.setUseClientMode(false); >>>>> + SslHandler handler = new SslHandler(engine); >>>>> EmbeddedChannel ch = new EmbeddedChannel(handler); >>>>> ch.close(); >>>>> @@ -417,6 +419,7 @@ public class SslHandlerTest { >>>>> @Test(timeout = 5000) >>>>> public void testEventsFired() throws Exception { >>>>> SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>>>> + engine.setUseClientMode(false); >>>>> final BlockingQueue events = new LinkedBlockingQueue(); >>>>> EmbeddedChannel channel = new EmbeddedChannel(new SslHandler(engine), new ChannelInboundHandlerAdapter() { >>>>> @Override >>>>> >>>>> >>>>> The exception we see without the patch is: >>>>> >>>>> java.lang.IllegalStateException: Client/Server mode has not yet been set. >>>>> at java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98) >>>>> at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731) >>>>> at io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644) >>>>> at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634) >>>>> at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >>>>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235) >>>>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409) >>>>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396) >>>>> at io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203) >>>>> at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) >>>>> at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) >>>>> at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >>>>> at io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46) >>>>> at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487) >>>>> at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161) >>>>> at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686) >>>>> at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510) >>>>> at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476) >>>>> at io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773) >>>>> at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130) >>>>> at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124) >>>>> at io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208) >>>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:167) >>>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:148) >>>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:135) >>>>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:100) >>>>> at io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >>>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >>>>> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >>>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >>>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>>>> at org.junit.runner.JUnitCore.run(JUnitCore.java:137) >>>>> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) >>>>> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) >>>>> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) >>>>> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) >>>>> >>>>> >>>>> So I have no problem to patch our test-case but I wondered if this may break others in other cases and so is a regression. >>>>> >>>>> Let me know what you think. >>>>> Norman >>>>> >>>>>> On 30. Jul 2018, at 20:06, Norman Maurer > wrote: >>>>>> >>>>>> Will do and report back as soon as possible. >>>>>> >>>>>> Thanks >>>>>> Norman >>>>>> >>>>>> >>>>>>> On 30. Jul 2018, at 19:57, Xuelei Fan > wrote: >>>>>>> >>>>>>> Hi Norman, >>>>>>> >>>>>>> Would you mind look at the code I posted in the following thread: >>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>>>>>> >>>>>>> I appreciate if you could have a test by the end of this week. >>>>>>> >>>>>>> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 7/25/2018 11:22 PM, Norman Maurer wrote: >>>>>>>> Just FYI? I tested this patch via the netty ssl tests and we no longer see the class-cast-exception problems I reported before dso I think this solves the issue. >>>>>>>> That said we still encounter a few test-failures for tests that test behaviour of closing outbound of the SSLEngine but I think these are more related to http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html and http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html . >>>>>>>> Bye >>>>>>>> Norman >>>>>>>>> On 25. Jul 2018, at 20:30, Xuelei Fan > wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the update for JDK-8208166: >>>>>>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>> >>>>> >> > From sean.mullan at oracle.com Thu Aug 9 17:17:07 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 Aug 2018 13:17:07 -0400 Subject: Feedback on EdDSA API In-Reply-To: <79ca499f-24be-1059-7d4b-f96fcf36c9bd@oracle.com> References: <79ca499f-24be-1059-7d4b-f96fcf36c9bd@oracle.com> Message-ID: <9f25c1f5-e19d-f165-d3b2-d20bbf41df20@oracle.com> A few (mostly minor) comments on the Solution section. I'll continue my review of the rest of the CSR later. First sentence, "from the existing API ECDSA ..." should that be "API for ECDSA"? // example: use KeyFactory to contruct a public key typo: construct "This API does not standardize "EdEC" algorithm names, so the programmer must use "EdDSA" as the algorithm name to obtain a KeyPairGenerator or KeyFactory." In the example, you use "Ed25519" and not "ECDSA" as the alg name for KeyPairGenerator - which one is correct? --Sean On 6/27/18 12:56 PM, Adam Petcher wrote: > I'm looking for some initial feedback on the proposed JCA API for > EdDSA[2], which I have documented in a draft CSR ticket[1]. Any > comments, concerns, suggestions, etc are appreciated. > > To summarize, the API for EdDSA looks a lot like the API for > X25519/X448. Like X25519/X448, it does not allow the selection of > arbitrary curve parameters. Though the API is flexible enough that it > could be extended to allow more flexibility in the future (or > immediately using provider-specific classes), if necessary. > > The EdDSA API is a little bit more complicated than X25519/X448, because > public keys are points that cannot be expressed with a single > coordinate, and because the signature scheme takes additional > information related to the mode (pure, prehash, context). So we need a > couple more classes to handle these complications, but otherwise the API > is essentially the same as X25519/X448. > > [1] https://bugs.openjdk.java.net/browse/JDK-8190219 > [2] https://tools.ietf.org/html/rfc8032 > From adam.petcher at oracle.com Thu Aug 9 17:30:45 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 9 Aug 2018 13:30:45 -0400 Subject: Feedback on EdDSA API In-Reply-To: <9f25c1f5-e19d-f165-d3b2-d20bbf41df20@oracle.com> References: <79ca499f-24be-1059-7d4b-f96fcf36c9bd@oracle.com> <9f25c1f5-e19d-f165-d3b2-d20bbf41df20@oracle.com> Message-ID: <6a704c25-656b-28b2-1677-1f2e8116e922@oracle.com> On 8/9/2018 1:17 PM, Sean Mullan wrote: > A few (mostly minor) comments on the Solution section. I'll continue > my review of the rest of the CSR later. > > First sentence, "from the existing API ECDSA ..." should that be "API > for ECDSA"? > > // example: use KeyFactory to contruct a public key > > typo: construct Thanks. I fixed these typos. > > "This API does not standardize "EdEC" algorithm names, so the > programmer must use "EdDSA" as the algorithm name to obtain a > KeyPairGenerator or KeyFactory." > > In the example, you use "Ed25519" and not "ECDSA" as the alg name for > KeyPairGenerator - which one is correct? I added a parenthetical to clarify that "Ed25519" can be used here in addition to "EdDSA". The point of this sentence is to state that there is no algorithm name like "EdEC" that can be used generate keys for either EdDSA or some other scheme that uses the same kind of keys. > > --Sean > From joe.darcy at oracle.com Thu Aug 9 18:36:21 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 9 Aug 2018 11:36:21 -0700 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings -- now RFR for 8209304: Deprecate serialVersionUID fields in interfaces In-Reply-To: <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com> Message-ID: Hi Alan, On 8/6/2018 11:12 PM, Alan Bateman wrote: > > > On 06/08/2018 20:11, joe darcy wrote: >> Hello, >> >> Various interfaces in the JDK extend Serializable and declare >> serialVersionUID fields. Such fields are ineffectual and >> @SuppressWarnings("serial") should be applied to such fields to >> suppress future planned serial lint checks (JDK-8202056). >> >> Most of the affected files are in the security-libs area with a >> handful in RMI and JNDI: >> >> ??? http://cr.openjdk.java.net/~darcy/8209024.0/ >> >> Patch below. I'll fix-up the copyright years before any push. > Is there a follow-on patch coming to deprecate these fields? > > Filed 8209304: Deprecate serialVersionUID fields in interfaces; webrev for review: ??? http://cr.openjdk.java.net/~darcy/8209304.0/ Security libs team, for src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java I added a separate @Deprecated annotation for the serialVersionUID field even though the interface itself is already deprecated. That interface's javadoc states: ? 41? * @deprecated Sun JDK internal use only --- WILL BE REMOVED in a future ? 42? * release. If you like, as part of this changeset I can upgrade (downgrade?) the @Deprecated annotation for this class to forRemoval=true. Once that detail is sorted out, I'll create the corresponding CSR. (Since the java.lang.Deprecated annotation type is @Documented, adding, removing, or changing @Deprecated annotations is an interface change.) Thanks, -Joe From sean.mullan at oracle.com Thu Aug 9 19:31:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 Aug 2018 15:31:10 -0400 Subject: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported In-Reply-To: References: <94A33519-DC3B-4AB5-8DCA-8D9A40DD3CA7@oracle.com> <71d54b7e-854f-d28b-783e-0b1348c02594@oracle.com> <5426b607-1a45-02bb-f2ce-61a71ea36c16@oracle.com> Message-ID: <0bf3da35-90b5-524d-8f13-6a2be244798e@oracle.com> On 8/7/18 11:53 PM, Weijun Wang wrote: > > >> On Aug 8, 2018, at 12:58 AM, Sean Mullan wrote: >> >> On 8/6/18 8:20 PM, Weijun Wang wrote: >>>> I'm not seeing how this would be a behavior change if it is a new option, can you add more details on that? If I specify -providerName, intuitively I would expect it would be used, at least as the first one. >>> Before this change when "keytool -importcert" is called, KeyStore.getInstance() uses "-providername" but CertificateFactory.getInstance()*does not*. Now CertificateFactory.getInstance() is using it. If it's preferred than the default provider, then it's a behavior change. >> >> Ok, I see. But this is the first time we have had issues with CertificateFactory. And we probably want to avoid having multiple -providerName options for each JCA engine that is used. >> >> But keytool -printcert does not interact with a KeyStore at all. Couldn't you distinguish between the two options and always use -providerName for CertificateFactory for -printcert? > > But in a real world people usually run keytool -printcert and then -importcert. -importcert would show the content of the cert if it's not trusted by existing CAs and ask for a yes/no. If people see different output (i.e. toString() of the X509Certificate child in a provider), will that be a little strange? Could be, I suppose. The -providerName option is kind of broken in that one provider is not always sufficient, but probably not worth trying to fix. So I think I agree with your approach as it seems to be the least disruptive option. --Sean From timbrooks at fastmail.com Thu Aug 9 23:23:21 2018 From: timbrooks at fastmail.com (Tim Brooks) Date: Thu, 9 Aug 2018 17:23:21 -0600 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> Message-ID: Hi Xuelei, My test passed using that patch. I?ll continue to explore over the next few days. But that patch resolves the main issues that I had encountered. Thanks, - Tim > On Aug 7, 2018, at 8:54 AM, Xuelei Fan wrote: > > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Aug 10 00:57:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 9 Aug 2018 17:57:05 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> Message-ID: <6018a034-598d-8cab-4b33-66335fb39746@oracle.com> Thank you, Tim! Please feel free to submit bugs and comments. Xuelei On 8/9/2018 4:23 PM, Tim Brooks wrote: > Hi?Xuelei, > > My test passed using that patch. I?ll continue to explore over the next > few days. But that patch resolves the main issues that I had encountered. > > Thanks, > > - Tim > >> On Aug 7, 2018, at 8:54 AM, Xuelei Fan > > wrote: >> >> Xuelei > From weijun.wang at oracle.com Fri Aug 10 10:53:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Aug 2018 18:53:16 +0800 Subject: RFR: JDK-8209129 :Further improvements to cipher buffer management In-Reply-To: <1bd9e050-409a-3b6d-26e8-62b909d6a306@oracle.com> References: <1bd9e050-409a-3b6d-26e8-62b909d6a306@oracle.com> Message-ID: <31BDBAEE-DF81-4D97-A7DA-F0CD188D2FB1@oracle.com> HmacPKCS12PBESHA1.java: 76 byte[] passwdBytes = key.getEncoded(); 77 if ((passwdBytes == null) || 78 !(key.getAlgorithm().regionMatches(true, 0, "PBE", 0, 3))) { 79 throw new InvalidKeyException("Missing password"); 80 } Please also cleanup passwdBytes. Maybe divide the if check above into 2 to avoid passwdBytes being assigned but algorithm is not PBE. 132 Arrays.fill(passwdChars, '0'); In a finally block? PBES1Core.java: 250 Arrays.fill(passwdBytes, (byte) 0x00); In a finally block? PBES2Core.java: 273 Arrays.fill(passwdChars, ' '); 274 Arrays.fill(passwdBytes, (byte)0x00); In a finally block? PBKDF2KeyImpl.java: 88 if (passwd == null) { 89 // Should allow an empty password. 90 this.passwd = new char[0]; 91 } else { 92 this.passwd = passwd.clone(); 93 } 94 // Convert the password from char[] to byte[] 95 byte[] passwdBytes = getPasswordBytes(this.passwd); 96 // remove local copy 97 Arrays.fill(passwd, '0'); Strange, why passwd.clone()? 129 Arrays.fill(passwdBytes, (byte)0x00); In a finally block? PBMAC1Core.java: 111 byte[] passwdBytes = key.getEncoded(); 112 if ((passwdBytes == null) || 113 !(key.getAlgorithm().regionMatches(true, 0, "PBE", 0, 3))) { 114 throw new InvalidKeyException("Missing password"); 115 } 170 Arrays.fill(passwdChars, ' '); Same comments as for HmacPKCS12PBESHA1.java. PKCS12PBECipherCore.java: 262 char[] passwdChars = null; Deal with the same way as in PBMAC1Core.java? MD4.java: 110 void implReset() { Add @Override. Thanks Max > On Aug 9, 2018, at 6:42 PM, Se?n Coffey wrote: > > Adding RFR to title.. > > On 09/08/2018 11:37, Se?n Coffey wrote: >> I've been looking further at how private/temporary buffers are used in cipher/keystore management and identified some more areas that could benefit with a more aggressive nulling out of contents. >> >> I've been testing through use of stepping through debugging sessions while setting/getting keys and capturing process memory via tooling like gcore. >> >> JBS report : https://bugs.openjdk.java.net/browse/JDK-8209129 >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8209129.v1/webrev/index.html >> >> TCK and regression tests are green. >> >> regards, >> Sean. >> > From sean.coffey at oracle.com Fri Aug 10 14:18:07 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 10 Aug 2018 15:18:07 +0100 Subject: RFR: JDK-8209129 :Further improvements to cipher buffer management In-Reply-To: <31BDBAEE-DF81-4D97-A7DA-F0CD188D2FB1@oracle.com> References: <1bd9e050-409a-3b6d-26e8-62b909d6a306@oracle.com> <31BDBAEE-DF81-4D97-A7DA-F0CD188D2FB1@oracle.com> Message-ID: <99fd1e16-4818-cadd-bade-d33cd6625169@oracle.com> Thanks for the review Max - comments inline.. Regards, Sean. On 10/08/18 11:53, Weijun Wang wrote: > HmacPKCS12PBESHA1.java: > > 76 byte[] passwdBytes = key.getEncoded(); > 77 if ((passwdBytes == null) || > 78 !(key.getAlgorithm().regionMatches(true, 0, "PBE", 0, 3))) { > 79 throw new InvalidKeyException("Missing password"); > 80 } > > Please also cleanup passwdBytes. Maybe divide the if check above into 2 to avoid passwdBytes being assigned but algorithm is not PBE. Yes - I had thought about refactoring this code during edits. Will make that change. > > 132 Arrays.fill(passwdChars, '0'); > > In a finally block? > > PBES1Core.java: > > 250 Arrays.fill(passwdBytes, (byte) 0x00); > > In a finally block? > > PBES2Core.java: > > 273 Arrays.fill(passwdChars, ' '); > 274 Arrays.fill(passwdBytes, (byte)0x00); > > In a finally block? Yes - makes sense to capture above in finally blocks. Will re-factor. > > PBKDF2KeyImpl.java: > > 88 if (passwd == null) { > 89 // Should allow an empty password. > 90 this.passwd = new char[0]; > 91 } else { > 92 this.passwd = passwd.clone(); > 93 } > 94 // Convert the password from char[] to byte[] > 95 byte[] passwdBytes = getPasswordBytes(this.passwd); > 96 // remove local copy > 97 Arrays.fill(passwd, '0'); > > Strange, why passwd.clone()? Not sure - it's original behaviour. I'll check if it makes sense to change. > > 129 Arrays.fill(passwdBytes, (byte)0x00); > > In a finally block? > > PBMAC1Core.java: > > 111 byte[] passwdBytes = key.getEncoded(); > 112 if ((passwdBytes == null) || > 113 !(key.getAlgorithm().regionMatches(true, 0, "PBE", 0, 3))) { > 114 throw new InvalidKeyException("Missing password"); > 115 } > > 170 Arrays.fill(passwdChars, ' '); > > Same comments as for HmacPKCS12PBESHA1.java. > > PKCS12PBECipherCore.java: > > 262 char[] passwdChars = null; > > Deal with the same way as in PBMAC1Core.java? > > MD4.java: > > 110 void implReset() { > > Add @Override. All above comments make sense. I've come across one other possible issue in MessageDigest functionality. I'm debugging that to be sure. Will get a new webrev out once that's done. regards, Sean. > > Thanks > Max > > >> On Aug 9, 2018, at 6:42 PM, Se?n Coffey wrote: >> >> Adding RFR to title.. >> >> On 09/08/2018 11:37, Se?n Coffey wrote: >>> I've been looking further at how private/temporary buffers are used in cipher/keystore management and identified some more areas that could benefit with a more aggressive nulling out of contents. >>> >>> I've been testing through use of stepping through debugging sessions while setting/getting keys and capturing process memory via tooling like gcore. >>> >>> JBS report : https://bugs.openjdk.java.net/browse/JDK-8209129 >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8209129.v1/webrev/index.html >>> >>> TCK and regression tests are green. >>> >>> regards, >>> Sean. >>> From sean.mullan at oracle.com Fri Aug 10 15:39:24 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 10 Aug 2018 11:39:24 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> Message-ID: I need more time to finish my review but here are some initial comments: - java.security 1079 # jarpath - enables more detailed information in the IOExceptions thrown Use "jarPath" to be consistent with "hostInfo". 1080 # by java.util.jar.Attributes and java.util.jar.Manifest and java.util.jar.JarFile - Manifest.java 57 private String jarFilename = null; Not necessary to set it to null, as that is the default. 82 Manifest(InputStream is, String jarFilename) throws IOException { 83 this.jarFilename = jarFilename; 84 read(is); 85 } Read from the InputStream and check for error conditions *before* setting jarFilename (switch lines 83 & 84). This is a general best practice but can also protect against finalizer attacks. See JSCG 7-3 for more info: https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7 - Attributes.java As Chris and Alan mentioned, you should move the parsing of the property to a more general location so it can be used by other code that uses this property. --Sean On 8/8/18 11:00 AM, Sean Mullan wrote: > Cross-posting to security-dev since this fix is security related and > should also be reviewed there. > > --Sean > > On 8/7/18 11:00 AM, Baesken, Matthias wrote: >> Ping ....? ?? , any reviews / comments ? >> >> Thanks , Matthias >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Dienstag, 31. Juli 2018 12:28 >>> To: 'Chris Hegarty' ; Alan Bateman >>> >>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz >>> ; Langer, Christoph >>> >>> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest >>> parsing of jar archives >>> >>> Hello , >>> looks like? the? generalization of? the `includeInExceptions` >>> security?? property >>> is now in jdk/jdk? after >>> >>> "8207846: Generalize the jdk.net.includeInExceptions security property" >>> >>> was added, great news? and thanks to Chris for driving this ! >>> >>> I use this security property now as well , and updated the? change : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/ >>> >>> I updated the CSR as well : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8207768 >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Chris Hegarty >>>> Sent: Donnerstag, 19. Juli 2018 14:54 >>>> To: Alan Bateman ; Baesken, Matthias >>>> >>>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz >>>> >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest >>>> parsing of jar archives >>>> >>>> >>>>> On 19 Jul 2018, at 11:46, Alan Bateman >>>> wrote: >>>>> >>>>> On 19/07/2018 09:07, Baesken, Matthias wrote: >>>>>> Hello, in the meantime I? prepared a CSR : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207768 >>>>>> >>>>>> >>>>>>> jdk.includeInExceptions expands the scope. That might be okay but we >>>>>>> will need to re-visit jdk.net.includeInExceptions and also move the >>>>>>> support to somewhere in jdk.internal so that it can be used by other >>>>>>> code in java.base. >>>>>> Is there some support code for? " jdk.net.includeInExceptions " >>>>>> or do >>>> you just? mean? the name of the property ? >>>>>> >>>>> Chris is right that it's a bit premature to submit a CSR while the >>>>> question >>> on >>>> whether to rename the existing security property is on the table. I >>>> have no >>>> objection to doing that. >>>> >>>> I filed the following issue to generalize the `includeInExceptions` >>>> security >>>> ? property: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8207846 >>>> >>>> I would like to resolve 8207846 first, then 8205525 can propose to >>>> add the >>>> new argument value, `jarPath`. >>>> >>>> -Chris. From anthony.scarpino at oracle.com Fri Aug 10 19:49:16 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 10 Aug 2018 12:49:16 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <17372eb4-9006-2150-547d-87dcbbb90a2c@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> <650ee21d-ec31-0ee0-ab2a-cf4fed2a21d4@oracle.com> <17372eb4-9006-2150-547d-87dcbbb90a2c@oracle.com> Message-ID: On 08/09/2018 06:49 AM, Xuelei Fan wrote: > On 8/9/2018 4:25 AM, Sean Mullan wrote: >> On 8/8/18 5:29 PM, Xuelei Fan wrote: >>> The "Default" algorithm defined in the SunJSSE provider is for TLS >>> protocols. >> >> What if I set DTLS to be the default, though? Ex: >> >> ???? SSLContext.setDefault(SSLContext.getInstance("DTLS")); >> > Good point!? Maybe, we also need to update the > SSLSocketFactory/SSLServerSocketFactory.getDefault() to return > inoperative factory. I'm not sure the code path you're looking as the oneI see seems pretty obscure. Are you two talking about where SSL[Server]SocketFactory.getDefault() uses a ssl.SocketFactory.provider property set to SunJSSE? If so, can see that as a code review comment, but it seems very obscure for the CSR. > Xuelei > >> --Sean >> >>> >>> Xuelei >>> >>> On 8/8/2018 1:28 PM, Sean Mullan wrote: >>>> On 8/8/18 1:58 PM, Anthony Scarpino wrote: >>>>> I don't see where your example of getDefault() is any different >>>>> than the current code path.? A user has to define a SSLContext when >>>>> using getDefault() which as far as I can tell goes through the code >>>>> path of SSLContext.get[Server]SocketFactory() >>>> >>>> SSL{Server}SocketFactory.getDefault() says: "Otherwise, this method >>>> returns SSLContext.getDefault().get{Server}SocketFactory(). If that >>>> call fails, an inoperative factory is returned." >>>> >>>> So it doesn't look like we have to do anything special for this >>>> case, but as part of this fix, we should check/test that an >>>> inoperative factory is returned if a DTLS context is the default. >>>> >>>> --Sean >>>> >>>>> >>>>> Tony >>>>> >>>>> On 08/08/2018 08:52 AM, Chris Hegarty wrote: >>>>>> +1 to everything Sean said, and just to add ... >>>>>> >>>>>> This change will prevent an SSLContext from giving out socket >>>>>> factories when it has been configured with DTLS. What about >>>>>> SSL[Server]SocketFactory::getDefault when the default SSL >>>>>> context is DTLS? I don?t see that getDefault can throw an UOE, >>>>>> should it???? Or should / could this be resolved at the socket >>>>>> factory level, when trying to create new sockets rather than at >>>>>> the factory retrieval time? >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> On 8 Aug 2018, at 15:46, Sean Mullan wrote: >>>>>>> >>>>>>> On 8/7/18 8:05 PM, Xuelei Fan wrote: >>>>>>>> Hi Tony, >>>>>>>> The Specification section looks more like the implementation >>>>>>>> details. We may change the implementation details again in the >>>>>>>> future.? It may be more suitable to move it to the Solution >>>>>>>> section, or just remove it. >>>>>>> >>>>>>> I agree, I would omit the diffs and put N/A for the Specification >>>>>>> section. >>>>>>> >>>>>>>> In the Specification section, I may just say something like, "No >>>>>>>> APIs changes.? The SunJSSE provider is updated to throw >>>>>>>> UnsupportedOperationException if >>>>>>>> SSLContext.SSLServerSocketFactory() or >>>>>>>> SSLContext.SSLSocketFactory() get called for DTLS algorithms >>>>>>>> SSLContext". >>>>>>> >>>>>>> I think the CSR should also say that the SunJSSE implementation >>>>>>> of the engineGetSocketFactory and engineGetServerSocketFactory >>>>>>> methods of SSLContextSpi have been changed to throw >>>>>>> UnsupportedOperationException. That is the specific API behavior >>>>>>> change. >>>>>>> >>>>>>> A few other comments on the CSR: >>>>>>> >>>>>>> "SSLContext.getSSLSocketFactory() and >>>>>>> SSLContext.getSSLServerSocketFactory()" >>>>>>> >>>>>>> Typo, there is no "SSL" in the method names. >>>>>>> >>>>>>> The Compatibility Risk field has several typos ("there" -> >>>>>>> "their", "how -> now", ...) and is a bit hard to understand. >>>>>>> Wasn't TLS being used before instead of DTLS in certain >>>>>>> scenarios? Because the API silently passed in certain cases, and >>>>>>> now we will be throwing an Exception, maybe it might be better to >>>>>>> say the risk is low. >>>>>>> >>>>>>> In the Summary section, it says "..., but it is not documented." >>>>>>> I suggest opening a docs bug to improve the DTLS documentation so >>>>>>> that it is more clear this scenario is not supported. >>>>>>> >>>>>>> I think the Interface Kind should be Java API since we are >>>>>>> changing the behavior of an implementation of a standard API. I >>>>>>> asked Joe Darcy this question yesterday, and he agreed. >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> On 8/7/2018 4:14 PM, Anthony Scarpino wrote: >>>>>>>>> Hi Xuelei, >>>>>>>>> >>>>>>>>> I have updated the csr and I believe I have addressed your >>>>>>>>> comments. >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> >>>>>>>>> Tony >>>>>>>>> >>>>>>>>> On 08/07/2018 01:43 PM, Xuelei Fan wrote: >>>>>>>>>> Hi Tony, >>>>>>>>>> >>>>>>>>>> Would you mind make it clear that this impact the JDK JSSE >>>>>>>>>> provider only?? Third party's provider may be able to support >>>>>>>>>> DTLS with SSLSocket. >>>>>>>>>> >>>>>>>>>> I think there may be no specification change.? The >>>>>>>>>> SSLContext.getServerSocketFactory() and >>>>>>>>>> SSLContext.getSocketFactory() defines the spec if the >>>>>>>>>> algorithm is not supported by the underlying provider, >>>>>>>>>> "UnsupportedOperationException - if the underlying provider >>>>>>>>>> does not implement the operation.".? I may prefer to make it >>>>>>>>>> clear that this is just a behavior change of the JDK JSSE >>>>>>>>>> provider (SunJSSE).? The SunJSSE provider now throws >>>>>>>>>> UnsupportedOperationException for creating >>>>>>>>>> SSL(Server)SocketFactory with DTLS SSLContext, because it does >>>>>>>>>> not actually support DTLS SSLSocket. >>>>>>>>>> >>>>>>>>>> In Solution section, "Throwing a UnsupportedOperationException >>>>>>>>>> when getting a socket from the SSLServerSocketFactory or >>>>>>>>>> SSLSocketFactory for DTLS."?? I guess you meant, throwing a >>>>>>>>>> UOE when calling SSLContext.getServerSocketFactory() and >>>>>>>>>> SSLContext.getSocketFactory()? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> On 8/7/2018 12:17 PM, Anthony Scarpino wrote: >>>>>>>>>>> I need a review of a CSR for SSLSocket should throw an >>>>>>>>>>> exception when configuring DTLS.? We are targeting this for >>>>>>>>>>> 12 right now. >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209031 >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> >>>>>>>>>>> Tony >>>>>>>>>>> >>>>>>>>> >>>>>> >>>>> From jamil.j.nimeh at oracle.com Fri Aug 10 23:02:22 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 10 Aug 2018 16:02:22 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> Message-ID: <0ee9e20c-5400-519a-7875-6dadd7bfa626@oracle.com> I'm good with the changes. --Jamil On 8/7/2018 5:24 PM, Xuelei Fan wrote: > Hi Jamil, > > Thanks for comments.? Here is the updated webrev: > ?? http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/ > > Thanks, > Xuelei > > On 8/7/2018 3:12 PM, Jamil Nimeh wrote: >> Hi Xuelei, mostly small stuff: >> >> ? * SSLEngineImpl.java >> ????? o 717: Nit, inbout --> inbound >> ? * SSLEngineOutputRecord.java >> ????? o 162, 169: Nit, applicatoin --> application >> ????? o Same section: It looks like the "if" and "else if" clauses take >> ??????? the same actions with the same message.? Maybe just do "if >> ??????? (isClosed())" ?? Or were you planning to have different messages >> ??????? here? >> ? * SSLSocketOutputRecord.java >> ????? o 58, 97, 204: Typo,? closedd --> closed >> ? * TLSEngineClosureTest.java >> ????? o 2: Copyright date fix >> ????? o 26: If this is a new test should the bug ID be different than >> ??????? 8085979? >> >> --Jamil >> >> >> On 08/07/2018 07:46 AM, Xuelei Fan wrote: >>> New webrev: >>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ >>> >>> Thanks for a find of Tim Brooks, that the SSLEngine inbound/outbound >>> status is incorrect if closing during handshake. The above webrev is >>> trying to fix the problems. See more in the OpenJDK thread: >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html >>> >>> >>> Please let me know your concerns before this Wednesday. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/3/2018 1:55 PM, Xuelei Fan wrote: >>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >>>> >>>> In webrev.01, the socket close may be blocked by super class close >>>> synchronization.? Updated the SSLSocketImpl.java to use handshake >>>> only lock in the startHandshake() implementation. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>>>> >>>>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>>>> renegotiation fails if Java client allows TLSv1.3". >>>>> SSLHandshake.java is updated to use negotiated version so that TLS >>>>> 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>>>> >>>>>> Please let me know your concerns by the end of August 1st, 2018. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> >>>>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the update for the TLS 1.3 half-close and >>>>>>> synchronization implementation: >>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>>>> >>>>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify >>>>>>> is use to close the local write side and peer read side only.? >>>>>>> After the close_notify get handles, the local read side and peer >>>>>>> write side may still be open. >>>>>>> >>>>>>> In this update, if an application calls >>>>>>> SSLEngine.closeInbound/Outbound() or >>>>>>> SSLSocket.shutdownInput/Output(), half-close will be used.? For >>>>>>> compatibility, if SSLSocket.close() get called, a duplex close >>>>>>> will be tried.? In order to support duplex close, JDK will use >>>>>>> the user_canceled warning alert even the handshake complete. >>>>>>> >>>>>>> In practice, an application may only close outbound even it is >>>>>>> intended to close the inbound as well, or close the connection >>>>>>> completely.? It works for TLS 1.2 and prior versions.? But no >>>>>>> more for TLS 1.3 because of the close_notify behavior change in >>>>>>> the TLS 1.3 specification.? The application may be hung and >>>>>>> dead-waiting for read/close.? It could be solved by closing the >>>>>>> inbound explicitly. In order to mitigate the impact, a new >>>>>>> System Property is introduced, "jdk.tls.acknowledgeCloseNotify" >>>>>>> if source code update is not available. ??If the System Property >>>>>>> is set to "true", if receiving the close_notify, a close_notify >>>>>>> alert will be responded.? It is a countermeasure of the TLS 1.3 >>>>>>> half-close issues. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> >>>>>>> >> From bradford.wetmore at oracle.com Sat Aug 11 01:14:49 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 10 Aug 2018 18:14:49 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <6018a034-598d-8cab-4b33-66335fb39746@oracle.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> <6018a034-598d-8cab-4b33-66335fb39746@oracle.com> Message-ID: On 8/9/2018 5:57 PM, Xuelei Fan wrote: > Thank you, Tim!?? Please feel free to submit bugs and comments. I went through a standard SSLEngineTemplate handshake/data/close with a fine-tooth comb (debugger), and found two bugs based on your -04 patch. 1. Things may have changed since the original SSLEngine implementation, but unwrap() was supposed to return a BUFFER_UNDERFLOW if there is not enough (or any) inbound data to make a packet. I'm seeing a mix of OK and BUFFER_UNDERFLOW. I haven't determined the pattern, but you should be able to run my test (attached) and see pretty quickly. 2. I haven't not had the cycles to follow the earlier discussion, so this may be a duplicate of something already discussed, but I got myself into an endless loop because the closes weren't happening as expected. In the attached file, after the handshaking and data exchange, close just one of the SSLEngines outbound side. I'll use client for this example, but same error with server side: // clientEngine.closeOutbound(); clientEngine.getHandshakeStatus() == NEED_WRAP client.isInboundDone(): false client.isOutboundDone(): false // client.wrap() sends the Close Notify (CN). client wrap: CLOSED/NEED_UNWRAP, 0/24 bytes clientEngine.getHandshakeStatus() == NEED_UNWRAP client.isInboundDone(): false client.isOutboundDone(): true // server.unwrap() parses the CN, and closes the inbound side. server unwrap: CLOSED/NEED_WRAP, 24/0 bytes clientEngine.getHandshakeStatus() == NEED_WRAP server.isInboundDone(): true server.isOutboundDone(): false So far so good. // server.wrap() needs to send the corresponding close_notify. server wrap: OK/NEED_WRAP, 0/0 bytes clientEngine.getHandshakeStatus() == NEED_WRAP server.isInboundDone(): true server.isOutboundDone(): false Whoops, it didn't happen. No outbound data was generated. State is still in NEED_WRAP. I just let the app run, it never closes because no CN is generated on the server side. Run the attached file for full details. Thanks, Brad > Xuelei > > On 8/9/2018 4:23 PM, Tim Brooks wrote: >> Hi?Xuelei, >> >> My test passed using that patch. I?ll continue to explore over the >> next few days. But that patch resolves the main issues that I had >> encountered. >> >> Thanks, >> >> - Tim >> >>> On Aug 7, 2018, at 8:54 AM, Xuelei Fan >> > wrote: >>> >>> Xuelei >> -------------- next part -------------- /* * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ // SunJSSE does not support dynamic system properties, no way to re-use // system properties in samevm/agentvm mode. /* * @test * @bug 1234567 * @summary XYZ * @run main/othervm TestSSLEngineFailedALPN */ /** * A SSLEngine usage example which simplifies the presentation * by removing the I/O and multi-threading concerns. * * The test creates two SSLEngines, simulating a client and server. * The "transport" layer consists two byte buffers: think of them * as directly connected pipes. * * Note, this is a *very* simple example: real code will be much more * involved. For example, different threading and I/O models could be * used, transport mechanisms could close unexpectedly, and so on. * * When this application runs, notice that several messages * (wrap/unwrap) pass before any application data is consumed or * produced. (For more information, please see the SSL/TLS * specifications.) There may several steps for a successful handshake, * so it's typical to see the following series of operations: * * client server message * ====== ====== ======= * wrap() ... ClientHello * ... unwrap() ClientHello * ... wrap() ServerHello/Certificate * unwrap() ... ServerHello/Certificate * wrap() ... ClientKeyExchange * wrap() ... ChangeCipherSpec * wrap() ... Finished * ... unwrap() ClientKeyExchange * ... unwrap() ChangeCipherSpec * ... unwrap() Finished * ... wrap() ChangeCipherSpec * ... wrap() Finished * unwrap() ... ChangeCipherSpec * unwrap() ... Finished */ import javax.net.ssl.*; import javax.net.ssl.SSLEngineResult.*; import java.io.*; import java.security.*; import java.nio.*; public class SSLEngineFailedALPN { /* * Enables logging of the SSLEngine operations. */ private static final boolean logging = true; /* * Enables the JSSE system debugging system property: * * -Djavax.net.debug=all * * This gives a lot of low-level information about operations underway, * including specific handshake messages, and might be best examined * after gaining some familiarity with this application. */ private static final boolean debug = true; private final SSLContext sslc; private SSLEngine clientEngine; // client Engine private ByteBuffer clientOut; // write side of clientEngine private ByteBuffer clientIn; // read side of clientEngine private SSLEngine serverEngine; // server Engine private ByteBuffer serverOut; // write side of serverEngine private ByteBuffer serverIn; // read side of serverEngine /* * For data transport, this example uses local ByteBuffers. This * isn't really useful, but the purpose of this example is to show * SSLEngine concepts, not how to do network transport. */ private ByteBuffer cTOs; // "reliable" transport client->server private ByteBuffer sTOc; // "reliable" transport server->client /* * The following is to set up the keystores. */ private static final String pathToStores = "../../../../javax/net/ssl/etc"; private static final String keyStoreFile = "keystore"; private static final String trustStoreFile = "truststore"; private static final String passwd = "passphrase"; private static final String keyFilename = System.getProperty("test.src", ".") + "/" + pathToStores + "/" + keyStoreFile; private static final String trustFilename = System.getProperty("test.src", ".") + "/" + pathToStores + "/" + trustStoreFile; /* * Main entry point for this test. */ public static void main(String args[]) throws Exception { if (debug) { System.setProperty("javax.net.debug", "all"); } SSLEngineFailedALPN test = new SSLEngineFailedALPN(); test.runTest(); System.out.println("Test Passed."); } /* * Create an initialized SSLContext to use for these tests. */ public SSLEngineFailedALPN() throws Exception { KeyStore ks = KeyStore.getInstance("JKS"); KeyStore ts = KeyStore.getInstance("JKS"); char[] passphrase = passwd.toCharArray(); ks.load(new FileInputStream(keyFilename), passphrase); ts.load(new FileInputStream(trustFilename), passphrase); KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); kmf.init(ks, passphrase); TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); tmf.init(ts); SSLContext sslCtx = SSLContext.getInstance("TLS"); sslCtx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null); sslc = sslCtx; } /* * Run the test. * * Sit in a tight loop, both engines calling wrap/unwrap regardless * of whether data is available or not. We do this until both engines * report back they are closed. * * The main loop handles all of the I/O phases of the SSLEngine's * lifetime: * * initial handshaking * application data transfer * engine closing * * One could easily separate these phases into separate * sections of code. */ private void runTest() throws Exception { boolean dataDone = false; createSSLEngines(); createBuffers(); // results from client's last operation SSLEngineResult clientResult = null; // results from server's last operation SSLEngineResult serverResult = null; /* * Examining the SSLEngineResults could be much more involved, * and may alter the overall flow of the application. * * For example, if we received a BUFFER_OVERFLOW when trying * to write to the output pipe, we could reallocate a larger * pipe, but instead we wait for the peer to drain it. */ Exception clientException = null; Exception serverException = null; while (!isEngineClosed(clientEngine) || !isEngineClosed(serverEngine)) { log("================"); try { clientResult = clientEngine.wrap(clientOut, cTOs); log("client wrap: ", clientResult); } catch (Exception e) { clientException = e; System.out.println("Client wrap() threw: " + e.getMessage()); } runDelegatedTasks(clientResult, clientEngine); log(clientEngine.getHandshakeStatus().toString()); log("client.isInboundDone(): " + clientEngine.isInboundDone()); log("client.isOutboundDone(): " + clientEngine.isOutboundDone()); try { serverResult = serverEngine.wrap(serverOut, sTOc); log("server wrap: ", serverResult); } catch (Exception e) { serverException = e; System.out.println("Server wrap() threw: " + e.getMessage()); } runDelegatedTasks(serverResult, serverEngine); log(serverEngine.getHandshakeStatus().toString()); log("server.isInboundDone(): " + serverEngine.isInboundDone()); log("server.isOutboundDone(): " + serverEngine.isOutboundDone()); cTOs.flip(); sTOc.flip(); log("----"); try { clientResult = clientEngine.unwrap(sTOc, clientIn); log("client unwrap: ", clientResult); } catch (Exception e) { clientException = e; System.out.println("Client unwrap() threw: " + e.getMessage()); } runDelegatedTasks(clientResult, clientEngine); log(clientEngine.getHandshakeStatus().toString()); log("client.isInboundDone(): " + clientEngine.isInboundDone()); log("client.isOutboundDone(): " + clientEngine.isOutboundDone()); try { serverResult = serverEngine.unwrap(cTOs, serverIn); log("server unwrap: ", serverResult); } catch (Exception e) { serverException = e; System.out.println("Server unwrap() threw: " + e.getMessage()); } runDelegatedTasks(serverResult, serverEngine); log(serverEngine.getHandshakeStatus().toString()); log("server.isInboundDone(): " + serverEngine.isInboundDone()); log("server.isOutboundDone(): " + serverEngine.isOutboundDone()); cTOs.compact(); sTOc.compact(); /* * After we've transfered all application data between the client * and server, we close the clientEngine's outbound stream. * This generates a close_notify handshake message, which the * server engine receives and responds by closing itself. */ if (!dataDone && (clientOut.limit() == serverIn.position()) && (serverOut.limit() == clientIn.position())) { /* * A sanity check to ensure we got what was sent. */ checkTransfer(serverOut, clientIn); checkTransfer(clientOut, serverIn); log("\tClosing clientEngine's *OUTBOUND*..."); clientEngine.closeOutbound(); log(clientEngine.getHandshakeStatus().toString()); log("client.isInboundDone(): " + clientEngine.isInboundDone()); log("client.isOutboundDone(): " + clientEngine.isOutboundDone()); dataDone = true; log("\tClosing serverEngine's *OUTBOUND*..."); // serverEngine.closeOutbound(); log(serverEngine.getHandshakeStatus().toString()); log("server.isInboundDone(): " + serverEngine.isInboundDone()); log("server.isOutboundDone(): " + serverEngine.isOutboundDone()); } } if (clientException == null) { throw new Exception("Client Exception not seen"); } if (serverException == null) { throw new Exception("SErver Exception not seen"); } System.out.println("Test Passed."); } /* * Using the SSLContext created during object creation, * create/configure the SSLEngines we'll use for this test. */ private void createSSLEngines() throws Exception { /* * Configure the serverEngine to act as a server in the SSL/TLS * handshake. Also, require SSL client authentication. */ serverEngine = sslc.createSSLEngine(); serverEngine.setUseClientMode(false); serverEngine.setNeedClientAuth(true); SSLParameters paramsServer = serverEngine.getSSLParameters(); paramsServer.setApplicationProtocols(new String[]{"one"}); serverEngine.setSSLParameters(paramsServer); /* * Similar to above, but using client mode instead. */ clientEngine = sslc.createSSLEngine("client", 80); clientEngine.setUseClientMode(true); SSLParameters paramsClient = clientEngine.getSSLParameters(); paramsClient.setApplicationProtocols(new String[]{"one"}); clientEngine.setSSLParameters(paramsClient); } /* * Create and size the buffers appropriately. */ private void createBuffers() { /* * We'll assume the buffer sizes are the same * between client and server. */ SSLSession session = clientEngine.getSession(); int appBufferMax = session.getApplicationBufferSize(); int netBufferMax = session.getPacketBufferSize(); /* * We'll make the input buffers a bit bigger than the max needed * size, so that unwrap()s following a successful data transfer * won't generate BUFFER_OVERFLOWS. * * We'll use a mix of direct and indirect ByteBuffers for * tutorial purposes only. In reality, only use direct * ByteBuffers when they give a clear performance enhancement. */ clientIn = ByteBuffer.allocate(appBufferMax + 50); serverIn = ByteBuffer.allocate(appBufferMax + 50); cTOs = ByteBuffer.allocateDirect(netBufferMax); sTOc = ByteBuffer.allocateDirect(netBufferMax); clientOut = ByteBuffer.wrap("Hi Server, I'm Client".getBytes()); serverOut = ByteBuffer.wrap("Hello Client, I'm Server".getBytes()); } /* * If the result indicates that we have outstanding tasks to do, * go ahead and run them in this thread. */ private static void runDelegatedTasks(SSLEngineResult result, SSLEngine engine) throws Exception { if (result.getHandshakeStatus() == HandshakeStatus.NEED_TASK) { Runnable runnable; while ((runnable = engine.getDelegatedTask()) != null) { log("\trunning delegated task..."); runnable.run(); } HandshakeStatus hsStatus = engine.getHandshakeStatus(); if (hsStatus == HandshakeStatus.NEED_TASK) { throw new Exception( "handshake shouldn't need additional tasks"); } log("\tnew HandshakeStatus: " + hsStatus); } } private static boolean isEngineClosed(SSLEngine engine) { return (engine.isOutboundDone() && engine.isInboundDone()); } /* * Simple check to make sure everything came across as expected. */ private static void checkTransfer(ByteBuffer a, ByteBuffer b) throws Exception { a.flip(); b.flip(); if (!a.equals(b)) { throw new Exception("Data didn't transfer cleanly"); } else { log("\tData transferred cleanly"); } a.position(a.limit()); b.position(b.limit()); a.limit(a.capacity()); b.limit(b.capacity()); } /* * Logging code */ private static boolean resultOnce = true; private static void log(String str, SSLEngineResult result) { if (!logging) { return; } if (resultOnce) { resultOnce = false; System.out.println("The format of the SSLEngineResult is: \n" + "\t\"getStatus() / getHandshakeStatus()\" +\n" + "\t\"bytesConsumed() / bytesProduced()\"\n"); } HandshakeStatus hsStatus = result.getHandshakeStatus(); log(str + result.getStatus() + "/" + hsStatus + ", " + result.bytesConsumed() + "/" + result.bytesProduced() + " bytes"); if (hsStatus == HandshakeStatus.FINISHED) { log("\t...ready for application data"); } } private static void log(String str) { if (logging) { System.out.println(str); } } } From sha.jiang at oracle.com Mon Aug 13 02:44:16 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 13 Aug 2018 10:44:16 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries Message-ID: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> Hi, This patch provides a system property, exactly test.nss.lib.path, for specifying the absolute path to the custom NSS lib. And it also removes the NSS 3.16 binary libs on windows and macosx from repo. On these two platforms, PKCS11 tests will download new built NSS 3.35 libs from Artifactory. Webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8164639 Best regards, John Jiang From weijun.wang at oracle.com Mon Aug 13 03:25:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Aug 2018 11:25:26 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> Message-ID: <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and depending on whether secmod is used the test might load one or the other. I have the same question on the downloaded file from the artifact server. It seems for each platform it is a zip file. Will it extract all libraries into the same "nsslib" directory? Also, this is the 1st time I hear about @Artifact in an openjdk test and know nothing about it. Is there a detailed description on this feature somewhere? As for this test, if customNssLib is the first element in nssLibDirs and not set by a user, does this mean the test will always download libraries from an artifact server? Would it spend too much time on downloading? Is there a cache mechanism so that after the 1st PKCS11 test downloads the libraries the other tests can reuse them? Are they cleaned up at some time? Thanks Max [1] https://packages.ubuntu.com/xenial-updates/arm64/libnss3/filelist > On Aug 13, 2018, at 10:44 AM, sha.jiang at oracle.com wrote: > > Hi, > This patch provides a system property, exactly test.nss.lib.path, for specifying the absolute path to the custom NSS lib. > And it also removes the NSS 3.16 binary libs on windows and macosx from repo. > On these two platforms, PKCS11 tests will download new built NSS 3.35 libs from Artifactory. > > Webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8164639 > > Best regards, > John Jiang > From rajan.halade at oracle.com Mon Aug 13 04:58:33 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Sun, 12 Aug 2018 21:58:33 -0700 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> Message-ID: <9e3a955f-e67a-33ca-ddb3-e3218ea60427@oracle.com> Thanks John for this fix. May be it will help if you can include README file under pkcs11 detailing how the artifacts are to be build and bundled. See inline for my attempt to answer some of Max's queries - On 8/12/18 8:25 PM, Weijun Wang wrote: > Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and depending on whether secmod is used the test might load one or the other. I have the same question on the downloaded file from the artifact server. It seems for each platform it is a zip file. Will it extract all libraries into the same "nsslib" directory? John's README, once there, should address this. It is easier to deal with artifactory if files are packaged in a zip or tar format. The layout of contents will be addressed in README. > > Also, this is the 1st time I hear about @Artifact in an openjdk test and know nothing about it. Is there a detailed description on this feature somewhere? I haven't come across any documentation except the code at test/lib/jdk/test/lib/artifacts. This feature was added with JDK-8175300 to JDK 10. Thanks, Rajan > As for this test, if customNssLib is the first element in nssLibDirs and not set by a user, does this mean the test will always download libraries from an artifact server? Would it spend too much time on downloading? Is there a cache mechanism so that after the 1st PKCS11 test downloads the libraries the other tests can reuse them? Are they cleaned up at some time? > > Thanks > Max > > [1] https://packages.ubuntu.com/xenial-updates/arm64/libnss3/filelist > >> On Aug 13, 2018, at 10:44 AM, sha.jiang at oracle.com wrote: >> >> Hi, >> This patch provides a system property, exactly test.nss.lib.path, for specifying the absolute path to the custom NSS lib. >> And it also removes the NSS 3.16 binary libs on windows and macosx from repo. >> On these two platforms, PKCS11 tests will download new built NSS 3.35 libs from Artifactory. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8164639 >> >> Best regards, >> John Jiang >> From sha.jiang at oracle.com Mon Aug 13 05:46:04 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 13 Aug 2018 13:46:04 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> Message-ID: <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> On 2018/8/13 11:25, Weijun Wang wrote: > Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and depending on whether secmod is used the test might load one or the other. I assume the custom libs are in a single directory. This property is used for manual test run. When run different tests, users can specify different target lib path. > I have the same question on the downloaded file from the artifact server. It seems for each platform it is a zip file. Will it extract all libraries into the same "nsslib" directory? In my case, only one zip file is downloaded in a specific platform. And each archive is a separated artifact, which has different artifactId. The local path contains the artifactId, so different artifacts cannot be in the same directory. > > Also, this is the 1st time I hear about @Artifact in an openjdk test and know nothing about it. Is there a detailed description on this feature somewhere? I also don't get the details. > As for this test, if customNssLib is the first element in nssLibDirs and not set by a user, does this mean the test will always download libraries from an artifact server? If customNssLib is null, the test downloads the platform-specific artifact from Artifactory; otherwise, the test just uses the specified local NSS libs and no downloading is triggered. > Would it spend too much time on downloading? In this case, with my testing, it didn't take much time. > Is there a cache mechanism so that after the 1st PKCS11 test downloads the libraries the other tests can reuse them? With my testing, if the local path for a specific artifact exists, the same artifact should not be re-downloaded. > Are they cleaned up at some time? The libs are NOT removed after my manual test execution. But I don't know the details about this point in CI system. Best regards, John Jiang > > Thanks > Max > > [1] https://packages.ubuntu.com/xenial-updates/arm64/libnss3/filelist > >> On Aug 13, 2018, at 10:44 AM, sha.jiang at oracle.com wrote: >> >> Hi, >> This patch provides a system property, exactly test.nss.lib.path, for specifying the absolute path to the custom NSS lib. >> And it also removes the NSS 3.16 binary libs on windows and macosx from repo. >> On these two platforms, PKCS11 tests will download new built NSS 3.35 libs from Artifactory. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8164639 >> >> Best regards, >> John Jiang >> > From weijun.wang at oracle.com Mon Aug 13 05:58:05 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Aug 2018 13:58:05 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> Message-ID: <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> > On Aug 13, 2018, at 1:46 PM, sha.jiang at oracle.com wrote: > > On 2018/8/13 11:25, Weijun Wang wrote: >> Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and depending on whether secmod is used the test might load one or the other. > I assume the custom libs are in a single directory. > This property is used for manual test run. When run different tests, users can specify different target lib path. But as [1] shows they can be in different directories. Therefore either you have to move them into a single directory or you will not be able to run all PKCS11 tests with a single jtreg command. > >> I have the same question on the downloaded file from the artifact server. It seems for each platform it is a zip file. Will it extract all libraries into the same "nsslib" directory? > In my case, only one zip file is downloaded in a specific platform. > > And each archive is a separated artifact, which has different artifactId. > The local path contains the artifactId, so different artifacts cannot be in the same directory. > >> >> Also, this is the 1st time I hear about @Artifact in an openjdk test and know nothing about it. Is there a detailed description on this feature somewhere? > I also don't get the details. Is there an artifact server available on the open internet? > > >> As for this test, if customNssLib is the first element in nssLibDirs and not set by a user, does this mean the test will always download libraries from an artifact server? > If customNssLib is null, the test downloads the platform-specific artifact from Artifactory; > otherwise, the test just uses the specified local NSS libs and no downloading is triggered. But I think the most common case is no user-customized nss lib path. > >> Would it spend too much time on downloading? > In this case, with my testing, it didn't take much time. > >> Is there a cache mechanism so that after the 1st PKCS11 test downloads the libraries the other tests can reuse them? > With my testing, if the local path for a specific artifact exists, the same artifact should not be re-downloaded. What is the local path? I assume it is out of the scratch directory. If multiple tests are running in agentvm mode, is there a risk they share the same local path and see incomplete download? Thanks Max > >> Are they cleaned up at some time? > The libs are NOT removed after my manual test execution. > But I don't know the details about this point in CI system. > > Best regards, > John Jiang > >> >> Thanks >> Max >> >> [1] https://packages.ubuntu.com/xenial-updates/arm64/libnss3/filelist >> >>> On Aug 13, 2018, at 10:44 AM, sha.jiang at oracle.com wrote: >>> >>> Hi, >>> This patch provides a system property, exactly test.nss.lib.path, for specifying the absolute path to the custom NSS lib. >>> And it also removes the NSS 3.16 binary libs on windows and macosx from repo. >>> On these two platforms, PKCS11 tests will download new built NSS 3.35 libs from Artifactory. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8164639 >>> >>> Best regards, >>> John Jiang >>> >> > From sha.jiang at oracle.com Mon Aug 13 07:36:33 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 13 Aug 2018 15:36:33 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> Message-ID: <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> Hi Max, On 2018/8/13 13:58, Weijun Wang wrote: > >> On Aug 13, 2018, at 1:46 PM, sha.jiang at oracle.com wrote: >> >> On 2018/8/13 11:25, Weijun Wang wrote: >>> Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and depending on whether secmod is used the test might load one or the other. >> I assume the custom libs are in a single directory. >> This property is used for manual test run. When run different tests, users can specify different target lib path. > But as [1] shows they can be in different directories. Therefore either you have to move them into a single directory or you will not be able to run all PKCS11 tests with a single jtreg command. For some platforms, including linux-x64 and linux-x86, the test may search multiple directories for a specific NSS lib, namely softokn3 or nss3. Please see method getOsMap() in PKCS11Test.java. But I assume this property is used when a user-built NSS libs, but not system NSS libs, are needed. The user-built NSS libs could be in a single directory. >>> I have the same question on the downloaded file from the artifact server. It seems for each platform it is a zip file. Will it extract all libraries into the same "nsslib" directory? >> In my case, only one zip file is downloaded in a specific platform. >> >> And each archive is a separated artifact, which has different artifactId. >> The local path contains the artifactId, so different artifacts cannot be in the same directory. >> >>> Also, this is the 1st time I hear about @Artifact in an openjdk test and know nothing about it. Is there a detailed description on this feature somewhere? >> I also don't get the details. > Is there an artifact server available on the open internet? It's transparent to me. @Artifact tool delegates the downloading. >>> As for this test, if customNssLib is the first element in nssLibDirs and not set by a user, does this mean the test will always download libraries from an artifact server? >> If customNssLib is null, the test downloads the platform-specific artifact from Artifactory; >> otherwise, the test just uses the specified local NSS libs and no downloading is triggered. > But I think the most common case is no user-customized nss lib path. Yes. So, generally the value of property test.nss.lib.path is null. PKCS11 tests use system NSS libs on Linux and Solaris, but download windows and macosx NSS libs from Artifactory (previously, these libs are in repo). My fix doesn't change this logic. >>> Would it spend too much time on downloading? >> In this case, with my testing, it didn't take much time. >> >>> Is there a cache mechanism so that after the 1st PKCS11 test downloads the libraries the other tests can reuse them? >> With my testing, if the local path for a specific artifact exists, the same artifact should not be re-downloaded. > What is the local path? I assume it is out of the scratch directory. In my laptop, the path is: /private/var/tmp/jib-sha.jiang/install/jpg/tests/jdk/nsslib/nsslib-macosx_x64/3.35/nsslib-macosx_x64-3.35.zip/nsslib > If multiple tests are running in agentvm mode, is there a risk they share the same local path and see incomplete download? They should share the same local path. If no synchronization on actions of building local directory structure, downloading and/or unpacking, some issue may raise. I will consult infra team on this issue. Best regards, John Jiang > > Thanks > Max > >>> Are they cleaned up at some time? >> The libs are NOT removed after my manual test execution. >> But I don't know the details about this point in CI system. >> >> Best regards, >> John Jiang >> >>> Thanks >>> Max >>> >>> [1] https://packages.ubuntu.com/xenial-updates/arm64/libnss3/filelist >>> >>>> On Aug 13, 2018, at 10:44 AM, sha.jiang at oracle.com wrote: >>>> >>>> Hi, >>>> This patch provides a system property, exactly test.nss.lib.path, for specifying the absolute path to the custom NSS lib. >>>> And it also removes the NSS 3.16 binary libs on windows and macosx from repo. >>>> On these two platforms, PKCS11 tests will download new built NSS 3.35 libs from Artifactory. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.00/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8164639 >>>> >>>> Best regards, >>>> John Jiang >>>> > From weijun.wang at oracle.com Mon Aug 13 08:31:37 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Aug 2018 16:31:37 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> Message-ID: <094E1310-7CED-4D4D-A382-12BAF2019255@oracle.com> > On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com wrote: > > Hi Max, > > On 2018/8/13 13:58, Weijun Wang wrote: >> >>> On Aug 13, 2018, at 1:46 PM, sha.jiang at oracle.com wrote: >>> >>> On 2018/8/13 11:25, Weijun Wang wrote: >>>> Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and depending on whether secmod is used the test might load one or the other. >>> I assume the custom libs are in a single directory. >>> This property is used for manual test run. When run different tests, users can specify different target lib path. >> But as [1] shows they can be in different directories. Therefore either you have to move them into a single directory or you will not be able to run all PKCS11 tests with a single jtreg command. > For some platforms, including linux-x64 and linux-x86, the test may search multiple directories for a specific NSS lib, namely softokn3 or nss3. > Please see method getOsMap() in PKCS11Test.java. > > But I assume this property is used when a user-built NSS libs, but not system NSS libs, are needed. > The user-built NSS libs could be in a single directory. We still take [1] as the example. Suppose someone build and install NSS libs on an arm64 machine. (I don't have the experience to use an arm64 machine, just speculating). The files might be /usr/local/lib/aarch64-linux-gnu/libnss3.so /usr/local/lib/aarch64-linux-gnu/nss/libsoftokn3.so With the "/usr/local" prefix the existing hardcoded osMap will not locate the libraries and one has to use the new system property. I really don't want to require the user to copy the files to a single directory before running the test. No other comment except for: > >> If multiple tests are running in agentvm mode, is there a risk they share the same local path and see incomplete download? > They should share the same local path. > If no synchronization on actions of building local directory structure, downloading and/or unpacking, some issue may raise. > I will consult infra team on this issue. Thanks Max > > Best regards, > John Jiang From weijun.wang at oracle.com Mon Aug 13 08:48:46 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Aug 2018 16:48:46 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> Message-ID: <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> Sorry, more questions: > On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com wrote: > >> Is there an artifact server available on the open internet? > It's transparent to me. @Artifact tool delegates the downloading. Have you tried running the test outside Oracle? Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. Thanks Max From weijun.wang at oracle.com Mon Aug 13 10:24:27 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Aug 2018 18:24:27 +0800 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS Message-ID: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". I've already introduced a new GetBooleanAction::privilegedGetProperty method. Noreg-cleanup. Thanks Max From roger.riggs at oracle.com Mon Aug 13 13:53:07 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 13 Aug 2018 09:53:07 -0400 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> Message-ID: Hi Max, It might be useful to be a bit more consistent about putting the property name on the same line as the privilegedGetProperty. It would help finding/grepping for the targets of privileged actions. For example, Grep would not find the one in sun/security/krb5/Config.java:824-825 or sun/security/jgss/ProviderList.java:109 (due to the static field definition). Just a thought.. Otherwise looks fine. Roger On 8/13/18 6:24 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ > > This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". > > I've already introduced a new GetBooleanAction::privilegedGetProperty method. > > Noreg-cleanup. > > Thanks > Max > > From xuelei.fan at oracle.com Mon Aug 13 14:00:01 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 13 Aug 2018 07:00:01 -0700 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> Message-ID: Looks fine to me. Did you notice other places that might need similar update as well in security components? Thanks, Xuelei On 8/13/2018 3:24 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ > > This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". > > I've already introduced a new GetBooleanAction::privilegedGetProperty method. > > Noreg-cleanup. > > Thanks > Max > > From matthias.baesken at sap.com Mon Aug 13 15:18:27 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 13 Aug 2018 15:18:27 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> Message-ID: <4c6b969405364fc394459e8cd1789842@sap.com> >As Chris and Alan mentioned, you should move the parsing of the property >to a more general location so it can be used by other code that uses >this property. Hi Sean, Thanks for the input and comments . Could we do the moving of the property parsing do in a followup CR, I would prefer this . Best regards, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Freitag, 10. August 2018 17:39 > To: Baesken, Matthias ; Chris Hegarty > ; Alan Bateman > Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK dev at openjdk.java.net> > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > I need more time to finish my review but here are some initial comments: > > - java.security > > 1079 # jarpath - enables more detailed information in the IOExceptions > thrown > > Use "jarPath" to be consistent with "hostInfo". > > 1080 # by java.util.jar.Attributes and java.util.jar.Manifest > > and java.util.jar.JarFile > > - Manifest.java > > 57 private String jarFilename = null; > > Not necessary to set it to null, as that is the default. > > 82 Manifest(InputStream is, String jarFilename) throws IOException { > 83 this.jarFilename = jarFilename; > 84 read(is); > 85 } > > Read from the InputStream and check for error conditions *before* > setting jarFilename (switch lines 83 & 84). This is a general best > practice but can also protect against finalizer attacks. See JSCG 7-3 > for more info: > https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7 > > - Attributes.java > > As Chris and Alan mentioned, you should move the parsing of the property > to a more general location so it can be used by other code that uses > this property. > > --Sean > > On 8/8/18 11:00 AM, Sean Mullan wrote: > > Cross-posting to security-dev since this fix is security related and > > should also be reviewed there. > > > > --Sean > > > > On 8/7/18 11:00 AM, Baesken, Matthias wrote: > >> Ping ....? ?? , any reviews / comments ? > >> > >> Thanks , Matthias > >> > >>> -----Original Message----- > >>> From: Baesken, Matthias > >>> Sent: Dienstag, 31. Juli 2018 12:28 > >>> To: 'Chris Hegarty' ; Alan Bateman > >>> > >>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz > >>> ; Langer, Christoph > >>> > >>> Subject: RE: [RFR] 8205525 : Improve exception messages during > manifest > >>> parsing of jar archives > >>> > >>> Hello , > >>> looks like? the? generalization of? the `includeInExceptions` > >>> security?? property > >>> is now in jdk/jdk? after > >>> > >>> "8207846: Generalize the jdk.net.includeInExceptions security property" > >>> > >>> was added, great news? and thanks to Chris for driving this ! > >>> > >>> I use this security property now as well , and updated the? change : > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/ > >>> > >>> I updated the CSR as well : > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8207768 > >>> > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Chris Hegarty > >>>> Sent: Donnerstag, 19. Juli 2018 14:54 > >>>> To: Alan Bateman ; Baesken, Matthias > >>>> > >>>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz > >>>> > >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest > >>>> parsing of jar archives > >>>> > >>>> > >>>>> On 19 Jul 2018, at 11:46, Alan Bateman > >>>> wrote: > >>>>> > >>>>> On 19/07/2018 09:07, Baesken, Matthias wrote: > >>>>>> Hello, in the meantime I? prepared a CSR : > >>>>>> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207768 > >>>>>> > >>>>>> > >>>>>>> jdk.includeInExceptions expands the scope. That might be okay but > we > >>>>>>> will need to re-visit jdk.net.includeInExceptions and also move the > >>>>>>> support to somewhere in jdk.internal so that it can be used by > other > >>>>>>> code in java.base. > >>>>>> Is there some support code for? " jdk.net.includeInExceptions " > >>>>>> or do > >>>> you just? mean? the name of the property ? > >>>>>> > >>>>> Chris is right that it's a bit premature to submit a CSR while the > >>>>> question > >>> on > >>>> whether to rename the existing security property is on the table. I > >>>> have no > >>>> objection to doing that. > >>>> > >>>> I filed the following issue to generalize the `includeInExceptions` > >>>> security > >>>> ? property: > >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8207846 > >>>> > >>>> I would like to resolve 8207846 first, then 8205525 can propose to > >>>> add the > >>>> new argument value, `jarPath`. > >>>> > >>>> -Chris. From weijun.wang at oracle.com Mon Aug 13 15:33:21 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Aug 2018 23:33:21 +0800 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> Message-ID: <846ED189-408D-4B76-BBE4-096D3AD4671C@oracle.com> > On Aug 13, 2018, at 10:00 PM, Xue-Lei Fan wrote: > > Looks fine to me. > > Did you notice other places that might need similar update as well in security components? One "new GetPropertyAction()" at String property = AccessController.doPrivileged( new GetPropertyAction("jdk.tls.namedGroups")); But I haven't checked for doPrivileged(()->System.getProperty()) calls. Thanks Max > > Thanks, > Xuelei > > > On 8/13/2018 3:24 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >> Noreg-cleanup. >> Thanks >> Max From weijun.wang at oracle.com Mon Aug 13 15:36:35 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Aug 2018 23:36:35 +0800 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <846ED189-408D-4B76-BBE4-096D3AD4671C@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> <846ED189-408D-4B76-BBE4-096D3AD4671C@oracle.com> Message-ID: <23A708B4-8BF0-4B0B-8A7F-6628A444B2A6@oracle.com> And several AccessController.doPrivileged(new GetBooleanAction()) calls. If you'd like me to fix them as well, I can change the bug synopsis a little. Thanks Max > On Aug 13, 2018, at 11:33 PM, Weijun Wang wrote: > > > >> On Aug 13, 2018, at 10:00 PM, Xue-Lei Fan wrote: >> >> Looks fine to me. >> >> Did you notice other places that might need similar update as well in security components? > > One "new GetPropertyAction()" at > > String property = AccessController.doPrivileged( > new GetPropertyAction("jdk.tls.namedGroups")); > > But I haven't checked for doPrivileged(()->System.getProperty()) calls. > > Thanks > Max > >> >> Thanks, >> Xuelei >> >> >> On 8/13/2018 3:24 AM, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >>> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >>> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >>> Noreg-cleanup. >>> Thanks >>> Max > From xuelei.fan at oracle.com Mon Aug 13 18:31:29 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 13 Aug 2018 11:31:29 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: <0ee9e20c-5400-519a-7875-6dadd7bfa626@oracle.com> References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> <0ee9e20c-5400-519a-7875-6dadd7bfa626@oracle.com> Message-ID: One more update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/ It is desired to make a note in SSLSocket and SSLEngine specification, so that users have a good sense that an application should close the input and output stream always. Updated for SSLEngine.java and SSLSocket.java only. No changes in other files. Please let me know your concerns by the end of today. Thanks, Xuelei On 8/10/2018 4:02 PM, Jamil Nimeh wrote: > I'm good with the changes. > > --Jamil > > On 8/7/2018 5:24 PM, Xuelei Fan wrote: >> Hi Jamil, >> >> Thanks for comments.? Here is the updated webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/ >> >> Thanks, >> Xuelei >> >> On 8/7/2018 3:12 PM, Jamil Nimeh wrote: >>> Hi Xuelei, mostly small stuff: >>> >>> ? * SSLEngineImpl.java >>> ????? o 717: Nit, inbout --> inbound >>> ? * SSLEngineOutputRecord.java >>> ????? o 162, 169: Nit, applicatoin --> application >>> ????? o Same section: It looks like the "if" and "else if" clauses take >>> ??????? the same actions with the same message.? Maybe just do "if >>> ??????? (isClosed())" ?? Or were you planning to have different messages >>> ??????? here? >>> ? * SSLSocketOutputRecord.java >>> ????? o 58, 97, 204: Typo,? closedd --> closed >>> ? * TLSEngineClosureTest.java >>> ????? o 2: Copyright date fix >>> ????? o 26: If this is a new test should the bug ID be different than >>> ??????? 8085979? >>> >>> --Jamil >>> >>> >>> On 08/07/2018 07:46 AM, Xuelei Fan wrote: >>>> New webrev: >>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ >>>> >>>> Thanks for a find of Tim Brooks, that the SSLEngine inbound/outbound >>>> status is incorrect if closing during handshake. The above webrev is >>>> trying to fix the problems. See more in the OpenJDK thread: >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html >>>> >>>> >>>> Please let me know your concerns before this Wednesday. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/3/2018 1:55 PM, Xuelei Fan wrote: >>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >>>>> >>>>> In webrev.01, the socket close may be blocked by super class close >>>>> synchronization.? Updated the SSLSocketImpl.java to use handshake >>>>> only lock in the startHandshake() implementation. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>>>>> >>>>>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>>>>> renegotiation fails if Java client allows TLSv1.3". >>>>>> SSLHandshake.java is updated to use negotiated version so that TLS >>>>>> 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>>>>> >>>>>>> Please let me know your concerns by the end of August 1st, 2018. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> >>>>>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the update for the TLS 1.3 half-close and >>>>>>>> synchronization implementation: >>>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>>>>> >>>>>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify >>>>>>>> is use to close the local write side and peer read side only. >>>>>>>> After the close_notify get handles, the local read side and peer >>>>>>>> write side may still be open. >>>>>>>> >>>>>>>> In this update, if an application calls >>>>>>>> SSLEngine.closeInbound/Outbound() or >>>>>>>> SSLSocket.shutdownInput/Output(), half-close will be used.? For >>>>>>>> compatibility, if SSLSocket.close() get called, a duplex close >>>>>>>> will be tried.? In order to support duplex close, JDK will use >>>>>>>> the user_canceled warning alert even the handshake complete. >>>>>>>> >>>>>>>> In practice, an application may only close outbound even it is >>>>>>>> intended to close the inbound as well, or close the connection >>>>>>>> completely.? It works for TLS 1.2 and prior versions.? But no >>>>>>>> more for TLS 1.3 because of the close_notify behavior change in >>>>>>>> the TLS 1.3 specification.? The application may be hung and >>>>>>>> dead-waiting for read/close.? It could be solved by closing the >>>>>>>> inbound explicitly. In order to mitigate the impact, a new >>>>>>>> System Property is introduced, "jdk.tls.acknowledgeCloseNotify" >>>>>>>> if source code update is not available. ??If the System Property >>>>>>>> is set to "true", if receiving the close_notify, a close_notify >>>>>>>> alert will be responded.? It is a countermeasure of the TLS 1.3 >>>>>>>> half-close issues. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> >>>>>>>> >>> > From jamil.j.nimeh at oracle.com Mon Aug 13 18:45:15 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 13 Aug 2018 11:45:15 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> <0ee9e20c-5400-519a-7875-6dadd7bfa626@oracle.com> Message-ID: <93a20bf6-fc53-1446-71b9-0302e74763dc@oracle.com> Hi Xuelei, * SSLSocket.java o 134: Nit - You can remove the first "both" in this sentence since you use it later with the input/output stream closure. Looks good to me otherwise. --Jamil On 8/13/2018 11:31 AM, Xue-Lei Fan wrote: > One more update: > ? http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/ > > It is desired to make a note in SSLSocket and SSLEngine specification, > so that users have a good sense that an application should close the > input and output stream always. > > Updated for SSLEngine.java and SSLSocket.java only.? No changes in > other files. > > Please let me know your concerns by the end of today. > > Thanks, > Xuelei > > On 8/10/2018 4:02 PM, Jamil Nimeh wrote: >> I'm good with the changes. >> >> --Jamil >> >> On 8/7/2018 5:24 PM, Xuelei Fan wrote: >>> Hi Jamil, >>> >>> Thanks for comments.? Here is the updated webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/ >>> >>> Thanks, >>> Xuelei >>> >>> On 8/7/2018 3:12 PM, Jamil Nimeh wrote: >>>> Hi Xuelei, mostly small stuff: >>>> >>>> ? * SSLEngineImpl.java >>>> ????? o 717: Nit, inbout --> inbound >>>> ? * SSLEngineOutputRecord.java >>>> ????? o 162, 169: Nit, applicatoin --> application >>>> ????? o Same section: It looks like the "if" and "else if" clauses >>>> take >>>> ??????? the same actions with the same message.? Maybe just do "if >>>> ??????? (isClosed())" ?? Or were you planning to have different >>>> messages >>>> ??????? here? >>>> ? * SSLSocketOutputRecord.java >>>> ????? o 58, 97, 204: Typo,? closedd --> closed >>>> ? * TLSEngineClosureTest.java >>>> ????? o 2: Copyright date fix >>>> ????? o 26: If this is a new test should the bug ID be different than >>>> ??????? 8085979? >>>> >>>> --Jamil >>>> >>>> >>>> On 08/07/2018 07:46 AM, Xuelei Fan wrote: >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ >>>>> >>>>> Thanks for a find of Tim Brooks, that the SSLEngine >>>>> inbound/outbound status is incorrect if closing during handshake. >>>>> The above webrev is trying to fix the problems. See more in the >>>>> OpenJDK thread: >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html >>>>> >>>>> >>>>> Please let me know your concerns before this Wednesday. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/3/2018 1:55 PM, Xuelei Fan wrote: >>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >>>>>> >>>>>> In webrev.01, the socket close may be blocked by super class >>>>>> close synchronization.? Updated the SSLSocketImpl.java to use >>>>>> handshake only lock in the startHandshake() implementation. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>>>>>> >>>>>>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>>>>>> renegotiation fails if Java client allows TLSv1.3". >>>>>>> SSLHandshake.java is updated to use negotiated version so that >>>>>>> TLS 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>>>>>> >>>>>>>> Please let me know your concerns by the end of August 1st, 2018. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> >>>>>>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the update for the TLS 1.3 half-close and >>>>>>>>> synchronization implementation: >>>>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>>>>>> >>>>>>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the >>>>>>>>> close_notify is use to close the local write side and peer >>>>>>>>> read side only. After the close_notify get handles, the local >>>>>>>>> read side and peer write side may still be open. >>>>>>>>> >>>>>>>>> In this update, if an application calls >>>>>>>>> SSLEngine.closeInbound/Outbound() or >>>>>>>>> SSLSocket.shutdownInput/Output(), half-close will be used.? >>>>>>>>> For compatibility, if SSLSocket.close() get called, a duplex >>>>>>>>> close will be tried.? In order to support duplex close, JDK >>>>>>>>> will use the user_canceled warning alert even the handshake >>>>>>>>> complete. >>>>>>>>> >>>>>>>>> In practice, an application may only close outbound even it is >>>>>>>>> intended to close the inbound as well, or close the connection >>>>>>>>> completely.? It works for TLS 1.2 and prior versions.? But no >>>>>>>>> more for TLS 1.3 because of the close_notify behavior change >>>>>>>>> in the TLS 1.3 specification.? The application may be hung and >>>>>>>>> dead-waiting for read/close.? It could be solved by closing >>>>>>>>> the inbound explicitly. In order to mitigate the impact, a new >>>>>>>>> System Property is introduced, >>>>>>>>> "jdk.tls.acknowledgeCloseNotify" if source code update is not >>>>>>>>> available. ??If the System Property is set to "true", if >>>>>>>>> receiving the close_notify, a close_notify alert will be >>>>>>>>> responded.? It is a countermeasure of the TLS 1.3 half-close >>>>>>>>> issues. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Aug 13 18:50:23 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 13 Aug 2018 11:50:23 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: <93a20bf6-fc53-1446-71b9-0302e74763dc@oracle.com> References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> <0ee9e20c-5400-519a-7875-6dadd7bfa626@oracle.com> <93a20bf6-fc53-1446-71b9-0302e74763dc@oracle.com> Message-ID: Hi Jamil, Thanks for review. One more step close to the integration. On 8/13/2018 11:45 AM, Jamil Nimeh wrote: > Hi Xuelei, > > * SSLSocket.java > o 134: Nit - You can remove the first "both" in this sentence > since you use it later with the input/output stream closure. > Let's use two to emphasize the behaviors: 1. both input and output streams should be closed in each side, and 2. both client and server should perform #1. Thanks, Xuelei > Looks good to me otherwise. > > --Jamil > > On 8/13/2018 11:31 AM, Xue-Lei Fan wrote: >> One more update: >> http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/ >> >> It is desired to make a note in SSLSocket and SSLEngine specification, >> so that users have a good sense that an application should close the >> input and output stream always. >> >> Updated for SSLEngine.java and SSLSocket.java only.? No changes in >> other files. >> >> Please let me know your concerns by the end of today. >> >> Thanks, >> Xuelei >> >> On 8/10/2018 4:02 PM, Jamil Nimeh wrote: >>> I'm good with the changes. >>> >>> --Jamil >>> >>> On 8/7/2018 5:24 PM, Xuelei Fan wrote: >>>> Hi Jamil, >>>> >>>> Thanks for comments.? Here is the updated webrev: >>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/ >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/7/2018 3:12 PM, Jamil Nimeh wrote: >>>>> Hi Xuelei, mostly small stuff: >>>>> >>>>> ? * SSLEngineImpl.java >>>>> ????? o 717: Nit, inbout --> inbound >>>>> ? * SSLEngineOutputRecord.java >>>>> ????? o 162, 169: Nit, applicatoin --> application >>>>> ????? o Same section: It looks like the "if" and "else if" clauses >>>>> take >>>>> ??????? the same actions with the same message.? Maybe just do "if >>>>> ??????? (isClosed())" ?? Or were you planning to have different >>>>> messages >>>>> ??????? here? >>>>> ? * SSLSocketOutputRecord.java >>>>> ????? o 58, 97, 204: Typo,? closedd --> closed >>>>> ? * TLSEngineClosureTest.java >>>>> ????? o 2: Copyright date fix >>>>> ????? o 26: If this is a new test should the bug ID be different than >>>>> ??????? 8085979? >>>>> >>>>> --Jamil >>>>> >>>>> >>>>> On 08/07/2018 07:46 AM, Xuelei Fan wrote: >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ >>>>>> >>>>>> Thanks for a find of Tim Brooks, that the SSLEngine >>>>>> inbound/outbound status is incorrect if closing during handshake. >>>>>> The above webrev is trying to fix the problems. See more in the >>>>>> OpenJDK thread: >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html >>>>>> >>>>>> >>>>>> Please let me know your concerns before this Wednesday. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 8/3/2018 1:55 PM, Xuelei Fan wrote: >>>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >>>>>>> >>>>>>> In webrev.01, the socket close may be blocked by super class >>>>>>> close synchronization.? Updated the SSLSocketImpl.java to use >>>>>>> handshake only lock in the startHandshake() implementation. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>>>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>>>>>>> >>>>>>>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>>>>>>> renegotiation fails if Java client allows TLSv1.3". >>>>>>>> SSLHandshake.java is updated to use negotiated version so that >>>>>>>> TLS 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>>>>>>> >>>>>>>>> Please let me know your concerns by the end of August 1st, 2018. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review the update for the TLS 1.3 half-close and >>>>>>>>>> synchronization implementation: >>>>>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>>>>>>> >>>>>>>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the >>>>>>>>>> close_notify is use to close the local write side and peer >>>>>>>>>> read side only. After the close_notify get handles, the local >>>>>>>>>> read side and peer write side may still be open. >>>>>>>>>> >>>>>>>>>> In this update, if an application calls >>>>>>>>>> SSLEngine.closeInbound/Outbound() or >>>>>>>>>> SSLSocket.shutdownInput/Output(), half-close will be used. >>>>>>>>>> For compatibility, if SSLSocket.close() get called, a duplex >>>>>>>>>> close will be tried.? In order to support duplex close, JDK >>>>>>>>>> will use the user_canceled warning alert even the handshake >>>>>>>>>> complete. >>>>>>>>>> >>>>>>>>>> In practice, an application may only close outbound even it is >>>>>>>>>> intended to close the inbound as well, or close the connection >>>>>>>>>> completely.? It works for TLS 1.2 and prior versions.? But no >>>>>>>>>> more for TLS 1.3 because of the close_notify behavior change >>>>>>>>>> in the TLS 1.3 specification.? The application may be hung and >>>>>>>>>> dead-waiting for read/close.? It could be solved by closing >>>>>>>>>> the inbound explicitly. In order to mitigate the impact, a new >>>>>>>>>> System Property is introduced, >>>>>>>>>> "jdk.tls.acknowledgeCloseNotify" if source code update is not >>>>>>>>>> available. ??If the System Property is set to "true", if >>>>>>>>>> receiving the close_notify, a close_notify alert will be >>>>>>>>>> responded.? It is a countermeasure of the TLS 1.3 half-close >>>>>>>>>> issues. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> >>> > From sean.mullan at oracle.com Mon Aug 13 19:11:28 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Aug 2018 15:11:28 -0400 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> Message-ID: <45eb8bd6-21d4-8f3e-be55-46fbc9ac5cc1@oracle.com> I think this should be an enhancement, and not a bug. Is this mainly for a performance improvement? Also, this change puts more of a dependency on sun.security.action which I think we want to avoid, as it would be nice to eventually stop exporting sun.security.action so as to minimize the exports from java.base to the java.security.jgss module. You can double-check with Mandy or Alan on whether my line of thinking is correct on that. Thanks, Sean On 8/13/18 6:24 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ > > This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". > > I've already introduced a new GetBooleanAction::privilegedGetProperty method. > > Noreg-cleanup. > > Thanks > Max > > From xuelei.fan at oracle.com Mon Aug 13 19:24:20 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 13 Aug 2018 12:24:20 -0700 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <23A708B4-8BF0-4B0B-8A7F-6628A444B2A6@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> <846ED189-408D-4B76-BBE4-096D3AD4671C@oracle.com> <23A708B4-8BF0-4B0B-8A7F-6628A444B2A6@oracle.com> Message-ID: <0f620419-4f5d-19d0-e3a6-d49f187b4788@oracle.com> It's nice to fix them if you'd like to. Thanks, Xuelei On 8/13/2018 8:36 AM, Weijun Wang wrote: > And several AccessController.doPrivileged(new GetBooleanAction()) calls. > > If you'd like me to fix them as well, I can change the bug synopsis a little. > > Thanks > Max > > >> On Aug 13, 2018, at 11:33 PM, Weijun Wang wrote: >> >> >> >>> On Aug 13, 2018, at 10:00 PM, Xue-Lei Fan wrote: >>> >>> Looks fine to me. >>> >>> Did you notice other places that might need similar update as well in security components? >> >> One "new GetPropertyAction()" at >> >> String property = AccessController.doPrivileged( >> new GetPropertyAction("jdk.tls.namedGroups")); >> >> But I haven't checked for doPrivileged(()->System.getProperty()) calls. >> >> Thanks >> Max >> >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 8/13/2018 3:24 AM, Weijun Wang wrote: >>>> Please take a review at >>>> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >>>> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >>>> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >>>> Noreg-cleanup. >>>> Thanks >>>> Max >> > From sean.mullan at oracle.com Mon Aug 13 19:42:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Aug 2018 15:42:06 -0400 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com> <14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> <650ee21d-ec31-0ee0-ab2a-cf4fed2a21d4@oracle.com> <17372eb4-9006-2150-547d-87dcbbb90a2c@oracle.com> Message-ID: <7a1961a6-3ffb-59f2-7775-d5a76b64ba5d@oracle.com> On 8/10/18 3:49 PM, Anthony Scarpino wrote: >> On 8/9/2018 4:25 AM, Sean Mullan wrote: >>> On 8/8/18 5:29 PM, Xuelei Fan wrote: >>>> The "Default" algorithm defined in the SunJSSE provider is for TLS >>>> protocols. >>> >>> What if I set DTLS to be the default, though? Ex: >>> >>> ???? SSLContext.setDefault(SSLContext.getInstance("DTLS")); >>> >> Good point!? Maybe, we also need to update the >> SSLSocketFactory/SSLServerSocketFactory.getDefault() to return >> inoperative factory. > > I'm not sure the code path you're looking as the oneI see seems pretty > obscure. > > Are you two talking about where SSL[Server]SocketFactory.getDefault() > uses a ssl.SocketFactory.provider property set to SunJSSE?? If so, can > see that as a code review comment, but it seems very obscure for the CSR. Here's the code I would use: SSLContext.setDefault(SSLContext.getInstance("DTLS")); ServerSocketFactory fac = SSLServerSocketFactory.getDefault(); If I read the spec correctly, fac should be an "inoperative factory". --Sean From sean.mullan at oracle.com Mon Aug 13 19:44:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Aug 2018 15:44:06 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <4c6b969405364fc394459e8cd1789842@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <4c6b969405364fc394459e8cd1789842@sap.com> Message-ID: <2dcec1bd-a08b-67b3-70bd-2686fede52ce@oracle.com> On 8/13/18 11:18 AM, Baesken, Matthias wrote: >> As Chris and Alan mentioned, you should move the parsing of the property >> to a more general location so it can be used by other code that uses >> this property. > Hi Sean, Thanks for the input and comments . > Could we do the moving of the property parsing do in a followup CR, I would prefer this . I think it should be done as part of this issue. It is too late to get this into JDK 11, so I think it is better to take the time now to do the code restructuring. Thanks, Sean From bradford.wetmore at oracle.com Mon Aug 13 21:12:47 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 13 Aug 2018 14:12:47 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> <6018a034-598d-8cab-4b33-66335fb39746@oracle.com> Message-ID: <0c80752c-0c2e-a4ac-7b5b-e2f29038286c@oracle.com> An update. 1. OK vs. BUFFER_UNDERFLOW may still be an issue. It's not a big one, but potentially confusing as to when you will get either. 2. I thought I saw this in the non-TLSv1.3 contexts also, but I think I must have been reverted my test case back to "TLS", which uses the TLS1.3 1/2 close. I can't get it to duplicate in TLSv1.2/1.1/1 today. Never mind. Brad On 8/10/2018 6:14 PM, Bradford Wetmore wrote: > > > On 8/9/2018 5:57 PM, Xuelei Fan wrote: >> Thank you, Tim!?? Please feel free to submit bugs and comments. > > I went through a standard SSLEngineTemplate handshake/data/close with a > fine-tooth comb (debugger), and found two bugs based on your -04 patch. > > 1.? Things may have changed since the original SSLEngine implementation, > but unwrap() was supposed to return a BUFFER_UNDERFLOW if there is not > enough (or any) inbound data to make a packet.? I'm seeing a mix of OK > and BUFFER_UNDERFLOW.? I haven't determined the pattern, but you should > be able to run my test (attached) and see pretty quickly. > > 2.?? I haven't not had the cycles to follow the earlier discussion, so > this may be a duplicate of something already discussed, but I got myself > into an endless loop because the closes weren't happening as expected. > > In the attached file, after the handshaking and data exchange, close > just one of the SSLEngines outbound side.? I'll use client for this > example, but same error with server side: > > // clientEngine.closeOutbound(); > clientEngine.getHandshakeStatus() == NEED_WRAP > client.isInboundDone(): false > client.isOutboundDone(): false > > // client.wrap() sends the Close Notify (CN). > client wrap: CLOSED/NEED_UNWRAP, 0/24 bytes > clientEngine.getHandshakeStatus() == NEED_UNWRAP > client.isInboundDone(): false > client.isOutboundDone(): true > > // server.unwrap() parses the CN, and closes the inbound side. > server unwrap: CLOSED/NEED_WRAP, 24/0 bytes > clientEngine.getHandshakeStatus() == NEED_WRAP > server.isInboundDone(): true > server.isOutboundDone(): false > > So far so good. > > // server.wrap() needs to send the corresponding close_notify. > server wrap: OK/NEED_WRAP, 0/0 bytes > clientEngine.getHandshakeStatus() == NEED_WRAP > server.isInboundDone(): true > server.isOutboundDone(): false > > Whoops, it didn't happen.? No outbound data was generated.? State is > still in NEED_WRAP.? I just let the app run, it never closes because no > CN is generated on the server side. > > Run the attached file for full details. > > Thanks, > > Brad > >> Xuelei >> >> On 8/9/2018 4:23 PM, Tim Brooks wrote: >>> Hi?Xuelei, >>> >>> My test passed using that patch. I?ll continue to explore over the >>> next few days. But that patch resolves the main issues that I had >>> encountered. >>> >>> Thanks, >>> >>> - Tim >>> >>>> On Aug 7, 2018, at 8:54 AM, Xuelei Fan >>> > wrote: >>>> >>>> Xuelei >>> From xuelei.fan at oracle.com Mon Aug 13 21:32:30 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 13 Aug 2018 14:32:30 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <0c80752c-0c2e-a4ac-7b5b-e2f29038286c@oracle.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> <6018a034-598d-8cab-4b33-66335fb39746@oracle.com> <0c80752c-0c2e-a4ac-7b5b-e2f29038286c@oracle.com> Message-ID: <6977768d-bd2b-19a1-43a6-cf575a566297@oracle.com> On 8/13/2018 2:12 PM, Bradford Wetmore wrote: > An update. > > 1.? OK vs. BUFFER_UNDERFLOW may still be an issue.? It's not a big one, > but potentially confusing as to when you will get either. > Did you figure out when OK is returned, and when BUFFER_UNDERFLOW is returned? I think we have an improvement that if the buffer is not used currently, the BUFFER_UNDERFLOW may not be returned. So OK may be used in some circumstances. Xuelei > 2.? I thought I saw this in the non-TLSv1.3 contexts also, but I think I > must have been reverted my test case back to "TLS", which uses the > TLS1.3 1/2 close.? I can't get it to duplicate in TLSv1.2/1.1/1 today. > Never mind. > > Brad > > > > On 8/10/2018 6:14 PM, Bradford Wetmore wrote: >> >> >> On 8/9/2018 5:57 PM, Xuelei Fan wrote: >>> Thank you, Tim!?? Please feel free to submit bugs and comments. >> >> I went through a standard SSLEngineTemplate handshake/data/close with >> a fine-tooth comb (debugger), and found two bugs based on your -04 patch. >> >> 1.? Things may have changed since the original SSLEngine >> implementation, but unwrap() was supposed to return a BUFFER_UNDERFLOW >> if there is not enough (or any) inbound data to make a packet.? I'm >> seeing a mix of OK and BUFFER_UNDERFLOW.? I haven't determined the >> pattern, but you should be able to run my test (attached) and see >> pretty quickly. >> >> 2.?? I haven't not had the cycles to follow the earlier discussion, so >> this may be a duplicate of something already discussed, but I got >> myself into an endless loop because the closes weren't happening as >> expected. >> >> In the attached file, after the handshaking and data exchange, close >> just one of the SSLEngines outbound side.? I'll use client for this >> example, but same error with server side: >> >> // clientEngine.closeOutbound(); >> clientEngine.getHandshakeStatus() == NEED_WRAP >> client.isInboundDone(): false >> client.isOutboundDone(): false >> >> // client.wrap() sends the Close Notify (CN). >> client wrap: CLOSED/NEED_UNWRAP, 0/24 bytes >> clientEngine.getHandshakeStatus() == NEED_UNWRAP >> client.isInboundDone(): false >> client.isOutboundDone(): true >> >> // server.unwrap() parses the CN, and closes the inbound side. >> server unwrap: CLOSED/NEED_WRAP, 24/0 bytes >> clientEngine.getHandshakeStatus() == NEED_WRAP >> server.isInboundDone(): true >> server.isOutboundDone(): false >> >> So far so good. >> >> // server.wrap() needs to send the corresponding close_notify. >> server wrap: OK/NEED_WRAP, 0/0 bytes >> clientEngine.getHandshakeStatus() == NEED_WRAP >> server.isInboundDone(): true >> server.isOutboundDone(): false >> >> Whoops, it didn't happen.? No outbound data was generated.? State is >> still in NEED_WRAP.? I just let the app run, it never closes because >> no CN is generated on the server side. >> >> Run the attached file for full details. >> >> Thanks, >> >> Brad >> >>> Xuelei >>> >>> On 8/9/2018 4:23 PM, Tim Brooks wrote: >>>> Hi?Xuelei, >>>> >>>> My test passed using that patch. I?ll continue to explore over the >>>> next few days. But that patch resolves the main issues that I had >>>> encountered. >>>> >>>> Thanks, >>>> >>>> - Tim >>>> >>>>> On Aug 7, 2018, at 8:54 AM, Xuelei Fan >>>> > wrote: >>>>> >>>>> Xuelei >>>> From bradford.wetmore at oracle.com Mon Aug 13 22:15:28 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 13 Aug 2018 15:15:28 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <6977768d-bd2b-19a1-43a6-cf575a566297@oracle.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> <6018a034-598d-8cab-4b33-66335fb39746@oracle.com> <0c80752c-0c2e-a4ac-7b5b-e2f29038286c@oracle.com> <6977768d-bd2b-19a1-43a6-cf575a566297@oracle.com> Message-ID: <4604ac89-4921-2403-7fcc-79e87693815c@oracle.com> No, I haven't had the time to determine when OK vs BU. Brad On 8/13/2018 2:32 PM, Xue-Lei Fan wrote: > On 8/13/2018 2:12 PM, Bradford Wetmore wrote: >> An update. >> >> 1.? OK vs. BUFFER_UNDERFLOW may still be an issue.? It's not a big >> one, but potentially confusing as to when you will get either. >> > Did you figure out when OK is returned, and when BUFFER_UNDERFLOW is > returned?? I think we have an improvement that if the buffer is not used > currently, the BUFFER_UNDERFLOW may not be returned.? So OK may be used > in some circumstances. > > Xuelei > >> 2.? I thought I saw this in the non-TLSv1.3 contexts also, but I think >> I must have been reverted my test case back to "TLS", which uses the >> TLS1.3 1/2 close.? I can't get it to duplicate in TLSv1.2/1.1/1 today. >> Never mind. >> >> Brad >> >> >> >> On 8/10/2018 6:14 PM, Bradford Wetmore wrote: >>> >>> >>> On 8/9/2018 5:57 PM, Xuelei Fan wrote: >>>> Thank you, Tim!?? Please feel free to submit bugs and comments. >>> >>> I went through a standard SSLEngineTemplate handshake/data/close with >>> a fine-tooth comb (debugger), and found two bugs based on your -04 >>> patch. >>> >>> 1.? Things may have changed since the original SSLEngine >>> implementation, but unwrap() was supposed to return a >>> BUFFER_UNDERFLOW if there is not enough (or any) inbound data to make >>> a packet.? I'm seeing a mix of OK and BUFFER_UNDERFLOW.? I haven't >>> determined the pattern, but you should be able to run my test >>> (attached) and see pretty quickly. >>> >>> 2.?? I haven't not had the cycles to follow the earlier discussion, >>> so this may be a duplicate of something already discussed, but I got >>> myself into an endless loop because the closes weren't happening as >>> expected. >>> >>> In the attached file, after the handshaking and data exchange, close >>> just one of the SSLEngines outbound side.? I'll use client for this >>> example, but same error with server side: >>> >>> // clientEngine.closeOutbound(); >>> clientEngine.getHandshakeStatus() == NEED_WRAP >>> client.isInboundDone(): false >>> client.isOutboundDone(): false >>> >>> // client.wrap() sends the Close Notify (CN). >>> client wrap: CLOSED/NEED_UNWRAP, 0/24 bytes >>> clientEngine.getHandshakeStatus() == NEED_UNWRAP >>> client.isInboundDone(): false >>> client.isOutboundDone(): true >>> >>> // server.unwrap() parses the CN, and closes the inbound side. >>> server unwrap: CLOSED/NEED_WRAP, 24/0 bytes >>> clientEngine.getHandshakeStatus() == NEED_WRAP >>> server.isInboundDone(): true >>> server.isOutboundDone(): false >>> >>> So far so good. >>> >>> // server.wrap() needs to send the corresponding close_notify. >>> server wrap: OK/NEED_WRAP, 0/0 bytes >>> clientEngine.getHandshakeStatus() == NEED_WRAP >>> server.isInboundDone(): true >>> server.isOutboundDone(): false >>> >>> Whoops, it didn't happen.? No outbound data was generated.? State is >>> still in NEED_WRAP.? I just let the app run, it never closes because >>> no CN is generated on the server side. >>> >>> Run the attached file for full details. >>> >>> Thanks, >>> >>> Brad >>> >>>> Xuelei >>>> >>>> On 8/9/2018 4:23 PM, Tim Brooks wrote: >>>>> Hi?Xuelei, >>>>> >>>>> My test passed using that patch. I?ll continue to explore over the >>>>> next few days. But that patch resolves the main issues that I had >>>>> encountered. >>>>> >>>>> Thanks, >>>>> >>>>> - Tim >>>>> >>>>>> On Aug 7, 2018, at 8:54 AM, Xuelei Fan >>>>> > wrote: >>>>>> >>>>>> Xuelei >>>>> From bradford.wetmore at oracle.com Mon Aug 13 23:43:29 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 13 Aug 2018 16:43:29 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> <1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> <0ee9e20c-5400-519a-7875-6dadd7bfa626@oracle.com> <93a20bf6-fc53-1446-71b9-0302e74763dc@oracle.com> Message-ID: Hi Xuelei, > Let's use two to emphasize the behaviors: > 1. both input and output streams should be closed in each side, and > 2. both client and server should perform #1. SSLEngine.java -------------- 159: Both sides (i.e. the peer) may not be a SSLEngine: both the client and server applications should close the {@code SSLEngine} by calling {@link SSLEngine#closeInbound} and {@link SSLEngine#closeOutbound} and should send/receive any... -> the application should close the {@code SSLEngine} by calling {@link SSLEngine#closeInbound} and {@link SSLEngine#closeOutbound} and should send/receive any... SSLSocket.java -------------- With all of the ways to close, trying to say anything here is going to get really ugly really fast. SSLSocket.close(), InputStream.close() & OutputStream.close, and now Socket.shutdownInput() & Socket.shutdownOutput(). Even shutdownInput()/shutdownOutput() still throw UnsupportedOperationExceptions in JDK 10 all the way back to 1.4. Can we just leave it at SSLSocket.close() and skip the Input/OutputStream.close() and shutdownInput/Output? Or something like: @apiNote The TLS standard has evolved over the years, especially when it comes to closing Sockets and streams. The most straightforward way to close a connection is for an application to call SSLSocket.close(). Some versions of the standard allow for independently closing the input or output sides of a connection, but may throw Exceptions if certain conditions aren't met. If such a connection state is desired, the output stream should generally be closed before the input stream. Once an {@code SSLSocket} is closed, it is not reusable: a new {@code SSLSocket} must be created. Brad On 8/13/2018 11:50 AM, Xue-Lei Fan wrote: > Hi Jamil, > > Thanks for review.? One more step close to the integration. > > On 8/13/2018 11:45 AM, Jamil Nimeh wrote: >> Hi Xuelei, >> >> ? * SSLSocket.java >> ????? o 134: Nit - You can remove the first "both" in this sentence >> ??????? since you use it later with the input/output stream closure. >> > Let's use two to emphasize the behaviors: > 1. both input and output streams should be closed in each side, and > 2. both client and server should perform #1. > > Thanks, > Xuelei > >> Looks good to me otherwise. >> >> --Jamil >> >> On 8/13/2018 11:31 AM, Xue-Lei Fan wrote: >>> One more update: >>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/ >>> >>> It is desired to make a note in SSLSocket and SSLEngine >>> specification, so that users have a good sense that an application >>> should close the input and output stream always. >>> >>> Updated for SSLEngine.java and SSLSocket.java only.? No changes in >>> other files. >>> >>> Please let me know your concerns by the end of today. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/10/2018 4:02 PM, Jamil Nimeh wrote: >>>> I'm good with the changes. >>>> >>>> --Jamil >>>> >>>> On 8/7/2018 5:24 PM, Xuelei Fan wrote: >>>>> Hi Jamil, >>>>> >>>>> Thanks for comments.? Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/ >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/7/2018 3:12 PM, Jamil Nimeh wrote: >>>>>> Hi Xuelei, mostly small stuff: >>>>>> >>>>>> ? * SSLEngineImpl.java >>>>>> ????? o 717: Nit, inbout --> inbound >>>>>> ? * SSLEngineOutputRecord.java >>>>>> ????? o 162, 169: Nit, applicatoin --> application >>>>>> ????? o Same section: It looks like the "if" and "else if" clauses >>>>>> take >>>>>> ??????? the same actions with the same message.? Maybe just do "if >>>>>> ??????? (isClosed())" ?? Or were you planning to have different >>>>>> messages >>>>>> ??????? here? >>>>>> ? * SSLSocketOutputRecord.java >>>>>> ????? o 58, 97, 204: Typo,? closedd --> closed >>>>>> ? * TLSEngineClosureTest.java >>>>>> ????? o 2: Copyright date fix >>>>>> ????? o 26: If this is a new test should the bug ID be different than >>>>>> ??????? 8085979? >>>>>> >>>>>> --Jamil >>>>>> >>>>>> >>>>>> On 08/07/2018 07:46 AM, Xuelei Fan wrote: >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ >>>>>>> >>>>>>> Thanks for a find of Tim Brooks, that the SSLEngine >>>>>>> inbound/outbound status is incorrect if closing during handshake. >>>>>>> The above webrev is trying to fix the problems. See more in the >>>>>>> OpenJDK thread: >>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html >>>>>>> >>>>>>> >>>>>>> Please let me know your concerns before this Wednesday. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 8/3/2018 1:55 PM, Xuelei Fan wrote: >>>>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >>>>>>>> >>>>>>>> In webrev.01, the socket close may be blocked by super class >>>>>>>> close synchronization.? Updated the SSLSocketImpl.java to use >>>>>>>> handshake only lock in the startHandshake() implementation. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>>>>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>>>>>>>> >>>>>>>>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>>>>>>>> renegotiation fails if Java client allows TLSv1.3". >>>>>>>>> SSLHandshake.java is updated to use negotiated version so that >>>>>>>>> TLS 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>>>>>>>> >>>>>>>>>> Please let me know your concerns by the end of August 1st, 2018. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please review the update for the TLS 1.3 half-close and >>>>>>>>>>> synchronization implementation: >>>>>>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the >>>>>>>>>>> close_notify is use to close the local write side and peer >>>>>>>>>>> read side only. After the close_notify get handles, the local >>>>>>>>>>> read side and peer write side may still be open. >>>>>>>>>>> >>>>>>>>>>> In this update, if an application calls >>>>>>>>>>> SSLEngine.closeInbound/Outbound() or >>>>>>>>>>> SSLSocket.shutdownInput/Output(), half-close will be used. >>>>>>>>>>> For compatibility, if SSLSocket.close() get called, a duplex >>>>>>>>>>> close will be tried.? In order to support duplex close, JDK >>>>>>>>>>> will use the user_canceled warning alert even the handshake >>>>>>>>>>> complete. >>>>>>>>>>> >>>>>>>>>>> In practice, an application may only close outbound even it >>>>>>>>>>> is intended to close the inbound as well, or close the >>>>>>>>>>> connection completely.? It works for TLS 1.2 and prior >>>>>>>>>>> versions.? But no more for TLS 1.3 because of the >>>>>>>>>>> close_notify behavior change in the TLS 1.3 specification. >>>>>>>>>>> The application may be hung and dead-waiting for read/close. >>>>>>>>>>> It could be solved by closing the inbound explicitly. In >>>>>>>>>>> order to mitigate the impact, a new System Property is >>>>>>>>>>> introduced, "jdk.tls.acknowledgeCloseNotify" if source code >>>>>>>>>>> update is not available. ??If the System Property is set to >>>>>>>>>>> "true", if receiving the close_notify, a close_notify alert >>>>>>>>>>> will be responded.? It is a countermeasure of the TLS 1.3 >>>>>>>>>>> half-close issues. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Xuelei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> >>>> >> From xuelei.fan at oracle.com Tue Aug 14 00:14:48 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 13 Aug 2018 17:14:48 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <4604ac89-4921-2403-7fcc-79e87693815c@oracle.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> <1f97169c-a5e9-92fa-b055-9f5254fbf56e@oracle.com> <8ca7202f-f9fa-45e8-2025-085e359c2bbb@oracle.com> <6018a034-598d-8cab-4b33-66335fb39746@oracle.com> <0c80752c-0c2e-a4ac-7b5b-e2f29038286c@oracle.com> <6977768d-bd2b-19a1-43a6-cf575a566297@oracle.com> <4604ac89-4921-2403-7fcc-79e87693815c@oracle.com> Message-ID: <81e3d07c-b21e-f9c4-fe74-68c4a161861b@oracle.com> OK, I will check it. Thanks! Xuelei On 8/13/2018 3:15 PM, Bradford Wetmore wrote: > No, I haven't had the time to determine when OK vs BU. > > Brad > > > On 8/13/2018 2:32 PM, Xue-Lei Fan wrote: >> On 8/13/2018 2:12 PM, Bradford Wetmore wrote: >>> An update. >>> >>> 1.? OK vs. BUFFER_UNDERFLOW may still be an issue.? It's not a big >>> one, but potentially confusing as to when you will get either. >>> >> Did you figure out when OK is returned, and when BUFFER_UNDERFLOW is >> returned?? I think we have an improvement that if the buffer is not >> used currently, the BUFFER_UNDERFLOW may not be returned.? So OK may >> be used in some circumstances. >> >> Xuelei >> >>> 2.? I thought I saw this in the non-TLSv1.3 contexts also, but I >>> think I must have been reverted my test case back to "TLS", which >>> uses the TLS1.3 1/2 close.? I can't get it to duplicate in >>> TLSv1.2/1.1/1 today. Never mind. >>> >>> Brad >>> >>> >>> >>> On 8/10/2018 6:14 PM, Bradford Wetmore wrote: >>>> >>>> >>>> On 8/9/2018 5:57 PM, Xuelei Fan wrote: >>>>> Thank you, Tim!?? Please feel free to submit bugs and comments. >>>> >>>> I went through a standard SSLEngineTemplate handshake/data/close >>>> with a fine-tooth comb (debugger), and found two bugs based on your >>>> -04 patch. >>>> >>>> 1.? Things may have changed since the original SSLEngine >>>> implementation, but unwrap() was supposed to return a >>>> BUFFER_UNDERFLOW if there is not enough (or any) inbound data to >>>> make a packet.? I'm seeing a mix of OK and BUFFER_UNDERFLOW.? I >>>> haven't determined the pattern, but you should be able to run my >>>> test (attached) and see pretty quickly. >>>> >>>> 2.?? I haven't not had the cycles to follow the earlier discussion, >>>> so this may be a duplicate of something already discussed, but I got >>>> myself into an endless loop because the closes weren't happening as >>>> expected. >>>> >>>> In the attached file, after the handshaking and data exchange, close >>>> just one of the SSLEngines outbound side.? I'll use client for this >>>> example, but same error with server side: >>>> >>>> // clientEngine.closeOutbound(); >>>> clientEngine.getHandshakeStatus() == NEED_WRAP >>>> client.isInboundDone(): false >>>> client.isOutboundDone(): false >>>> >>>> // client.wrap() sends the Close Notify (CN). >>>> client wrap: CLOSED/NEED_UNWRAP, 0/24 bytes >>>> clientEngine.getHandshakeStatus() == NEED_UNWRAP >>>> client.isInboundDone(): false >>>> client.isOutboundDone(): true >>>> >>>> // server.unwrap() parses the CN, and closes the inbound side. >>>> server unwrap: CLOSED/NEED_WRAP, 24/0 bytes >>>> clientEngine.getHandshakeStatus() == NEED_WRAP >>>> server.isInboundDone(): true >>>> server.isOutboundDone(): false >>>> >>>> So far so good. >>>> >>>> // server.wrap() needs to send the corresponding close_notify. >>>> server wrap: OK/NEED_WRAP, 0/0 bytes >>>> clientEngine.getHandshakeStatus() == NEED_WRAP >>>> server.isInboundDone(): true >>>> server.isOutboundDone(): false >>>> >>>> Whoops, it didn't happen.? No outbound data was generated.? State is >>>> still in NEED_WRAP.? I just let the app run, it never closes because >>>> no CN is generated on the server side. >>>> >>>> Run the attached file for full details. >>>> >>>> Thanks, >>>> >>>> Brad >>>> >>>>> Xuelei >>>>> >>>>> On 8/9/2018 4:23 PM, Tim Brooks wrote: >>>>>> Hi?Xuelei, >>>>>> >>>>>> My test passed using that patch. I?ll continue to explore over the >>>>>> next few days. But that patch resolves the main issues that I had >>>>>> encountered. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> - Tim >>>>>> >>>>>>> On Aug 7, 2018, at 8:54 AM, Xuelei Fan >>>>>> > wrote: >>>>>>> >>>>>>> Xuelei >>>>>> From weijun.wang at oracle.com Tue Aug 14 03:17:37 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2018 11:17:37 +0800 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> Message-ID: Good suggestion. I'll update my change. Thanks Max > On Aug 13, 2018, at 9:53 PM, Roger Riggs wrote: > > Hi Max, > > It might be useful to be a bit more consistent about putting the property name on > the same line as the privilegedGetProperty. > It would help finding/grepping for the targets of privileged actions. > For example, Grep would not find the one in sun/security/krb5/Config.java:824-825 or > sun/security/jgss/ProviderList.java:109 (due to the static field definition). > > Just a thought.. > > Otherwise looks fine. > > Roger > > > > On 8/13/18 6:24 AM, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >> >> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >> >> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >> >> Noreg-cleanup. >> >> Thanks >> Max >> >> > From weijun.wang at oracle.com Tue Aug 14 04:29:02 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2018 12:29:02 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com> Message-ID: Sorry for the late reply. > On Aug 7, 2018, at 10:57 PM, Roger Riggs wrote: > > Hi Max, > > It may be useful to include in the descriptions a reminder that if no ObjectInputFilter > is supplied the global filter is used. Details in ObjectInputStream. The new getObject() methods with an ObjectInputFilter does not allow it to be null, so it looks strange to mention this in the method spec. I'm thinking about these changes in the example part of the class spec: * Signature.getInstance(algorithm, provider); * if (so.verify(publickey, verificationEngine)) * try { - * Object myobj = so.getObject(); + * ObjectInputFilter myfilter = ...; + * Object myobj = so.getObject(myfilter); * } catch (java.lang.ClassNotFoundException e) {}; * } * + * In this example, the {@link ObjectInputFilter} object is used during + * deserialization to check the contents of the stream. If {@link #getObject()} + * is called, the {@link ObjectInputFilter.Config#getSerialFilter() + * initial process-wide filter} is used. I copied the words from ObjectInputStream::getObjectInputFilter. Is this a formal name of the "global filter"? > > Typically, the @throws clauses that are not full sentences do not include a final period "." > For consistency with the existing javadoc, omit the "." > For example, SealedObject.java:191, 239, 240, 330 > SignedObject.java: 128, 130, 229, 252, 253 > > While you are editing SealedObject.java: 143-145, please indent the continuation lines of @throws. OK. > > Are there any caveats on what the serial filter needs to allow when used in SealedObject or SignedObject? I'll think about this. In reality, a user first get a SignedObject from an ObjectInputStream and then call getObject() to read it. I should probably point out a user can check the content of SignedObject themselves while retrieving the SignedObject itself and the new method only takes care about deserializing the internal object only. Thanks Max > > Thanks, Roger > > > On 8/7/18 2:31 AM, Weijun Wang wrote: >> Please review the code change at >> >> webrev: http://cr.openjdk.java.net/~weijun/8193859/webrev.00/ >> >> where >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8193859 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8193887 >> >> Thanks >> Max >> >> > From weijun.wang at oracle.com Tue Aug 14 05:04:02 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2018 13:04:02 +0800 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <45eb8bd6-21d4-8f3e-be55-46fbc9ac5cc1@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> <45eb8bd6-21d4-8f3e-be55-46fbc9ac5cc1@oracle.com> Message-ID: <23BE44EB-D6D1-49BC-96A0-20DFDFFF7AEA@oracle.com> > On Aug 14, 2018, at 3:11 AM, Sean Mullan wrote: > > I think this should be an enhancement, and not a bug. Is this mainly for a performance improvement? Yes it's an enhancement. Performance can be gained. Also, the privilegedGetProperty() method is already called in a lot of places. Using it everywhere makes the code looks consistent and simpler. > > Also, this change puts more of a dependency on sun.security.action which I think we want to avoid, as it would be nice to eventually stop exporting sun.security.action so as to minimize the exports from java.base to the java.security.jgss module. You can double-check with Mandy or Alan on whether my line of thinking is correct on that. I've talked with Mandy. She thinks it's OK now to continue using the sun.security.action since java.security.jgss is not upgradeable and there is no security concern. Also, I think using the same method now would be helpful if we want to switch to another method implemented inside the module some time in the future. Thanks Max > > Thanks, > Sean > > On 8/13/18 6:24 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >> Noreg-cleanup. >> Thanks >> Max From weijun.wang at oracle.com Tue Aug 14 05:33:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2018 13:33:40 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com> Message-ID: Here is the change for both classes. I use "original object" so a caller would know what the filter should expect. diff --git a/src/java.base/share/classes/java/security/SignedObject.java b/src/java.base/share/classes/java/security/SignedObject.java --- a/src/java.base/share/classes/java/security/SignedObject.java +++ b/src/java.base/share/classes/java/security/SignedObject.java @@ -59,10 +59,16 @@ * Signature.getInstance(algorithm, provider); * if (so.verify(publickey, verificationEngine)) * try { - * Object myobj = so.getObject(); + * ObjectInputFilter myfilter = ...; + * Object myobj = so.getObject(myfilter); * } catch (java.lang.ClassNotFoundException e) {}; * } * + * In this example, an {@link ObjectInputFilter} object is used during + * deserialization of the original object. If {@link #getObject()} is + * called, the {@link ObjectInputFilter.Config#getSerialFilter() + * initial process-wide filter} is used instead. + * *

Several points are worth noting. First, there is no need to * initialize the signing or verification engine, as it will be * re-initialized inside the constructor and the {@code verify} diff --git a/src/java.base/share/classes/javax/crypto/SealedObject.java b/src/java.base/share/classes/javax/crypto/SealedObject.java --- a/src/java.base/share/classes/javax/crypto/SealedObject.java +++ b/src/java.base/share/classes/javax/crypto/SealedObject.java @@ -86,6 +86,12 @@ * * * + * Both methods have overloaded forms that accept an {@link ObjectInputFilter} + * parameter, which will be used during deserialization of the original object. + * If a {@code getObject} method without a {@code ObjectInputFilter} parameter + * is called, the {@link ObjectInputFilter.Config#getSerialFilter() + * initial process-wide filter} is used instead. This last paragraph is after the

wrote: > >> On Aug 7, 2018, at 10:57 PM, Roger Riggs wrote: >> >> It may be useful to include in the descriptions a reminder that if no ObjectInputFilter >> is supplied the global filter is used. Details in ObjectInputStream. > > The new getObject() methods with an ObjectInputFilter does not allow it to be null, so it looks strange to mention this in the method spec. From weijun.wang at oracle.com Tue Aug 14 06:39:24 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2018 14:39:24 +0800 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <0f620419-4f5d-19d0-e3a6-d49f187b4788@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> <846ED189-408D-4B76-BBE4-096D3AD4671C@oracle.com> <23A708B4-8BF0-4B0B-8A7F-6628A444B2A6@oracle.com> <0f620419-4f5d-19d0-e3a6-d49f187b4788@oracle.com> Message-ID: <509F427C-D939-459F-A953-CC6BC47EEE36@oracle.com> Updated webrev at http://cr.openjdk.java.net/~weijun/8209416/webrev.01/ You can look at [1] to see what has changed. Mostly it's a case in other security libs. I also change the calling style to put property name in the same line as the getProperty() call, and inline the name if it was defined as a constant. You might want to double check on the change in TlsRsaPremasterSecretParameterSpec.java. I think I got it right. Thanks Max [1] http://cr.openjdk.java.net/~weijun/8209416/webrev.01/interdiff.patch.html > On Aug 14, 2018, at 3:24 AM, Xue-Lei Fan wrote: > > It's nice to fix them if you'd like to. > > Thanks, > Xuelei > > On 8/13/2018 8:36 AM, Weijun Wang wrote: >> And several AccessController.doPrivileged(new GetBooleanAction()) calls. >> If you'd like me to fix them as well, I can change the bug synopsis a little. >> Thanks >> Max >>> On Aug 13, 2018, at 11:33 PM, Weijun Wang wrote: >>> >>> >>> >>>> On Aug 13, 2018, at 10:00 PM, Xue-Lei Fan wrote: >>>> >>>> Looks fine to me. >>>> >>>> Did you notice other places that might need similar update as well in security components? >>> >>> One "new GetPropertyAction()" at >>> >>> String property = AccessController.doPrivileged( >>> new GetPropertyAction("jdk.tls.namedGroups")); >>> >>> But I haven't checked for doPrivileged(()->System.getProperty()) calls. >>> >>> Thanks >>> Max >>> >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 8/13/2018 3:24 AM, Weijun Wang wrote: >>>>> Please take a review at >>>>> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >>>>> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >>>>> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >>>>> Noreg-cleanup. >>>>> Thanks >>>>> Max >>> From sha.jiang at oracle.com Tue Aug 14 11:40:30 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 14 Aug 2018 19:40:30 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> Message-ID: <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> Hi Max, Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. I added a block to README for clarifying something on getting NSS libraries. Best regards, John Jiang On 2018/8/13 16:48, Weijun Wang wrote: > Sorry, more questions: > >> On Aug 13, 2018, at 3:36 PM,sha.jiang at oracle.com wrote: >> >>> Is there an artifact server available on the open internet? >> It's transparent to me. @Artifact tool delegates the downloading. > Have you tried running the test outside Oracle? > > Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) > > While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. > > Thanks > Max > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Aug 14 13:25:31 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 14 Aug 2018 06:25:31 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com>

<1eb8223a-f355-3778-d355-f217f28cdb75@oracle.com> <6e608428-ea3e-9d89-e847-e321ed76b0e9@oracle.com> <57799762-f8b5-dadd-f8b8-23ff7ca52d95@oracle.com> <0ee9e20c-5400-519a-7875-6dadd7bfa626@oracle.com> <93a20bf6-fc53-1446-71b9-0302e74763dc@oracle.com>

Message-ID: <38abc450-b7c3-bd11-699e-04a0bce45bcc@oracle.com> Hi Brad, Good points! Here is the updated webrev: http://cr.openjdk.java.net/~xuelei/8207009/webrev.06/ Please let me know if you have more comments by 11:30AM today. Thanks, Xuelei On 8/13/2018 4:43 PM, Bradford Wetmore wrote: > Hi Xuelei, > > > Let's use two to emphasize the behaviors: > > 1. both input and output streams should be closed in each side, and > > 2. both client and server should perform #1. > > SSLEngine.java > -------------- > 159:? Both sides (i.e. the peer) may not be a SSLEngine: > > both the client and server applications should close the {@code > SSLEngine} by calling {@link SSLEngine#closeInbound} and {@link > SSLEngine#closeOutbound} and should send/receive any... > -> > the application should close the {@code SSLEngine} by calling {@link > SSLEngine#closeInbound} and {@link SSLEngine#closeOutbound} and should > send/receive any... > > > SSLSocket.java > -------------- > With all of the ways to close, trying to say anything here is going to > get really ugly really fast.? SSLSocket.close(), InputStream.close() & > OutputStream.close, and now Socket.shutdownInput() & > Socket.shutdownOutput().? Even shutdownInput()/shutdownOutput() still > throw UnsupportedOperationExceptions in JDK 10 all the way back to 1.4. > > Can we just leave it at SSLSocket.close() and skip the > Input/OutputStream.close() and shutdownInput/Output?? Or something like: > > @apiNote > The TLS standard has evolved over the years, especially when it comes to > closing Sockets and streams.? The most straightforward way to close a > connection is for an application to call SSLSocket.close().? Some > versions of the standard allow for independently closing the input or > output sides of a connection, but may throw Exceptions if certain > conditions aren't met.? If such a connection state is desired, the > output stream should generally be closed before the input stream. > > Once an {@code SSLSocket} is closed, it is not reusable: a new > {@code SSLSocket} must be created. > > Brad > > > > > On 8/13/2018 11:50 AM, Xue-Lei Fan wrote: >> Hi Jamil, >> >> Thanks for review.? One more step close to the integration. >> >> On 8/13/2018 11:45 AM, Jamil Nimeh wrote: >>> Hi Xuelei, >>> >>> ? * SSLSocket.java >>> ????? o 134: Nit - You can remove the first "both" in this sentence >>> ??????? since you use it later with the input/output stream closure. >>> >> Let's use two to emphasize the behaviors: >> 1. both input and output streams should be closed in each side, and >> 2. both client and server should perform #1. >> >> Thanks, >> Xuelei >> >>> Looks good to me otherwise. >>> >>> --Jamil >>> >>> On 8/13/2018 11:31 AM, Xue-Lei Fan wrote: >>>> One more update: >>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/ >>>> >>>> It is desired to make a note in SSLSocket and SSLEngine >>>> specification, so that users have a good sense that an application >>>> should close the input and output stream always. >>>> >>>> Updated for SSLEngine.java and SSLSocket.java only.? No changes in >>>> other files. >>>> >>>> Please let me know your concerns by the end of today. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/10/2018 4:02 PM, Jamil Nimeh wrote: >>>>> I'm good with the changes. >>>>> >>>>> --Jamil >>>>> >>>>> On 8/7/2018 5:24 PM, Xuelei Fan wrote: >>>>>> Hi Jamil, >>>>>> >>>>>> Thanks for comments.? Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.04/ >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 8/7/2018 3:12 PM, Jamil Nimeh wrote: >>>>>>> Hi Xuelei, mostly small stuff: >>>>>>> >>>>>>> ? * SSLEngineImpl.java >>>>>>> ????? o 717: Nit, inbout --> inbound >>>>>>> ? * SSLEngineOutputRecord.java >>>>>>> ????? o 162, 169: Nit, applicatoin --> application >>>>>>> ????? o Same section: It looks like the "if" and "else if" >>>>>>> clauses take >>>>>>> ??????? the same actions with the same message.? Maybe just do "if >>>>>>> ??????? (isClosed())" ?? Or were you planning to have different >>>>>>> messages >>>>>>> ??????? here? >>>>>>> ? * SSLSocketOutputRecord.java >>>>>>> ????? o 58, 97, 204: Typo,? closedd --> closed >>>>>>> ? * TLSEngineClosureTest.java >>>>>>> ????? o 2: Copyright date fix >>>>>>> ????? o 26: If this is a new test should the bug ID be different >>>>>>> than >>>>>>> ??????? 8085979? >>>>>>> >>>>>>> --Jamil >>>>>>> >>>>>>> >>>>>>> On 08/07/2018 07:46 AM, Xuelei Fan wrote: >>>>>>>> New webrev: >>>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.03/ >>>>>>>> >>>>>>>> Thanks for a find of Tim Brooks, that the SSLEngine >>>>>>>> inbound/outbound status is incorrect if closing during >>>>>>>> handshake. The above webrev is trying to fix the problems. See >>>>>>>> more in the OpenJDK thread: >>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html >>>>>>>> >>>>>>>> >>>>>>>> Please let me know your concerns before this Wednesday. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 8/3/2018 1:55 PM, Xuelei Fan wrote: >>>>>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ >>>>>>>>> >>>>>>>>> In webrev.01, the socket close may be blocked by super class >>>>>>>>> close synchronization.? Updated the SSLSocketImpl.java to use >>>>>>>>> handshake only lock in the startHandshake() implementation. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 8/1/2018 7:27 PM, Xuelei Fan wrote: >>>>>>>>>> Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ >>>>>>>>>> >>>>>>>>>> Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 >>>>>>>>>> renegotiation fails if Java client allows TLSv1.3". >>>>>>>>>> SSLHandshake.java is updated to use negotiated version so that >>>>>>>>>> TLS 1.2 HelloRequest is acceptable in TLS 1.3 client side. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> On 7/30/2018 10:24 AM, Xuelei Fan wrote: >>>>>>>>>>> >>>>>>>>>>> Please let me know your concerns by the end of August 1st, 2018. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Xuelei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/30/2018 9:59 AM, Xuelei Fan wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Please review the update for the TLS 1.3 half-close and >>>>>>>>>>>> synchronization implementation: >>>>>>>>>>>> http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Unlike TLS 1.2 and prior versions, for TLS 1.3, the >>>>>>>>>>>> close_notify is use to close the local write side and peer >>>>>>>>>>>> read side only. After the close_notify get handles, the >>>>>>>>>>>> local read side and peer write side may still be open. >>>>>>>>>>>> >>>>>>>>>>>> In this update, if an application calls >>>>>>>>>>>> SSLEngine.closeInbound/Outbound() or >>>>>>>>>>>> SSLSocket.shutdownInput/Output(), half-close will be used. >>>>>>>>>>>> For compatibility, if SSLSocket.close() get called, a duplex >>>>>>>>>>>> close will be tried.? In order to support duplex close, JDK >>>>>>>>>>>> will use the user_canceled warning alert even the handshake >>>>>>>>>>>> complete. >>>>>>>>>>>> >>>>>>>>>>>> In practice, an application may only close outbound even it >>>>>>>>>>>> is intended to close the inbound as well, or close the >>>>>>>>>>>> connection completely.? It works for TLS 1.2 and prior >>>>>>>>>>>> versions.? But no more for TLS 1.3 because of the >>>>>>>>>>>> close_notify behavior change in the TLS 1.3 specification. >>>>>>>>>>>> The application may be hung and dead-waiting for read/close. >>>>>>>>>>>> It could be solved by closing the inbound explicitly. In >>>>>>>>>>>> order to mitigate the impact, a new System Property is >>>>>>>>>>>> introduced, "jdk.tls.acknowledgeCloseNotify" if source code >>>>>>>>>>>> update is not available. ??If the System Property is set to >>>>>>>>>>>> "true", if receiving the close_notify, a close_notify alert >>>>>>>>>>>> will be responded.? It is a countermeasure of the TLS 1.3 >>>>>>>>>>>> half-close issues. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Xuelei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>> >>> From xuelei.fan at oracle.com Tue Aug 14 13:32:21 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 14 Aug 2018 06:32:21 -0700 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <509F427C-D939-459F-A953-CC6BC47EEE36@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> <846ED189-408D-4B76-BBE4-096D3AD4671C@oracle.com> <23A708B4-8BF0-4B0B-8A7F-6628A444B2A6@oracle.com> <0f620419-4f5d-19d0-e3a6-d49f187b4788@oracle.com> <509F427C-D939-459F-A953-CC6BC47EEE36@oracle.com> Message-ID: <32000447-2f4c-501e-0008-44e9a06f6cbe@oracle.com> Thanks for the update! On 8/13/2018 11:39 PM, Weijun Wang wrote: > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8209416/webrev.01/ > > You can look at [1] to see what has changed. Mostly it's a case in other security libs. I also change the calling style to put property name in the same line as the getProperty() call, and inline the name if it was defined as a constant. > > You might want to double check on the change in TlsRsaPremasterSecretParameterSpec.java. I think I got it right. > Would you like remove the PROP_NAME field, and use its value directly? Just a nit, need no more review from me. Thanks, Xuelei > Thanks > Max > > [1] http://cr.openjdk.java.net/~weijun/8209416/webrev.01/interdiff.patch.html > >> On Aug 14, 2018, at 3:24 AM, Xue-Lei Fan wrote: >> >> It's nice to fix them if you'd like to. >> >> Thanks, >> Xuelei >> >> On 8/13/2018 8:36 AM, Weijun Wang wrote: >>> And several AccessController.doPrivileged(new GetBooleanAction()) calls. >>> If you'd like me to fix them as well, I can change the bug synopsis a little. >>> Thanks >>> Max >>>> On Aug 13, 2018, at 11:33 PM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Aug 13, 2018, at 10:00 PM, Xue-Lei Fan wrote: >>>>> >>>>> Looks fine to me. >>>>> >>>>> Did you notice other places that might need similar update as well in security components? >>>> >>>> One "new GetPropertyAction()" at >>>> >>>> String property = AccessController.doPrivileged( >>>> new GetPropertyAction("jdk.tls.namedGroups")); >>>> >>>> But I haven't checked for doPrivileged(()->System.getProperty()) calls. >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>> On 8/13/2018 3:24 AM, Weijun Wang wrote: >>>>>> Please take a review at >>>>>> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >>>>>> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >>>>>> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >>>>>> Noreg-cleanup. >>>>>> Thanks >>>>>> Max >>>> > From Roger.Riggs at Oracle.com Tue Aug 14 14:18:04 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 14 Aug 2018 10:18:04 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

Message-ID: Hi Max, On 8/14/2018 12:29 AM, Weijun Wang wrote: >> On Aug 7, 2018, at 10:57 PM, Roger Riggs wrote: >> >> Hi Max, >> >> It may be useful to include in the descriptions a reminder that if no ObjectInputFilter >> is supplied the global filter is used. Details in ObjectInputStream. > The new getObject() methods with an ObjectInputFilter does not allow it to be null, so it looks strange to mention this in the method spec. True, the system filter would only apply to the original getObject() method in which a serial filter is not supplied. > I'm thinking about these changes in the example part of the class spec: > > * Signature.getInstance(algorithm, provider); > * if (so.verify(publickey, verificationEngine)) > * try { > - * Object myobj = so.getObject(); > + * ObjectInputFilter myfilter = ...; > + * Object myobj = so.getObject(myfilter); > * } catch (java.lang.ClassNotFoundException e) {}; > * } > * > + * In this example, the {@link ObjectInputFilter} object is used during > + * deserialization to check the contents of the stream. If {@link #getObject()} > + * is called, the {@link ObjectInputFilter.Config#getSerialFilter() > + * initial process-wide filter} is used. > > I copied the words from ObjectInputStream::getObjectInputFilter. Is this a formal name of the "global filter"? I've had a request to update the terminology, so 'system filter' will be more appropriate. [1] 8202675 Replace process-wide terminology in serial filtering to be consistent Regards, Roger >> Thanks, Roger >> >> >> On 8/7/18 2:31 AM, Weijun Wang wrote: >>> Please review the code change at >>> >>> webrev: http://cr.openjdk.java.net/~weijun/8193859/webrev.00/ >>> >>> where >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8193859 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8193887 >>> >>> Thanks >>> Max >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Tue Aug 14 14:18:07 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 14 Aug 2018 10:18:07 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

Message-ID: <1da044db-3f10-ffee-bcb8-6c5e4a8cdc01@Oracle.com> Hi Max, On 8/14/2018 1:33 AM, Weijun Wang wrote: > Here is the change for both classes. I use "original object" so a caller would know what the filter should expect. ok > > diff --git a/src/java.base/share/classes/java/security/SignedObject.java b/src/java.base/share/classes/java/security/SignedObject.java > --- a/src/java.base/share/classes/java/security/SignedObject.java > +++ b/src/java.base/share/classes/java/security/SignedObject.java > @@ -59,10 +59,16 @@ > * Signature.getInstance(algorithm, provider); > * if (so.verify(publickey, verificationEngine)) > * try { > - * Object myobj = so.getObject(); > + * ObjectInputFilter myfilter = ...; > + * Object myobj = so.getObject(myfilter); > * } catch (java.lang.ClassNotFoundException e) {}; > * } > * > + * In this example, an {@link ObjectInputFilter}object is used during > + * deserialization of the original object. If {@link #getObject()} is > + * called, the {@link ObjectInputFilter.Config#getSerialFilter() > + * initial process-wide filter} is used instead. > + * Just saying "an ObjectInputFilter is used"... is fine. > *

Several points are worth noting. First, there is no need to > * initialize the signing or verification engine, as it will be > * re-initialized inside the constructor and the {@code verify} > diff --git a/src/java.base/share/classes/javax/crypto/SealedObject.java b/src/java.base/share/classes/javax/crypto/SealedObject.java > --- a/src/java.base/share/classes/javax/crypto/SealedObject.java > +++ b/src/java.base/share/classes/javax/crypto/SealedObject.java > @@ -86,6 +86,12 @@ > * > *

> * > + * Both methods have overloaded forms that accept an {@link ObjectInputFilter} > + * parameter, which will be used during deserialization of the original object. > + * If a {@code getObject} method without a {@code ObjectInputFilter} parameter > + * is called, the {@link ObjectInputFilter.Config#getSerialFilter() > + * initial process-wide filter} is used instead. > > This last paragraph is after the

wrote: >> >>> On Aug 7, 2018, at 10:57 PM, Roger Riggs wrote: >>> >>> It may be useful to include in the descriptions a reminder that if no ObjectInputFilter >>> is supplied the global filter is used. Details in ObjectInputStream. >> The new getObject() methods with an ObjectInputFilter does not allow it to be null, so it looks strange to mention this in the method spec. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Aug 14 14:26:59 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Aug 2018 10:26:59 -0400 Subject: RFR 8209416: Refactoring GetPropertyAction calls in JGSS In-Reply-To: <23BE44EB-D6D1-49BC-96A0-20DFDFFF7AEA@oracle.com> References: <9D164507-9CB7-4A82-853B-12759A2E6E0A@oracle.com> <45eb8bd6-21d4-8f3e-be55-46fbc9ac5cc1@oracle.com> <23BE44EB-D6D1-49BC-96A0-20DFDFFF7AEA@oracle.com> Message-ID: <08d66287-43e7-79ef-6374-989036390dec@oracle.com> On 8/14/18 1:04 AM, Weijun Wang wrote: > > >> On Aug 14, 2018, at 3:11 AM, Sean Mullan wrote: >> >> I think this should be an enhancement, and not a bug. Is this mainly for a performance improvement? > > Yes it's an enhancement. > > Performance can be gained. Also, the privilegedGetProperty() method is already called in a lot of places. Using it everywhere makes the code looks consistent and simpler. > >> >> Also, this change puts more of a dependency on sun.security.action which I think we want to avoid, as it would be nice to eventually stop exporting sun.security.action so as to minimize the exports from java.base to the java.security.jgss module. You can double-check with Mandy or Alan on whether my line of thinking is correct on that. > > I've talked with Mandy. She thinks it's OK now to continue using the sun.security.action since java.security.jgss is not upgradeable and there is no security concern. Also, I think using the same method now would be helpful if we want to switch to another method implemented inside the module some time in the future. Ok. --Sean > > Thanks > Max > >> >> Thanks, >> Sean >> >> On 8/13/18 6:24 AM, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8209416/webrev.00/ >>> This is all about refactoring "AccessController.doPrivileged(new GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)". >>> I've already introduced a new GetBooleanAction::privilegedGetProperty method. >>> Noreg-cleanup. >>> Thanks >>> Max > From mbalao at redhat.com Tue Aug 14 14:43:18 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 14 Aug 2018 15:43:18 +0100 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com>

<7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> Message-ID: Hi Valerie, Here it is Webrev.07: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.07/ * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.07.zip * p11_convert.c: * L530 and 834: masterKeyDeriveParamToCKMasterKeyDeriveParam and keyMatParamToCKKeyMatParam functions used to accept "null" value for class parameter -and, in fact, immediately return in such case-. Null-checking was in these functions to avoid checking on each call site (i.e.: jSsl3MasterKeyDeriveParamToCKSsl3MasterKeyDeriveParam and jTls12MasterKeyDeriveParamToCKTls12MasterKeyDeriveParam call sites for masterKeyDeriveParamToCKMasterKeyDeriveParam). But I reverted this change now, so we check on call sites. I couldn't find any not-checked FindClass call. * L1262: well spotted! Fixed. * Author tags removed * Updated copyright on every modified file * TestTLS12.java improvements: * initSecmod is now called when starting the test * Better integration with existing NSSDB + FIPS infrastructure * RSA+SHA256 certificate (that expires in 2042) was added to FIPS keystore and NSSDB. * Putback comment on webrev * jdk/sun/security/pkcs11 test suite pass-rate experienced no regression Thanks, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Aug 14 14:59:07 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2018 22:59:07 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

Message-ID: > On Aug 14, 2018, at 10:18 PM, Roger Riggs wrote: >> >> * >> + * In this example, the {@link ObjectInputFilter} object is used during >> + * deserialization to check the contents of the stream. If {@link #getObject()} >> + * is called, the {@link ObjectInputFilter.Config#getSerialFilter() >> + * initial process-wide filter} is used. >> >> I copied the words from ObjectInputStream::getObjectInputFilter. Is this a formal name of the "global filter"? > I've had a request to update the terminology, so 'system filter' will be more appropriate. s/initial process-wide filter/system filter/? --Max > [1] 8202675 Replace process-wide terminology in serial filtering to be consistent > > Regards, Roger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Tue Aug 14 15:19:11 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 14 Aug 2018 11:19:11 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

Message-ID: <9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> Hi, On 8/14/2018 10:59 AM, Weijun Wang wrote: > > s/initial process-wide filter/system filter/? yes Roger > > --Max > >> [1] 8202675 ? >> Replace process-wide terminology in serial filtering to be consistent >> >> Regards, Roger >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Tue Aug 14 15:48:48 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 14 Aug 2018 08:48:48 -0700 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> Message-ID: <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> Few minor comments on README: - Please leave an empty line after each numbered section - I would suggest to update #2 to have general instruction on use of artifactory. Something like 2. Pre-built NSS libraries from artifactory server If the value of system property test.nss.lib.paths is null then tests will try to download pre-built NSS libraries from artifactory server. Currently, test only looks for libraries for Windows and MacOSX on artifactory. Please note that, JIB jar MUST be present in classpath when downloading the libraries. Other changes look good to me. Thanks, Rajan On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: > > Hi Max, > Please review the new webrev: > http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ > > The new system property has been renamed to test.nss.lib.paths, and it > supports multiple paths. > Currently, it cannot download the artifacts outside Oracle network. > This affects the test executions on Windows and MacOSX. > I added a block to README for clarifying something on getting NSS > libraries. > > Best regards, > John Jiang > > On 2018/8/13 16:48, Weijun Wang wrote: >> Sorry, more questions: >> >>> On Aug 13, 2018, at 3:36 PM,sha.jiang at oracle.com wrote: >>> >>>> Is there an artifact server available on the open internet? >>> It's transparent to me. @Artifact tool delegates the downloading. >> Have you tried running the test outside Oracle? >> >> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >> >> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >> >> Thanks >> Max >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Tue Aug 14 16:22:38 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 14 Aug 2018 09:22:38 -0700 Subject: RFR: 8209452: VerifyCACerts.java failed with "At least one cacert test failed" Message-ID: <92bc4a00-6cf8-b34d-c700-a1352d48f04c@oracle.com> Please review this fix to allow test to pass if expired certificate is allowed by exception list. Webrev: http://cr.openjdk.java.net/~rhalade/8209452/webrev.00/ Thanks, Rajan From sean.mullan at oracle.com Tue Aug 14 16:34:58 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Aug 2018 12:34:58 -0400 Subject: RFR: 8209452: VerifyCACerts.java failed with "At least one cacert test failed" In-Reply-To: <92bc4a00-6cf8-b34d-c700-a1352d48f04c@oracle.com> References: <92bc4a00-6cf8-b34d-c700-a1352d48f04c@oracle.com> Message-ID: Looks good. When you push the changeset, can you add a Summary line with more details of the fix, ex: Summary: allow expired certificates on exception list to pass after they expire Thanks, Sean On 8/14/18 12:22 PM, Rajan Halade wrote: > Please review this fix to allow test to pass if expired certificate is > allowed by exception list. > > Webrev: http://cr.openjdk.java.net/~rhalade/8209452/webrev.00/ > > Thanks, > Rajan From anthony.scarpino at oracle.com Tue Aug 14 17:56:51 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 14 Aug 2018 10:56:51 -0700 Subject: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: <7a1961a6-3ffb-59f2-7775-d5a76b64ba5d@oracle.com> References: <45d61e4c-e81e-a4ee-497e-f205c2c3f015@oracle.com>

<14a0da8e-a1e5-0916-969a-e7cd20b57e3e@oracle.com> <4f57a76f-8fc5-7390-88cb-7e40b3142a36@oracle.com> <01954bbf-3623-78f6-488d-3283cd248587@oracle.com> <8c12023c-9d30-f66e-b139-db659d2b1023@oracle.com> <650ee21d-ec31-0ee0-ab2a-cf4fed2a21d4@oracle.com> <17372eb4-9006-2150-547d-87dcbbb90a2c@oracle.com> <7a1961a6-3ffb-59f2-7775-d5a76b64ba5d@oracle.com> <9c7a394a-9087-d70e-02c3-621556629e71@oracle.com> Message-ID: <9a2a9aa8-eebe-8002-3fe6-1495a2c404ff@oracle.com> On 08/14/2018 11:27 AM, Sean Mullan wrote: > On 8/14/18 1:56 PM, Anthony Scarpino wrote: >> On 08/13/2018 12:42 PM, Sean Mullan wrote: >>> On 8/10/18 3:49 PM, Anthony Scarpino wrote: >>>>> On 8/9/2018 4:25 AM, Sean Mullan wrote: >>>>>> On 8/8/18 5:29 PM, Xuelei Fan wrote: >>>>>>> The "Default" algorithm defined in the SunJSSE provider is for >>>>>>> TLS protocols. >>>>>> >>>>>> What if I set DTLS to be the default, though? Ex: >>>>>> >>>>>> ???? SSLContext.setDefault(SSLContext.getInstance("DTLS")); >>>>>> >>>>> Good point!? Maybe, we also need to update the >>>>> SSLSocketFactory/SSLServerSocketFactory.getDefault() to return >>>>> inoperative factory. >>>> >>>> I'm not sure the code path you're looking as the oneI see seems >>>> pretty obscure. >>>> >>>> Are you two talking about where >>>> SSL[Server]SocketFactory.getDefault() uses a >>>> ssl.SocketFactory.provider property set to SunJSSE?? If so, can see >>>> that as a code review comment, but it seems very obscure for the CSR. >>> >>> Here's the code I would use: >>> >>> ???????? SSLContext.setDefault(SSLContext.getInstance("DTLS")); >>> ???????? ServerSocketFactory fac = SSLServerSocketFactory.getDefault(); >>> >>> If I read the spec correctly, fac should be an "inoperative factory". >>> >>> --Sean >> >> >> Sure, but SSLServerSocketFactory.getDefault() typically return >> SSLContext.getDefault().getServerSocketFactory(). Which is covered by >> the planned exception change, unless I'm missing something here. >> >> Now there is the atypically case where the property is set, but that >> seems like a stretch to set the property to use SunJSSE, >> >> Finally, even if there is a change to be made here. I'm not sure the >> impact of the CSR.. It's seems easier to explain an obvious exception >> than a nebulous "inoperative factory" > > If our implementation throws an Exception that is not specified by the > API, then we are non-compliant (or the API needs to be updated to throw > that Exception). > > --Sean > Fair point.. It throws nothing right now. I guess inoperative factory it shall be. I updated the Solution to include this change, I don't think it needs to be hi-lighted elswhere given it's a result to the main change. Tony From rajan.halade at oracle.com Tue Aug 14 21:06:32 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 14 Aug 2018 14:06:32 -0700 Subject: RFR: 8209506: Add Google Trust Services GlobalSign root certificates Message-ID: <07bd7453-235a-c68e-9a69-65a9ffc1dcf0@oracle.com> Please review this fix to add Google issued root certificates to cacerts file. I have started jdk11 late enhancement request and will wait for approval to push this fix. Also, release note is available at JDK-8209512. After this fix is pushed, we will need to update release note 8207255 to remove mention of Google roots. Webrev: http://cr.openjdk.java.net/~rhalade/8209506/webrev.00/ Thanks, Rajan From sean.mullan at oracle.com Tue Aug 14 21:19:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Aug 2018 17:19:13 -0400 Subject: RFR: 8209506: Add Google Trust Services GlobalSign root certificates In-Reply-To: <07bd7453-235a-c68e-9a69-65a9ffc1dcf0@oracle.com> References: <07bd7453-235a-c68e-9a69-65a9ffc1dcf0@oracle.com> Message-ID: <943f9f67-5709-b959-b180-f05fe444eaf6@oracle.com> Looks good. --Sean On 8/14/18 5:06 PM, Rajan Halade wrote: > Please review this fix to add Google issued root certificates to cacerts > file. I have started jdk11 late enhancement request and will wait for > approval to push this fix. Also, release note is available at > JDK-8209512. After this fix is pushed, we will need to update release > note 8207255 to remove mention of Google roots. > > Webrev: http://cr.openjdk.java.net/~rhalade/8209506/webrev.00/ > > Thanks, > Rajan From rajan.halade at oracle.com Tue Aug 14 23:10:45 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 14 Aug 2018 16:10:45 -0700 Subject: RFR: 8206176: Remove the temporary tls13VN Message-ID: <43d77e7b-e9e9-1af5-88a2-d2a118973da2@oracle.com> Please review this fix to remove "jdk.tsl13.version" system property we had as interim solution for testing TLSv1.3 implementation. Webrev: http://cr.openjdk.java.net/~rhalade/8206176/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Tue Aug 14 23:14:11 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 14 Aug 2018 16:14:11 -0700 Subject: RFR: 8206176: Remove the temporary tls13VN In-Reply-To: <43d77e7b-e9e9-1af5-88a2-d2a118973da2@oracle.com> References: <43d77e7b-e9e9-1af5-88a2-d2a118973da2@oracle.com> Message-ID: <49dd3154-4c12-2f9a-9059-1e740763c226@oracle.com> Looks fine to me. Thanks! Xuelei On 8/14/2018 4:10 PM, Rajan Halade wrote: > Please review this fix to remove "jdk.tsl13.version" system property we > had as interim solution for testing TLSv1.3 implementation. > > Webrev: http://cr.openjdk.java.net/~rhalade/8206176/webrev.00/ > > Thanks, > Rajan From bradford.wetmore at oracle.com Tue Aug 14 23:29:32 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 14 Aug 2018 16:29:32 -0700 Subject: RFR: 8206176: Remove the temporary tls13VN In-Reply-To: <49dd3154-4c12-2f9a-9059-1e740763c226@oracle.com> References: <43d77e7b-e9e9-1af5-88a2-d2a118973da2@oracle.com> <49dd3154-4c12-2f9a-9059-1e740763c226@oracle.com> Message-ID: Looks good. Brad On 8/14/2018 4:14 PM, Xue-Lei Fan wrote: > Looks fine to me.? Thanks! > > Xuelei > > On 8/14/2018 4:10 PM, Rajan Halade wrote: >> Please review this fix to remove "jdk.tsl13.version" system property >> we had as interim solution for testing TLSv1.3 implementation. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8206176/webrev.00/ >> >> Thanks, >> Rajan From sha.jiang at oracle.com Wed Aug 15 02:13:41 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 15 Aug 2018 10:13:41 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> Message-ID: <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> Thanks for the comments! Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ Only README was adjusted. Best regards, John Jiang On 2018/8/14 23:48, Rajan Halade wrote: > Few minor comments on README: > > - Please leave an empty line after each numbered section > - I would suggest to update #2 to have general instruction on use of > artifactory. Something like > > 2. Pre-built NSS libraries from artifactory server > If the value of system property test.nss.lib.paths is null then tests will try > to download pre-built NSS libraries from artifactory server. > Currently, test only looks for libraries for Windows and MacOSX on artifactory. > Please note that, JIB jar MUST be present in classpath when downloading the libraries. > Other changes look good to me. > > Thanks, > Rajan > > On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >> >> Hi Max, >> Please review the new webrev: >> http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >> >> The new system property has been renamed to test.nss.lib.paths, and >> it supports multiple paths. >> Currently, it cannot download the artifacts outside Oracle network. >> This affects the test executions on Windows and MacOSX. >> I added a block to README for clarifying something on getting NSS >> libraries. >> >> Best regards, >> John Jiang >> >> On 2018/8/13 16:48, Weijun Wang wrote: >>> Sorry, more questions: >>> >>>> On Aug 13, 2018, at 3:36 PM,sha.jiang at oracle.com wrote: >>>> >>>>> Is there an artifact server available on the open internet? >>>> It's transparent to me. @Artifact tool delegates the downloading. >>> Have you tried running the test outside Oracle? >>> >>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>> >>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>> >>> Thanks >>> Max >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Wed Aug 15 02:16:59 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 14 Aug 2018 19:16:59 -0700 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> Message-ID: <87c84cf9-ee32-11f9-5165-c434e633a3b3@oracle.com> Looks good to me! Thanks, Rajan On 8/14/18 7:13 PM, sha.jiang at oracle.com wrote: > > Thanks for the comments! > Please take a look the updated webrev: > http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ > Only README was adjusted. > > Best regards, > John Jiang > > On 2018/8/14 23:48, Rajan Halade wrote: >> Few minor comments on README: >> >> - Please leave an empty line after each numbered section >> - I would suggest to update #2 to have general instruction on use of >> artifactory. Something like >> >> 2. Pre-built NSS libraries from artifactory server >> If the value of system property test.nss.lib.paths is null then tests will try >> to download pre-built NSS libraries from artifactory server. >> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >> Other changes look good to me. >> >> Thanks, >> Rajan >> >> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>> >>> Hi Max, >>> Please review the new webrev: >>> http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>> >>> The new system property has been renamed to test.nss.lib.paths, and >>> it supports multiple paths. >>> Currently, it cannot download the artifacts outside Oracle network. >>> This affects the test executions on Windows and MacOSX. >>> I added a block to README for clarifying something on getting NSS >>> libraries. >>> >>> Best regards, >>> John Jiang >>> >>> On 2018/8/13 16:48, Weijun Wang wrote: >>>> Sorry, more questions: >>>> >>>>> On Aug 13, 2018, at 3:36 PM,sha.jiang at oracle.com wrote: >>>>> >>>>>> Is there an artifact server available on the open internet? >>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>> Have you tried running the test outside Oracle? >>>> >>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>> >>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>> >>>> Thanks >>>> Max >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Aug 15 03:23:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2018 11:23:54 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> Message-ID: Two comments on PKCS11Test.java: First, 865 private static String fetchNssLib(Class clazz) { 866 try { 867 String path = ArtifactResolver.resolve(clazz).entrySet().stream() 868 .findAny().get().getValue() + File.separator + "nsslib" 869 + File.separator; 870 return path; 871 } catch (ArtifactResolverException e) { 872 throw new RuntimeException("Fetch artifact failed: " + clazz 873 + "\nPlease make sure the artifact is available " 874 + "and JIB jar is in the classpath", e); 875 } 876 } If an external developer is running this test and cannot download the artifact (either because there's no JIB jar or cannot access the server), will this test fail? If yes, this is not a good idea. I'm OK with the test succeed with a warning (even if no one notice it) but failure is bad. Second, 666 osMap.put("SunOS-sparc-32", 667 getNssLibPaths(new String[] { "/usr/lib/mps/" })); ... We needn't call getNssLibPaths() for every platform, especially, the fetchNssLib() action should only run on the current platform. We can simply add something after these existing lines 309 String osid = osName + "-" 310 + props.getProperty("os.arch") + "-" + props.getProperty("sun.arch.data.model"); 311 String[] nssLibDirs = osMap.get(osid); For example, String[] nssLibDirs = expandDirs(osMap.get(osid)); and let expandDirs() to do the test.nss.lib.paths search and artifact downloading. REAME is good, although I would like to see more blank lines. Thanks Max > On Aug 15, 2018, at 10:13 AM, sha.jiang at oracle.com wrote: > > Thanks for the comments! > Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ > Only README was adjusted. > > Best regards, > John Jiang > On 2018/8/14 23:48, Rajan Halade wrote: >> Few minor comments on README: >> >> - Please leave an empty line after each numbered section >> - I would suggest to update #2 to have general instruction on use of artifactory. Something like >> >> 2. Pre-built NSS libraries from artifactory server >> If the value of system property test.nss.lib.paths is null then tests will try >> to download pre-built NSS libraries from artifactory server. >> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >> >> Other changes look good to me. >> >> Thanks, >> Rajan >> >> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>> Hi Max, >>> Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>> >>> The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. >>> Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. >>> I added a block to README for clarifying something on getting NSS libraries. >>> >>> Best regards, >>> John Jiang >>> On 2018/8/13 16:48, Weijun Wang wrote: >>>> Sorry, more questions: >>>> >>>> >>>>> On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com >>>>> wrote: >>>>> >>>>> >>>>>> Is there an artifact server available on the open internet? >>>>>> >>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>>> >>>> Have you tried running the test outside Oracle? >>>> >>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>> >>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> >>> >> > From sha.jiang at oracle.com Wed Aug 15 06:45:07 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 15 Aug 2018 14:45:07 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> Message-ID: <4bf31a4e-f9bc-e800-a934-8555a20b68c1@oracle.com> Hi Max, Thanks for your comments very much! Please review this version: http://cr.openjdk.java.net/~jjiang/8164639/werbrev.03/ All of your comments are addressed. Assume external developers have no JIB jar, the artifact resolving fails quickly. The tests will be skipped for this case. Best regards, John Jiang On 2018/8/15 11:23, Weijun Wang wrote: > Two comments on PKCS11Test.java: > > First, > > 865 private static String fetchNssLib(Class clazz) { > 866 try { > 867 String path = ArtifactResolver.resolve(clazz).entrySet().stream() > 868 .findAny().get().getValue() + File.separator + "nsslib" > 869 + File.separator; > 870 return path; > 871 } catch (ArtifactResolverException e) { > 872 throw new RuntimeException("Fetch artifact failed: " + clazz > 873 + "\nPlease make sure the artifact is available " > 874 + "and JIB jar is in the classpath", e); > 875 } > 876 } > > If an external developer is running this test and cannot download the artifact (either because there's no JIB jar or cannot access the server), will this test fail? > > If yes, this is not a good idea. I'm OK with the test succeed with a warning (even if no one notice it) but failure is bad. > > Second, > > 666 osMap.put("SunOS-sparc-32", > 667 getNssLibPaths(new String[] { "/usr/lib/mps/" })); > ... > > We needn't call getNssLibPaths() for every platform, especially, the fetchNssLib() action should only run on the current platform. We can simply add something after these existing lines > > 309 String osid = osName + "-" > 310 + props.getProperty("os.arch") + "-" + props.getProperty("sun.arch.data.model"); > 311 String[] nssLibDirs = osMap.get(osid); > > For example, > > String[] nssLibDirs = expandDirs(osMap.get(osid)); > > and let expandDirs() to do the test.nss.lib.paths search and artifact downloading. > > REAME is good, although I would like to see more blank lines. > > Thanks > Max > >> On Aug 15, 2018, at 10:13 AM, sha.jiang at oracle.com wrote: >> >> Thanks for the comments! >> Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ >> Only README was adjusted. >> >> Best regards, >> John Jiang >> On 2018/8/14 23:48, Rajan Halade wrote: >>> Few minor comments on README: >>> >>> - Please leave an empty line after each numbered section >>> - I would suggest to update #2 to have general instruction on use of artifactory. Something like >>> >>> 2. Pre-built NSS libraries from artifactory server >>> If the value of system property test.nss.lib.paths is null then tests will try >>> to download pre-built NSS libraries from artifactory server. >>> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >>> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >>> >>> Other changes look good to me. >>> >>> Thanks, >>> Rajan >>> >>> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>>> Hi Max, >>>> Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>>> >>>> The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. >>>> Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. >>>> I added a block to README for clarifying something on getting NSS libraries. >>>> >>>> Best regards, >>>> John Jiang >>>> On 2018/8/13 16:48, Weijun Wang wrote: >>>>> Sorry, more questions: >>>>> >>>>> >>>>>> On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Is there an artifact server available on the open internet? >>>>>>> >>>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>>>> >>>>> Have you tried running the test outside Oracle? >>>>> >>>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>>> >>>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> > From weijun.wang at oracle.com Wed Aug 15 06:54:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2018 14:54:17 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <4bf31a4e-f9bc-e800-a934-8555a20b68c1@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> <4bf31a4e-f9bc-e800-a934-8555a20b68c1@oracle.com> Message-ID: <04D20828-3CC7-42F3-A3EE-7577E6C85AFE@oracle.com> I notice one behavior change in PKCS11Test.java. 693 private static String[] getNssLibPaths(String osId) { 694 String[] preferablePaths = getPreferableNssLibPaths(osId); 695 if (preferablePaths.length != 0) { 696 return preferablePaths; 697 } else { 698 return getOsMap().get(osId); 699 } 700 } If getPreferableNssLibPaths(osId) returns a non-empty array, it seems you will not look at osMap at all. This means if the system property is set but it does not contain NSS libraries you will not look into osMap as a fallback. Is this intended? Thanks Max > On Aug 15, 2018, at 2:45 PM, sha.jiang at oracle.com wrote: > > Hi Max, > Thanks for your comments very much! > > Please review this version: http://cr.openjdk.java.net/~jjiang/8164639/werbrev.03/ > All of your comments are addressed. > > Assume external developers have no JIB jar, the artifact resolving fails quickly. The tests will be skipped for this case. > > Best regards, > John Jiang > > On 2018/8/15 11:23, Weijun Wang wrote: >> Two comments on PKCS11Test.java: >> >> First, >> >> 865 private static String fetchNssLib(Class clazz) { >> 866 try { >> 867 String path = ArtifactResolver.resolve(clazz).entrySet().stream() >> 868 .findAny().get().getValue() + File.separator + "nsslib" >> 869 + File.separator; >> 870 return path; >> 871 } catch (ArtifactResolverException e) { >> 872 throw new RuntimeException("Fetch artifact failed: " + clazz >> 873 + "\nPlease make sure the artifact is available " >> 874 + "and JIB jar is in the classpath", e); >> 875 } >> 876 } >> >> If an external developer is running this test and cannot download the artifact (either because there's no JIB jar or cannot access the server), will this test fail? >> >> If yes, this is not a good idea. I'm OK with the test succeed with a warning (even if no one notice it) but failure is bad. >> >> Second, >> >> 666 osMap.put("SunOS-sparc-32", >> 667 getNssLibPaths(new String[] { "/usr/lib/mps/" })); >> ... >> >> We needn't call getNssLibPaths() for every platform, especially, the fetchNssLib() action should only run on the current platform. We can simply add something after these existing lines >> >> 309 String osid = osName + "-" >> 310 + props.getProperty("os.arch") + "-" + props.getProperty("sun.arch.data.model"); >> 311 String[] nssLibDirs = osMap.get(osid); >> >> For example, >> >> String[] nssLibDirs = expandDirs(osMap.get(osid)); >> >> and let expandDirs() to do the test.nss.lib.paths search and artifact downloading. >> >> REAME is good, although I would like to see more blank lines. >> >> Thanks >> Max >> >>> On Aug 15, 2018, at 10:13 AM, sha.jiang at oracle.com wrote: >>> >>> Thanks for the comments! >>> Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ >>> Only README was adjusted. >>> >>> Best regards, >>> John Jiang >>> On 2018/8/14 23:48, Rajan Halade wrote: >>>> Few minor comments on README: >>>> >>>> - Please leave an empty line after each numbered section >>>> - I would suggest to update #2 to have general instruction on use of artifactory. Something like >>>> >>>> 2. Pre-built NSS libraries from artifactory server >>>> If the value of system property test.nss.lib.paths is null then tests will try >>>> to download pre-built NSS libraries from artifactory server. >>>> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >>>> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >>>> >>>> Other changes look good to me. >>>> >>>> Thanks, >>>> Rajan >>>> >>>> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>>>> Hi Max, >>>>> Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>>>> >>>>> The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. >>>>> Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. >>>>> I added a block to README for clarifying something on getting NSS libraries. >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> On 2018/8/13 16:48, Weijun Wang wrote: >>>>>> Sorry, more questions: >>>>>> >>>>>> >>>>>>> On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Is there an artifact server available on the open internet? >>>>>>>> >>>>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>>>>> >>>>>> Have you tried running the test outside Oracle? >>>>>> >>>>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>>>> >>>>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> >> > From sha.jiang at oracle.com Wed Aug 15 07:07:27 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 15 Aug 2018 15:07:27 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <04D20828-3CC7-42F3-A3EE-7577E6C85AFE@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> <4bf31a4e-f9bc-e800-a934-8555a20b68c1@oracle.com> <04D20828-3CC7-42F3-A3EE-7577E6C85AFE@oracle.com> Message-ID: <41a9f3e3-459e-77ed-c115-2b7fb18f2e00@oracle.com> On 2018/8/15 14:54, Weijun Wang wrote: > I notice one behavior change in PKCS11Test.java. > > 693 private static String[] getNssLibPaths(String osId) { > 694 String[] preferablePaths = getPreferableNssLibPaths(osId); > 695 if (preferablePaths.length != 0) { > 696 return preferablePaths; > 697 } else { > 698 return getOsMap().get(osId); > 699 } > 700 } > > If getPreferableNssLibPaths(osId) returns a non-empty array, it seems you will not look at osMap at all. This means if the system property is set but it does not contain NSS libraries you will not look into osMap as a fallback. Is this intended? Yes. I assume user have specified the full libs. If the specified libs are not enough, that may be a user's mistake. If it allows the tests work with custom libs and system libs, that may be confused. Best regards, John Jiang > > Thanks > Max > > >> On Aug 15, 2018, at 2:45 PM, sha.jiang at oracle.com wrote: >> >> Hi Max, >> Thanks for your comments very much! >> >> Please review this version: http://cr.openjdk.java.net/~jjiang/8164639/werbrev.03/ >> All of your comments are addressed. >> >> Assume external developers have no JIB jar, the artifact resolving fails quickly. The tests will be skipped for this case. >> >> Best regards, >> John Jiang >> >> On 2018/8/15 11:23, Weijun Wang wrote: >>> Two comments on PKCS11Test.java: >>> >>> First, >>> >>> 865 private static String fetchNssLib(Class clazz) { >>> 866 try { >>> 867 String path = ArtifactResolver.resolve(clazz).entrySet().stream() >>> 868 .findAny().get().getValue() + File.separator + "nsslib" >>> 869 + File.separator; >>> 870 return path; >>> 871 } catch (ArtifactResolverException e) { >>> 872 throw new RuntimeException("Fetch artifact failed: " + clazz >>> 873 + "\nPlease make sure the artifact is available " >>> 874 + "and JIB jar is in the classpath", e); >>> 875 } >>> 876 } >>> >>> If an external developer is running this test and cannot download the artifact (either because there's no JIB jar or cannot access the server), will this test fail? >>> >>> If yes, this is not a good idea. I'm OK with the test succeed with a warning (even if no one notice it) but failure is bad. >>> >>> Second, >>> >>> 666 osMap.put("SunOS-sparc-32", >>> 667 getNssLibPaths(new String[] { "/usr/lib/mps/" })); >>> ... >>> >>> We needn't call getNssLibPaths() for every platform, especially, the fetchNssLib() action should only run on the current platform. We can simply add something after these existing lines >>> >>> 309 String osid = osName + "-" >>> 310 + props.getProperty("os.arch") + "-" + props.getProperty("sun.arch.data.model"); >>> 311 String[] nssLibDirs = osMap.get(osid); >>> >>> For example, >>> >>> String[] nssLibDirs = expandDirs(osMap.get(osid)); >>> >>> and let expandDirs() to do the test.nss.lib.paths search and artifact downloading. >>> >>> REAME is good, although I would like to see more blank lines. >>> >>> Thanks >>> Max >>> >>>> On Aug 15, 2018, at 10:13 AM, sha.jiang at oracle.com wrote: >>>> >>>> Thanks for the comments! >>>> Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ >>>> Only README was adjusted. >>>> >>>> Best regards, >>>> John Jiang >>>> On 2018/8/14 23:48, Rajan Halade wrote: >>>>> Few minor comments on README: >>>>> >>>>> - Please leave an empty line after each numbered section >>>>> - I would suggest to update #2 to have general instruction on use of artifactory. Something like >>>>> >>>>> 2. Pre-built NSS libraries from artifactory server >>>>> If the value of system property test.nss.lib.paths is null then tests will try >>>>> to download pre-built NSS libraries from artifactory server. >>>>> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >>>>> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >>>>> >>>>> Other changes look good to me. >>>>> >>>>> Thanks, >>>>> Rajan >>>>> >>>>> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>>>>> Hi Max, >>>>>> Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>>>>> >>>>>> The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. >>>>>> Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. >>>>>> I added a block to README for clarifying something on getting NSS libraries. >>>>>> >>>>>> Best regards, >>>>>> John Jiang >>>>>> On 2018/8/13 16:48, Weijun Wang wrote: >>>>>>> Sorry, more questions: >>>>>>> >>>>>>> >>>>>>>> On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Is there an artifact server available on the open internet? >>>>>>>>> >>>>>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>>>>>> >>>>>>> Have you tried running the test outside Oracle? >>>>>>> >>>>>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>>>>> >>>>>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> > From weijun.wang at oracle.com Wed Aug 15 07:14:48 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2018 15:14:48 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <41a9f3e3-459e-77ed-c115-2b7fb18f2e00@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> <4bf31a4e-f9bc-e800-a934-8555a20b68c1@oracle.com> <04D20828-3CC7-42F3-A3EE-7577E6C85AFE@oracle.com> <41a9f3e3-459e-77ed-c115-2b7fb18f2e00@oracle.com> Message-ID: <89D948AC-5F53-43E0-AA8E-A6AF29935C03@oracle.com> I see. One more question: Since the osMap content is not changed, is there a special reason you move the code from a static block into a static method? Thanks Max > On Aug 15, 2018, at 3:07 PM, sha.jiang at oracle.com wrote: > > On 2018/8/15 14:54, Weijun Wang wrote: >> I notice one behavior change in PKCS11Test.java. >> >> 693 private static String[] getNssLibPaths(String osId) { >> 694 String[] preferablePaths = getPreferableNssLibPaths(osId); >> 695 if (preferablePaths.length != 0) { >> 696 return preferablePaths; >> 697 } else { >> 698 return getOsMap().get(osId); >> 699 } >> 700 } >> >> If getPreferableNssLibPaths(osId) returns a non-empty array, it seems you will not look at osMap at all. This means if the system property is set but it does not contain NSS libraries you will not look into osMap as a fallback. Is this intended? > Yes. > > I assume user have specified the full libs. If the specified libs are not enough, that may be a user's mistake. > If it allows the tests work with custom libs and system libs, that may be confused. > > Best regards, > John Jiang > >> >> Thanks >> Max >> >> >>> On Aug 15, 2018, at 2:45 PM, sha.jiang at oracle.com wrote: >>> >>> Hi Max, >>> Thanks for your comments very much! >>> >>> Please review this version: http://cr.openjdk.java.net/~jjiang/8164639/werbrev.03/ >>> All of your comments are addressed. >>> >>> Assume external developers have no JIB jar, the artifact resolving fails quickly. The tests will be skipped for this case. >>> >>> Best regards, >>> John Jiang >>> >>> On 2018/8/15 11:23, Weijun Wang wrote: >>>> Two comments on PKCS11Test.java: >>>> >>>> First, >>>> >>>> 865 private static String fetchNssLib(Class clazz) { >>>> 866 try { >>>> 867 String path = ArtifactResolver.resolve(clazz).entrySet().stream() >>>> 868 .findAny().get().getValue() + File.separator + "nsslib" >>>> 869 + File.separator; >>>> 870 return path; >>>> 871 } catch (ArtifactResolverException e) { >>>> 872 throw new RuntimeException("Fetch artifact failed: " + clazz >>>> 873 + "\nPlease make sure the artifact is available " >>>> 874 + "and JIB jar is in the classpath", e); >>>> 875 } >>>> 876 } >>>> >>>> If an external developer is running this test and cannot download the artifact (either because there's no JIB jar or cannot access the server), will this test fail? >>>> >>>> If yes, this is not a good idea. I'm OK with the test succeed with a warning (even if no one notice it) but failure is bad. >>>> >>>> Second, >>>> >>>> 666 osMap.put("SunOS-sparc-32", >>>> 667 getNssLibPaths(new String[] { "/usr/lib/mps/" })); >>>> ... >>>> >>>> We needn't call getNssLibPaths() for every platform, especially, the fetchNssLib() action should only run on the current platform. We can simply add something after these existing lines >>>> >>>> 309 String osid = osName + "-" >>>> 310 + props.getProperty("os.arch") + "-" + props.getProperty("sun.arch.data.model"); >>>> 311 String[] nssLibDirs = osMap.get(osid); >>>> >>>> For example, >>>> >>>> String[] nssLibDirs = expandDirs(osMap.get(osid)); >>>> >>>> and let expandDirs() to do the test.nss.lib.paths search and artifact downloading. >>>> >>>> REAME is good, although I would like to see more blank lines. >>>> >>>> Thanks >>>> Max >>>> >>>>> On Aug 15, 2018, at 10:13 AM, sha.jiang at oracle.com wrote: >>>>> >>>>> Thanks for the comments! >>>>> Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ >>>>> Only README was adjusted. >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> On 2018/8/14 23:48, Rajan Halade wrote: >>>>>> Few minor comments on README: >>>>>> >>>>>> - Please leave an empty line after each numbered section >>>>>> - I would suggest to update #2 to have general instruction on use of artifactory. Something like >>>>>> >>>>>> 2. Pre-built NSS libraries from artifactory server >>>>>> If the value of system property test.nss.lib.paths is null then tests will try >>>>>> to download pre-built NSS libraries from artifactory server. >>>>>> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >>>>>> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >>>>>> >>>>>> Other changes look good to me. >>>>>> >>>>>> Thanks, >>>>>> Rajan >>>>>> >>>>>> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>>>>>> Hi Max, >>>>>>> Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>>>>>> >>>>>>> The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. >>>>>>> Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. >>>>>>> I added a block to README for clarifying something on getting NSS libraries. >>>>>>> >>>>>>> Best regards, >>>>>>> John Jiang >>>>>>> On 2018/8/13 16:48, Weijun Wang wrote: >>>>>>>> Sorry, more questions: >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Is there an artifact server available on the open internet? >>>>>>>>>> >>>>>>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>>>>>>> >>>>>>>> Have you tried running the test outside Oracle? >>>>>>>> >>>>>>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>>>>>> >>>>>>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> >> > From sha.jiang at oracle.com Wed Aug 15 07:22:26 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 15 Aug 2018 15:22:26 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: <89D948AC-5F53-43E0-AA8E-A6AF29935C03@oracle.com> References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> <4bf31a4e-f9bc-e800-a934-8555a20b68c1@oracle.com> <04D20828-3CC7-42F3-A3EE-7577E6C85AFE@oracle.com> <41a9f3e3-459e-77ed-c115-2b7fb18f2e00@oracle.com> <89D948AC-5F53-43E0-AA8E-A6AF29935C03@oracle.com> Message-ID: On 2018/8/15 15:14, Weijun Wang wrote: > I see. > > One more question: Since the osMap content is not changed, is there a special reason you move the code from a static block into a static method? If preferable NSS lib paths have been provided, it looks no need to create that map. Best regards, John Jiang > > Thanks > Max > >> On Aug 15, 2018, at 3:07 PM, sha.jiang at oracle.com wrote: >> >> On 2018/8/15 14:54, Weijun Wang wrote: >>> I notice one behavior change in PKCS11Test.java. >>> >>> 693 private static String[] getNssLibPaths(String osId) { >>> 694 String[] preferablePaths = getPreferableNssLibPaths(osId); >>> 695 if (preferablePaths.length != 0) { >>> 696 return preferablePaths; >>> 697 } else { >>> 698 return getOsMap().get(osId); >>> 699 } >>> 700 } >>> >>> If getPreferableNssLibPaths(osId) returns a non-empty array, it seems you will not look at osMap at all. This means if the system property is set but it does not contain NSS libraries you will not look into osMap as a fallback. Is this intended? >> Yes. >> >> I assume user have specified the full libs. If the specified libs are not enough, that may be a user's mistake. >> If it allows the tests work with custom libs and system libs, that may be confused. >> >> Best regards, >> John Jiang >> >>> Thanks >>> Max >>> >>> >>>> On Aug 15, 2018, at 2:45 PM, sha.jiang at oracle.com wrote: >>>> >>>> Hi Max, >>>> Thanks for your comments very much! >>>> >>>> Please review this version: http://cr.openjdk.java.net/~jjiang/8164639/werbrev.03/ >>>> All of your comments are addressed. >>>> >>>> Assume external developers have no JIB jar, the artifact resolving fails quickly. The tests will be skipped for this case. >>>> >>>> Best regards, >>>> John Jiang >>>> >>>> On 2018/8/15 11:23, Weijun Wang wrote: >>>>> Two comments on PKCS11Test.java: >>>>> >>>>> First, >>>>> >>>>> 865 private static String fetchNssLib(Class clazz) { >>>>> 866 try { >>>>> 867 String path = ArtifactResolver.resolve(clazz).entrySet().stream() >>>>> 868 .findAny().get().getValue() + File.separator + "nsslib" >>>>> 869 + File.separator; >>>>> 870 return path; >>>>> 871 } catch (ArtifactResolverException e) { >>>>> 872 throw new RuntimeException("Fetch artifact failed: " + clazz >>>>> 873 + "\nPlease make sure the artifact is available " >>>>> 874 + "and JIB jar is in the classpath", e); >>>>> 875 } >>>>> 876 } >>>>> >>>>> If an external developer is running this test and cannot download the artifact (either because there's no JIB jar or cannot access the server), will this test fail? >>>>> >>>>> If yes, this is not a good idea. I'm OK with the test succeed with a warning (even if no one notice it) but failure is bad. >>>>> >>>>> Second, >>>>> >>>>> 666 osMap.put("SunOS-sparc-32", >>>>> 667 getNssLibPaths(new String[] { "/usr/lib/mps/" })); >>>>> ... >>>>> >>>>> We needn't call getNssLibPaths() for every platform, especially, the fetchNssLib() action should only run on the current platform. We can simply add something after these existing lines >>>>> >>>>> 309 String osid = osName + "-" >>>>> 310 + props.getProperty("os.arch") + "-" + props.getProperty("sun.arch.data.model"); >>>>> 311 String[] nssLibDirs = osMap.get(osid); >>>>> >>>>> For example, >>>>> >>>>> String[] nssLibDirs = expandDirs(osMap.get(osid)); >>>>> >>>>> and let expandDirs() to do the test.nss.lib.paths search and artifact downloading. >>>>> >>>>> REAME is good, although I would like to see more blank lines. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Aug 15, 2018, at 10:13 AM, sha.jiang at oracle.com wrote: >>>>>> >>>>>> Thanks for the comments! >>>>>> Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ >>>>>> Only README was adjusted. >>>>>> >>>>>> Best regards, >>>>>> John Jiang >>>>>> On 2018/8/14 23:48, Rajan Halade wrote: >>>>>>> Few minor comments on README: >>>>>>> >>>>>>> - Please leave an empty line after each numbered section >>>>>>> - I would suggest to update #2 to have general instruction on use of artifactory. Something like >>>>>>> >>>>>>> 2. Pre-built NSS libraries from artifactory server >>>>>>> If the value of system property test.nss.lib.paths is null then tests will try >>>>>>> to download pre-built NSS libraries from artifactory server. >>>>>>> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >>>>>>> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >>>>>>> >>>>>>> Other changes look good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Rajan >>>>>>> >>>>>>> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>>>>>>> Hi Max, >>>>>>>> Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>>>>>>> >>>>>>>> The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. >>>>>>>> Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. >>>>>>>> I added a block to README for clarifying something on getting NSS libraries. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> John Jiang >>>>>>>> On 2018/8/13 16:48, Weijun Wang wrote: >>>>>>>>> Sorry, more questions: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Is there an artifact server available on the open internet? >>>>>>>>>>> >>>>>>>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>>>>>>>> >>>>>>>>> Have you tried running the test outside Oracle? >>>>>>>>> >>>>>>>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>>>>>>> >>>>>>>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>> > From weijun.wang at oracle.com Wed Aug 15 07:23:18 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2018 15:23:18 +0800 Subject: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries In-Reply-To: References: <318c4766-5f46-5a16-6ace-d46cdf031702@oracle.com> <9C95B28E-B672-4EBB-8984-FC14A38C80BE@oracle.com> <4e902ba2-6eb7-640c-117a-2ea1c825e21e@oracle.com> <0874AB54-E422-4C05-B9D3-8D7F2EABA393@oracle.com> <8cc5186d-27fe-a378-74f7-d2e713a93b66@oracle.com> <7C8994F3-8FC4-4E97-9568-72F535F4D8CC@oracle.com> <3879a3e8-ded4-7f54-2c2a-0fdb55544e2b@oracle.com> <840d5d61-7f01-4eb7-4f6d-c301f22f4d2f@oracle.com> <3e811437-30b8-ea00-5c9b-65f5d55f87c4@oracle.com> <4bf31a4e-f9bc-e800-a934-8555a20b68c1@oracle.com> <04D20828-3CC7-42F3-A3EE-7577E6C85AFE@oracle.com> <41a9f3e3-459e-77ed-c115-2b7fb18f2e00@oracle.com> <89D948AC-5F53-43E0-AA8E-A6AF29935C03@oracle.com> Message-ID: <2B4D80FB-ADCD-41FA-8EF6-F30C17AC15A3@oracle.com> Good. I have no other comment. Thanks Max > On Aug 15, 2018, at 3:22 PM, sha.jiang at oracle.com wrote: > > On 2018/8/15 15:14, Weijun Wang wrote: >> I see. >> >> One more question: Since the osMap content is not changed, is there a special reason you move the code from a static block into a static method? > If preferable NSS lib paths have been provided, it looks no need to create that map. > > Best regards, > John Jiang > >> >> Thanks >> Max >> >>> On Aug 15, 2018, at 3:07 PM, sha.jiang at oracle.com wrote: >>> >>> On 2018/8/15 14:54, Weijun Wang wrote: >>>> I notice one behavior change in PKCS11Test.java. >>>> >>>> 693 private static String[] getNssLibPaths(String osId) { >>>> 694 String[] preferablePaths = getPreferableNssLibPaths(osId); >>>> 695 if (preferablePaths.length != 0) { >>>> 696 return preferablePaths; >>>> 697 } else { >>>> 698 return getOsMap().get(osId); >>>> 699 } >>>> 700 } >>>> >>>> If getPreferableNssLibPaths(osId) returns a non-empty array, it seems you will not look at osMap at all. This means if the system property is set but it does not contain NSS libraries you will not look into osMap as a fallback. Is this intended? >>> Yes. >>> >>> I assume user have specified the full libs. If the specified libs are not enough, that may be a user's mistake. >>> If it allows the tests work with custom libs and system libs, that may be confused. >>> >>> Best regards, >>> John Jiang >>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Aug 15, 2018, at 2:45 PM, sha.jiang at oracle.com wrote: >>>>> >>>>> Hi Max, >>>>> Thanks for your comments very much! >>>>> >>>>> Please review this version: http://cr.openjdk.java.net/~jjiang/8164639/werbrev.03/ >>>>> All of your comments are addressed. >>>>> >>>>> Assume external developers have no JIB jar, the artifact resolving fails quickly. The tests will be skipped for this case. >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>>> On 2018/8/15 11:23, Weijun Wang wrote: >>>>>> Two comments on PKCS11Test.java: >>>>>> >>>>>> First, >>>>>> >>>>>> 865 private static String fetchNssLib(Class clazz) { >>>>>> 866 try { >>>>>> 867 String path = ArtifactResolver.resolve(clazz).entrySet().stream() >>>>>> 868 .findAny().get().getValue() + File.separator + "nsslib" >>>>>> 869 + File.separator; >>>>>> 870 return path; >>>>>> 871 } catch (ArtifactResolverException e) { >>>>>> 872 throw new RuntimeException("Fetch artifact failed: " + clazz >>>>>> 873 + "\nPlease make sure the artifact is available " >>>>>> 874 + "and JIB jar is in the classpath", e); >>>>>> 875 } >>>>>> 876 } >>>>>> >>>>>> If an external developer is running this test and cannot download the artifact (either because there's no JIB jar or cannot access the server), will this test fail? >>>>>> >>>>>> If yes, this is not a good idea. I'm OK with the test succeed with a warning (even if no one notice it) but failure is bad. >>>>>> >>>>>> Second, >>>>>> >>>>>> 666 osMap.put("SunOS-sparc-32", >>>>>> 667 getNssLibPaths(new String[] { "/usr/lib/mps/" })); >>>>>> ... >>>>>> >>>>>> We needn't call getNssLibPaths() for every platform, especially, the fetchNssLib() action should only run on the current platform. We can simply add something after these existing lines >>>>>> >>>>>> 309 String osid = osName + "-" >>>>>> 310 + props.getProperty("os.arch") + "-" + props.getProperty("sun.arch.data.model"); >>>>>> 311 String[] nssLibDirs = osMap.get(osid); >>>>>> >>>>>> For example, >>>>>> >>>>>> String[] nssLibDirs = expandDirs(osMap.get(osid)); >>>>>> >>>>>> and let expandDirs() to do the test.nss.lib.paths search and artifact downloading. >>>>>> >>>>>> REAME is good, although I would like to see more blank lines. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Aug 15, 2018, at 10:13 AM, sha.jiang at oracle.com wrote: >>>>>>> >>>>>>> Thanks for the comments! >>>>>>> Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ >>>>>>> Only README was adjusted. >>>>>>> >>>>>>> Best regards, >>>>>>> John Jiang >>>>>>> On 2018/8/14 23:48, Rajan Halade wrote: >>>>>>>> Few minor comments on README: >>>>>>>> >>>>>>>> - Please leave an empty line after each numbered section >>>>>>>> - I would suggest to update #2 to have general instruction on use of artifactory. Something like >>>>>>>> >>>>>>>> 2. Pre-built NSS libraries from artifactory server >>>>>>>> If the value of system property test.nss.lib.paths is null then tests will try >>>>>>>> to download pre-built NSS libraries from artifactory server. >>>>>>>> Currently, test only looks for libraries for Windows and MacOSX on artifactory. >>>>>>>> Please note that, JIB jar MUST be present in classpath when downloading the libraries. >>>>>>>> >>>>>>>> Other changes look good to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Rajan >>>>>>>> >>>>>>>> On 8/14/18 4:40 AM, sha.jiang at oracle.com wrote: >>>>>>>>> Hi Max, >>>>>>>>> Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ >>>>>>>>> >>>>>>>>> The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. >>>>>>>>> Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on Windows and MacOSX. >>>>>>>>> I added a block to README for clarifying something on getting NSS libraries. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> John Jiang >>>>>>>>> On 2018/8/13 16:48, Weijun Wang wrote: >>>>>>>>>> Sorry, more questions: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Aug 13, 2018, at 3:36 PM, sha.jiang at oracle.com >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Is there an artifact server available on the open internet? >>>>>>>>>>>> >>>>>>>>>>> It's transparent to me. @Artifact tool delegates the downloading. >>>>>>>>>>> >>>>>>>>>> Have you tried running the test outside Oracle? >>>>>>>>>> >>>>>>>>>> Have you tried submitting the change to Mach5 as a non-Oracle developer? (i.e. using submit-repo) >>>>>>>>>> >>>>>>>>>> While I am glad to see these files removed from the repo, I hope people still have a chance to run the tests. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> > From oddbjornkvalsund at gmail.com Wed Aug 15 09:45:39 2018 From: oddbjornkvalsund at gmail.com (=?UTF-8?Q?Oddbj=C3=B8rn_Kvalsund?=) Date: Wed, 15 Aug 2018 11:45:39 +0200 Subject: JDK-6782021 In-Reply-To: References: <972ae00c-f669-7816-fbb0-44f8f48c9f54@oracle.com>

Message-ID: Hi, I had another look at this (using certificates and private keys from the LOCAL_MACHINE certificate store) yesterday and made another small discovery; in addition to passing the CERT_STORE_READONLY_FLAG to CertOpenStore(), it's also important to pass CRYPT_MACHINE_KEYSET in the 'dwFlags' parameter to CryptAquireContext()[1] if the referenced key is provided by the LOCAL_MACHINE certificate store or else you'll get a NTE_BAD_KEYSET ("Keyset does not exist") error. I've updated my wcsa[2] utility to account for this. FYI: If anyone wants to take a stab at modifying the underlying libsunmscapi provided by OpenJDK to enable accessing of certificates and keys in the LOCAL_MACHINE certificate store, you might find my sunmscapi-build-helper[3] useful, as it enables building the sunmscapi.dll (with debug symbols) in isolation without having to build the entire OpenJDK. References: [1] https://docs.microsoft.com/en-us/windows/desktop/api/wincrypt/nf-wincrypt-cryptacquirecontexta [2] https://github.com/oddbjornkvalsund/wcsa [3] https://github.com/oddbjornkvalsund/sunmscapi-build-helper Best regards, Oddbj?rn Kvalsund ons. 8. aug. 2018 kl. 23:19 skrev Oddbj?rn Kvalsund < oddbjornkvalsund at gmail.com>: > Thanks for the input, Bernd and Sean! I'm afraid submitting a patch for > this directly is a bit beyond my ability, but I'll happily discuss the > design of such a patch. > > Nelson D'Costa proposed a couple of possible solutions in JDK-6782021: > > > Either define a new store type like Windows-LOCALCOMPUTER, > > or also list the computer local certificates when using the Windows-MY > store type. > > My rudimentary understanding of the Windows certificate store architecture > after reading [1] is that Windows comes with a predefined set of > "collection stores" that can be opened with the WinCrypt function > CertOpenStore() using identifier tuples such as > CERT_SYSTEM_STORE_CURRENT_USER+MY, CERT_SYSTEM_STORE_LOCAL_MACHINE+CA etc. > and that these collection stores aggregate a set of "physical stores", > typically in the Windows registry. This model is thoroughly documented in > [1] (although complex), but mapping this identifier scheme to something > that can be used by JCA and KeyStore.getInstance() is slightly > tricky because of at least two concerns: > > 1) The SunMSCAPI JCA provider is widely used and although its "Windows-MY" > certificate store identifier scheme is flawed (it should have been > something like "Windows-CurrentUser-MY") we can't easily change it without > breaking things. > 2) Opening any certificate stores involving the > CERT_SYSTEM_STORE_LOCAL_MACHINE identifier (and most likely other > identifiers) requires administrator privileges or specifically opening the > store as read-only by passing CERT_STORE_READONLY_FLAG to CertOpenStore [2]. > > To offer the full flexibility of CertOpenStore() through > KeyStore.getInstance() seems like a grand undertaking involving an almost > infinite number of magic string identifiers, so my suggestion is as follows: > > 1) Introduce the new identifiers Windows-CurrentUser-MY, > Windows-CurrentUser-ROOT, Windows-LocalMachine-MY and > Windows-LocalMachine-ROOT. These seem to be the most requested, but the > identifier scheme allows for more esoteric additions such as > Windows-Services--MY down the line. > 2) Make Windows-MY and Windows-ROOT be aliases for Windows-CurrentUser-MY > and Windows-CurrentUser-ROOT to maintain backward compatibility. > 3) Attempt to open Windows-LocalMachine-MY and Windows-LocalMachine-ROOT > in the default read-write mode, but fallback to read-only if read-write > mode fails. This will transparently enable write operations for privileged > users, while unprivileged users will get an exception when attempting to > write to the store. > > References: > [1] > https://docs.microsoft.com/en-us/windows/desktop/seccrypto/system-store-locations > [2] > https://docs.microsoft.com/en-us/windows/desktop/api/wincrypt/nf-wincrypt-certopenstore > > Best regards, > Oddbj?rn Kvalsund > > ons. 8. aug. 2018 kl. 14:04 skrev Bernd Eckenfels >: > >> Hello, >> >> What also should be mentioned is that the old CAPI clients cannot access >> CNG Keys. Which is especially a pity since only the new keys benefit from >> the cryptographic process isolation (not to mention the confusion that it?s >> hard to see which provide hosts them) >> >> Gruss >> Bernd >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> ------------------------------ >> *Von:* -980814368m Auftrag von >> *Gesendet:* Mittwoch, August 8, 2018 12:35 PM >> *An:* Oddbj?rn Kvalsund; security-dev at openjdk.java.net >> *Betreff:* Re: JDK-6782021 >> >> Vinnie is not working on security-libs any more and I think the JBS >> report should be marked as unassigned. If any contributors want to suggest >> a patch, then I think it can be reviewed on this list! >> >> regards, >> Sean. >> >> On 07/08/2018 06:36, Oddbj?rn Kvalsund wrote: >> >> Hi, >> >> I was just bit by this issue [JDK-6782021] It is not possible to read >> local computer certificates with the SunMSCAPI provider >> and from >> StackOverflow I notice that several other people (see [1][2][3]) have come >> across the same problem. Coming up on the 10th anniversary for this issue; >> any chance we'll see some love for it? Or at least a comment on the issue >> on what timeline to expect and a list of workaround/alternative solutions >> for the meantime? >> >> Background: I'm working with a company having primarily Microsoft >> infrastructure and they have a routine where all Windows servers >> automatically receive new certificates/keys when the old ones expire. These >> certificates are installed in the "Local Computer ? Private" certificate >> store. They're quite fond of this system and hesitant to diverge from it, >> so my preferred option is to just "get with the program". To temporarily >> get around JDK-6782021 I created a small utility [5] that intercepts the >> JDKs call to 'CertOpenSystemStore' [4] and presents a read-only virtual >> certificate store combining all certificates and keys from the "Current >> User" and "Local Computer" certificate stores, but this may have unexpected >> implications that I've not yet uncovered, so I'd much prefer not having to >> do this. A more thorough solution would be to use the commercial Pheox >> JCAPI [6] product, but this is rather expensive and way overkill for what I >> (and most others, it seems) need. >> >> References: >> [1] >> https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java/51708360 >> [2] >> https://stackoverflow.com/questions/51205158/access-windows-local-machine-personal-keystore-with-java-sunmscapi >> [3] >> https://stackoverflow.com/questions/51193143/use-jna-to-get-local-machine-certificate >> [4] >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp >> [5] https://github.com/oddbjornkvalsund/wcsa >> [6] https://pheox.com/products/jcapi/ >> >> Best regards, >> Oddbj?rn Kvalsund >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Aug 15 14:40:19 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Aug 2018 10:40:19 -0400 Subject: Result: New Security Group Member: Adam Petcher Message-ID: The vote for Adam Petcher [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017727.html From sha.jiang at oracle.com Wed Aug 15 17:40:45 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 16 Aug 2018 01:40:45 +0800 Subject: RFR[11] JDK-8209537: Two security tests failed after JDK-8164639 due to dependency was missed Message-ID: <53ba70f0-b7fd-e692-0fb7-efcd546a259e@oracle.com> Hi, JDK-8164639 removed NSS libs from repo and added @Artifact in /test/lib to PKCS11Test.java as dependency. Some tests outside of sun/security/pkcs11 are also affected. So they have to be modified accordingly. Webrev: http://cr.openjdk.java.net/~jjiang/8209537/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8209537 Have run all tier2 tests with this fix. The result is green. Best regards, John Jiang From rajan.halade at oracle.com Wed Aug 15 17:46:24 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 15 Aug 2018 10:46:24 -0700 Subject: RFR[11] JDK-8209537: Two security tests failed after JDK-8164639 due to dependency was missed In-Reply-To: <53ba70f0-b7fd-e692-0fb7-efcd546a259e@oracle.com> References: <53ba70f0-b7fd-e692-0fb7-efcd546a259e@oracle.com> Message-ID: <4d34ee26-4070-6661-b514-cd21487edc76@oracle.com> Looks good! Please file a new bug for autotest.sh to see if we can support macos. Thanks, Rajan On 8/15/18 10:40 AM, sha.jiang at oracle.com wrote: > Hi, > JDK-8164639 removed NSS libs from repo and added @Artifact in > /test/lib to PKCS11Test.java as dependency. > Some tests outside of sun/security/pkcs11 are also affected. So they > have to be modified accordingly. > > Webrev: http://cr.openjdk.java.net/~jjiang/8209537/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8209537 > > Have run all tier2 tests with this fix. The result is green. > > Best regards, > John Jiang > From sean.mullan at oracle.com Wed Aug 15 20:32:29 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Aug 2018 16:32:29 -0400 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings -- now RFR for 8209304: Deprecate serialVersionUID fields in interfaces In-Reply-To: References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com> Message-ID: <906e7e63-cc49-71ae-74d2-7a4829b4cc0e@oracle.com> On 8/9/18 2:36 PM, joe darcy wrote: > Security libs team, for > > src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java > > > I added a separate @Deprecated annotation for the serialVersionUID field > even though the interface itself is already deprecated. That interface's > javadoc states: > > ? 41? * @deprecated Sun JDK internal use only --- WILL BE REMOVED in a > future > ? 42? * release. > > If you like, as part of this changeset I can upgrade (downgrade?) the > @Deprecated annotation for this class to forRemoval=true. Let's just leave it as is for now (don't add forRemoval=true). We don't have any upcoming plans to remove or replace this class. Thanks, Sean From valerie.peng at oracle.com Wed Aug 15 23:02:41 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 15 Aug 2018 16:02:41 -0700 Subject: RFR[11]: release note for JDK-7007966 "Add Brainpool ECC support (RFC 5639)" Message-ID: <32556c55-2460-e519-7186-eca79c652e47@oracle.com> Hi Adam, Can you please help reviewing the release note for JDK-7007966 "Add Brainpool ECC support (RFC 5639)" The release note subtask can be found at: https://bugs.openjdk.java.net/browse/JDK-8208580 Thanks, Valerie From adam.petcher at oracle.com Thu Aug 16 15:10:24 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 16 Aug 2018 11:10:24 -0400 Subject: RFR[11]: release note for JDK-7007966 "Add Brainpool ECC support (RFC 5639)" In-Reply-To: <32556c55-2460-e519-7186-eca79c652e47@oracle.com> References: <32556c55-2460-e519-7186-eca79c652e47@oracle.com> Message-ID: <9c681c70-42aa-dbfc-7d9d-84d9e112b3f9@oracle.com> This is in JCA only, and not yet integrated into SunJSSE, right? Either way, I think it would be helpful to add a sentence saying whether these curves are supported in SunJSSE. I expect that people will wonder about this when reading the release note. On 8/15/2018 7:02 PM, Valerie Peng wrote: > Hi Adam, > > Can you please help reviewing the release note for JDK-7007966 "Add > Brainpool ECC support (RFC 5639)" > The release note subtask can be found at: > https://bugs.openjdk.java.net/browse/JDK-8208580 > > Thanks, > Valerie From sean.coffey at oracle.com Thu Aug 16 16:53:43 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 16 Aug 2018 17:53:43 +0100 Subject: RFR: JDK-8209129 :Further improvements to cipher buffer management In-Reply-To: <99fd1e16-4818-cadd-bade-d33cd6625169@oracle.com> References: <1bd9e050-409a-3b6d-26e8-62b909d6a306@oracle.com> <31BDBAEE-DF81-4D97-A7DA-F0CD188D2FB1@oracle.com> <99fd1e16-4818-cadd-bade-d33cd6625169@oracle.com> Message-ID: <85f9e373-657d-3672-00b7-5466132e58c5@oracle.com> Find new webrev here Max : http://cr.openjdk.java.net/~coffeys/webrev.8209129.v2/webrev/ regards : > MD4.java: > > ? 110???? void implReset() { > > ? Add @Override. There's a whole bunch of annotations missing in these files, I'd prefer if it was fixed up with different bug ID. another thing we're to be cautious about is the nulling out of values returned from some Key's such as PBEKey subclasses. We're assuming that getPassword() returns cloned copies. That should be the case for any production fit code. Edit to test/jdk/com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java was necessary as a result. regards, Sean. On 10/08/2018 15:18, Se?n Coffey wrote: > Thanks for the review Max - comments inline.. > > Regards, > Sean. > > On 10/08/18 11:53, Weijun Wang wrote: >> HmacPKCS12PBESHA1.java: >> >> ?? 76???????????? byte[] passwdBytes = key.getEncoded(); >> ?? 77???????????? if ((passwdBytes == null) || >> ?? 78???????????????? !(key.getAlgorithm().regionMatches(true, 0, >> "PBE", 0, 3))) { >> ?? 79???????????????? throw new InvalidKeyException("Missing password"); >> ?? 80???????????? } >> >> ? Please also cleanup passwdBytes. Maybe divide the if check above >> into 2 to avoid passwdBytes being assigned but algorithm is not PBE. > Yes - I had thought about refactoring this code during edits. Will > make that change. >> >> ? 132???????? Arrays.fill(passwdChars, '0'); >> >> ? In a finally block? >> >> PBES1Core.java: >> >> ? 250???????? Arrays.fill(passwdBytes, (byte) 0x00); >> >> ? In a finally block? >> >> PBES2Core.java: >> >> ? 273???????? Arrays.fill(passwdChars, ' '); >> ? 274???????? Arrays.fill(passwdBytes, (byte)0x00); >> >> ? In a finally block? > Yes - makes sense to capture above in finally blocks. Will re-factor. >> >> PBKDF2KeyImpl.java: >> >> ?? 88???????? if (passwd == null) { >> ?? 89???????????? // Should allow an empty password. >> ?? 90???????????? this.passwd = new char[0]; >> ?? 91???????? } else { >> ?? 92???????????? this.passwd = passwd.clone(); >> ?? 93???????? } >> ?? 94???????? // Convert the password from char[] to byte[] >> ?? 95???????? byte[] passwdBytes = getPasswordBytes(this.passwd); >> ?? 96???????? // remove local copy >> ?? 97???????? Arrays.fill(passwd, '0'); >> >> ? Strange, why passwd.clone()? > Not sure - it's original behaviour. I'll check if it makes sense to > change. >> >> ? 129???????? Arrays.fill(passwdBytes, (byte)0x00); >> >> ? In a finally block? >> >> PBMAC1Core.java: >> >> ? 111???????????? byte[] passwdBytes = key.getEncoded(); >> ? 112???????????? if ((passwdBytes == null) || >> ? 113???????????????? !(key.getAlgorithm().regionMatches(true, 0, >> "PBE", 0, 3))) { >> ? 114???????????????? throw new InvalidKeyException("Missing password"); >> ? 115???????????? } >> >> ? 170???????? Arrays.fill(passwdChars, ' '); >> >> ? Same comments as for HmacPKCS12PBESHA1.java. >> >> PKCS12PBECipherCore.java: >> >> ? 262???????? char[] passwdChars = null; >> >> ? Deal with the same way as in PBMAC1Core.java? >> >> MD4.java: >> >> ? 110???? void implReset() { >> >> ? Add @Override. > All above comments make sense. I've come across one other possible > issue in MessageDigest functionality. I'm debugging that to be sure. > Will get a new webrev out once that's done. > > regards, > Sean. >> >> Thanks >> Max >> >> >>> On Aug 9, 2018, at 6:42 PM, Se?n Coffey wrote: >>> >>> Adding RFR to title.. >>> >>> On 09/08/2018 11:37, Se?n Coffey wrote: >>>> I've been looking further at how private/temporary buffers are used >>>> in cipher/keystore management and identified some more areas that >>>> could benefit with a more aggressive nulling out of contents. >>>> >>>> I've been testing through use of stepping through debugging >>>> sessions while setting/getting keys and capturing process memory >>>> via tooling like gcore. >>>> >>>> JBS report : https://bugs.openjdk.java.net/browse/JDK-8209129 >>>> >>>> webrev : >>>> http://cr.openjdk.java.net/~coffeys/webrev.8209129.v1/webrev/index.html >>>> >>>> >>>> TCK and regression tests are green. >>>> >>>> regards, >>>> Sean. >>>> > From valerie.peng at oracle.com Fri Aug 17 00:28:09 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 16 Aug 2018 17:28:09 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> References:

<6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> Message-ID: <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> Hi Martin, Since there is no regression test for this test, you will need to add a "noreg-xxx" label to the bug record. For this issue, it'll probably be "noreg-hard". To understand the changes better, please find my questions and some review comments below: - line 397: It's incorrect to change initialize() to ensureInitialized(). If the cipher object were to be initialized twice with two different keys, you need to re-initialize again. - line 471: Why do you change it to Throwable from PKCS11Exception? - line 99: comment is somewhat unclear. typo: "temporal" should be "temporary". - line 148-149: JDK-8165996 has been fixed. This does not apply now, does it? - You changed the constructors of all the P11Key-related classes to take an additional boolean argument "tmpNativeKey". However, this boolean argument is only used when the underlying token is "NSS". Why limiting to NSS only? It seems that all callers except for PKCS11 KeyStore pass true for "tmpNativeKey". When "tmpNativeKey" is true, the keyID handle first destroyed in constructor and later created again (ref count == 1) and destroyed (when ref count drops to 0). This replaced the PhantomReference approach in SessionKeyRef class, right? Now both approaches seem to be used and key destruction is taking places at different methods. I think we should clarify the cleanup model and perhaps refactor the code so it's easier which approach is in use. Or grouping all these cleanup-related fields/variables into a separate class for readability/clarity. - line 157-175: nativeKeyWrapperKeyID is a static variable, shouldn't it be synchronized on a class level object? - line 1343: the impl doesn't look right. Why do you call both removeObject() and addObject() here with the same check? - line 1363: the change seems incorrect, you should still call session.removeObject(). the call setKeyIDAndSession(0, null) does not lower the session object count. Thanks, Valerie On 8/7/2018 5:41 PM, Valerie Peng wrote: > > Hi Martin, > > Thanks for the update, I will resume the review on this one with your > latest webrev. > > BTW, there is no webrev.07 for your other fix, i.e. JDK-8029661, > right? Just checking. > > Regards, > Valerie > > On 8/3/2018 2:13 PM, Martin Balao wrote: >> Hi Valerie, >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/ >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip >> >> >> New in webrev 10: >> >> ?* Bug fix when private DSA/EC keys are sensitive >> ? * I found this bug removing "attributes = compatibility" entry in >> NSS configuration file so keys were CKA_SENSITIVE. >> ? * This is really an NSS bug when unwrapping ephemeral keys >> (NSC_UnwrapKey function), because CKA_NETSCAPE_DB attribute is >> required but not used/needed. There was a similar bug when creating >> objects (NSC_CreateObject function), fixed many years ago [1]. >> ? * In those cases in which the bug occurs (private keys, of DSA/EC >> type, sensitive and without CKA_NETSCAPE_DB attribute set), I store >> an empty CKA_NETSCAPE_DB attribute in the buffer that will later be >> used for key unwrapping. I'm not doing a C_SetAttributeValue call >> because keys are read-only. We can let users set CKA_NETSCAPE_DB >> attribute in NSS configuration file [2] but this would be a >> workaround on users side. >> ? * Changes in: >> ? ?* p11_keymgmt.c >> ? ? * L175-187, L212-214 and L275-278 >> >> ?* Bug fix when storing sensitive RSA keys in a keystore >> ? * CKA_NETSCAPE_DB attribute is not needed so we return it as null >> (instead of failing with an "Invalid algorithm" message) >> ? * Changes in: >> ? ?* P11KeyStore.java >> ? ? * L1909-1914 >> >> ?* Lines length was cut to improve code readability >> >> Regression tests on jdk/sun/security/pkcs11 category passed. I ran my >> internal test suite too, that covers the following services (with >> SunPKCS11 provider): Cipher, Signature, KeyAgreement, Digest, Mac, >> KeyGenerator, KeyPairGenerator and Keystore. >> >> Kind regards, >> Martin.- >> >> -- >> [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=309701#c6 >> >> [2] - >> https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/test/sun/security/pkcs11/fips/fips.cfg.shtml >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Aug 17 00:29:35 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 16 Aug 2018 17:29:35 -0700 Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings -- now RFR for 8209304: Deprecate serialVersionUID fields in interfaces In-Reply-To: <906e7e63-cc49-71ae-74d2-7a4829b4cc0e@oracle.com> References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com> <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com> <906e7e63-cc49-71ae-74d2-7a4829b4cc0e@oracle.com> Message-ID: <5B7616EF.5070207@oracle.com> Hi Sean, On 8/15/2018 1:32 PM, Sean Mullan wrote: > On 8/9/18 2:36 PM, joe darcy wrote: >> Security libs team, for >> >> src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java >> >> >> I added a separate @Deprecated annotation for the serialVersionUID >> field even though the interface itself is already deprecated. That >> interface's javadoc states: >> >> 41 * @deprecated Sun JDK internal use only --- WILL BE REMOVED in >> a future >> 42 * release. >> >> If you like, as part of this changeset I can upgrade (downgrade?) the >> @Deprecated annotation for this class to forRemoval=true. > > Let's just leave it as is for now (don't add forRemoval=true). We > don't have any upcoming plans to remove or replace this class. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8209317 and I'll proceed in getting this fix into JDK 12. Thanks, -Joe From valerie.peng at oracle.com Fri Aug 17 01:27:03 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 16 Aug 2018 18:27:03 -0700 Subject: RFR[11]: release note for JDK-7007966 "Add Brainpool ECC support (RFC 5639)" In-Reply-To: <9c681c70-42aa-dbfc-7d9d-84d9e112b3f9@oracle.com> References: <32556c55-2460-e519-7186-eca79c652e47@oracle.com> <9c681c70-42aa-dbfc-7d9d-84d9e112b3f9@oracle.com> Message-ID: Sure, I've updated the release note. Please let me know if you have other suggestions/feedbacks. https://bugs.openjdk.java.net/browse/JDK-8208580 Thanks, Valerie On 8/16/2018 8:10 AM, Adam Petcher wrote: > This is in JCA only, and not yet integrated into SunJSSE, right? > Either way, I think it would be helpful to add a sentence saying > whether these curves are supported in SunJSSE. I expect that people > will wonder about this when reading the release note. > > > On 8/15/2018 7:02 PM, Valerie Peng wrote: >> Hi Adam, >> >> Can you please help reviewing the release note for JDK-7007966 "Add >> Brainpool ECC support (RFC 5639)" >> The release note subtask can be found at: >> https://bugs.openjdk.java.net/browse/JDK-8208580 >> >> Thanks, >> Valerie > From sean.coffey at oracle.com Fri Aug 17 09:13:03 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 17 Aug 2018 10:13:03 +0100 Subject: RFR: JDK-8208675: Remove legacy sun.security.key.serial.interop property Message-ID: "sun.security.key.serial.interop" is an old JDK 1.4 -1.5 interoperability property. It can be safely removed now. JBS report : https://bugs.openjdk.java.net/browse/JDK-8208675 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8208675/webrev/ regards, Sean. From adam.petcher at oracle.com Fri Aug 17 14:12:03 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 17 Aug 2018 10:12:03 -0400 Subject: RFR[11]: release note for JDK-7007966 "Add Brainpool ECC support (RFC 5639)" In-Reply-To: References: <32556c55-2460-e519-7186-eca79c652e47@oracle.com> <9c681c70-42aa-dbfc-7d9d-84d9e112b3f9@oracle.com> Message-ID: <3ab3bfe0-9348-bc58-5ac4-637dfd83fa4c@oracle.com> No more suggestions. Looks good to me. On 8/16/2018 9:27 PM, Valerie Peng wrote: > > Sure, I've updated the release note. Please let me know if you have > other suggestions/feedbacks. > > https://bugs.openjdk.java.net/browse/JDK-8208580 > > Thanks, > > Valerie > > > > On 8/16/2018 8:10 AM, Adam Petcher wrote: >> This is in JCA only, and not yet integrated into SunJSSE, right? >> Either way, I think it would be helpful to add a sentence saying >> whether these curves are supported in SunJSSE. I expect that people >> will wonder about this when reading the release note. >> >> >> On 8/15/2018 7:02 PM, Valerie Peng wrote: >>> Hi Adam, >>> >>> Can you please help reviewing the release note for JDK-7007966 "Add >>> Brainpool ECC support (RFC 5639)" >>> The release note subtask can be found at: >>> https://bugs.openjdk.java.net/browse/JDK-8208580 >>> >>> Thanks, >>> Valerie >> > From sean.mullan at oracle.com Fri Aug 17 14:16:35 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Aug 2018 10:16:35 -0400 Subject: RFR: JDK-8208675: Remove legacy sun.security.key.serial.interop property In-Reply-To: References: Message-ID: <612dceaf-04b7-2c3b-4c08-c4956db1949e@oracle.com> Looks good. --Sean On 8/17/18 5:13 AM, Se?n Coffey wrote: > "sun.security.key.serial.interop" is an old JDK 1.4 -1.5 > interoperability property. It can be safely removed now. > > JBS report : https://bugs.openjdk.java.net/browse/JDK-8208675 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8208675/webrev/ > > regards, > Sean. From weijun.wang at oracle.com Fri Aug 17 14:56:07 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Aug 2018 22:56:07 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: <9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> Message-ID: <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> Please take a review at the updated webrev at http://cr.openjdk.java.net/~weijun/8193859/webrev.01 Changes only in doc, including 1) The "2018-8-15 updates" in the CSR [1] 2) formatting Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8193887 > On Aug 14, 2018, at 11:19 PM, Roger Riggs wrote: > > Hi, > > On 8/14/2018 10:59 AM, Weijun Wang wrote: >> >> s/initial process-wide filter/system filter/? > > yes > > Roger > >> >> --Max >> >>> [1] 8202675 Replace process-wide terminology in serial filtering to be consistent >>> >>> Regards, Roger >>> >> > From jamil.j.nimeh at oracle.com Fri Aug 17 15:45:58 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 17 Aug 2018 08:45:58 -0700 Subject: RFR - 8203614: Java API SSLEngine example code needs correction Message-ID: <9cbe35c8-b540-74d0-de4a-4be27e69b1a3@oracle.com> Hello all, This is a simple doc-only one-liner that fixes the sample code in SSLEngine to use the correct ByteBuffer in the capacity size check. webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8203614/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8203614 Thanks, --Jamil From roger.riggs at oracle.com Fri Aug 17 17:05:30 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 17 Aug 2018 13:05:30 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> Message-ID: <5a6b8ed9-700f-43f6-941a-0c387887e34e@oracle.com> Look fine. Thanks, Roger On 8/17/18 10:56 AM, Weijun Wang wrote: > Please take a review at the updated webrev at > > http://cr.openjdk.java.net/~weijun/8193859/webrev.01 > > Changes only in doc, including > > 1) The "2018-8-15 updates" in the CSR [1] > > 2) formatting > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8193887 > >> On Aug 14, 2018, at 11:19 PM, Roger Riggs wrote: >> >> Hi, >> >> On 8/14/2018 10:59 AM, Weijun Wang wrote: >>> s/initial process-wide filter/system filter/? >> yes >> >> Roger >> >>> --Max >>> >>>> [1] 8202675 Replace process-wide terminology in serial filtering to be consistent >>>> >>>> Regards, Roger >>>> From anthony.scarpino at oracle.com Sat Aug 18 00:53:19 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 17 Aug 2018 17:53:19 -0700 Subject: RFR - 8203614: Java API SSLEngine example code needs correction In-Reply-To: <9cbe35c8-b540-74d0-de4a-4be27e69b1a3@oracle.com> References: <9cbe35c8-b540-74d0-de4a-4be27e69b1a3@oracle.com> Message-ID: <66040F5E-5A06-4543-BB0B-4B176DD86782@oracle.com> Looks fine. Tony > On Aug 17, 2018, at 8:45 AM, Jamil Nimeh wrote: > > Hello all, > > This is a simple doc-only one-liner that fixes the sample code in SSLEngine to use the correct ByteBuffer in the capacity size check. > > webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8203614/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8203614 > > Thanks, > --Jamil From bradford.wetmore at oracle.com Sat Aug 18 04:04:15 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 17 Aug 2018 21:04:15 -0700 Subject: RFR - 8203614: Java API SSLEngine example code needs correction In-Reply-To: <66040F5E-5A06-4543-BB0B-4B176DD86782@oracle.com> References: <9cbe35c8-b540-74d0-de4a-4be27e69b1a3@oracle.com> <66040F5E-5A06-4543-BB0B-4B176DD86782@oracle.com> Message-ID: <4b6a3249-39e5-9e85-00f6-21939c59651a@oracle.com> Looks good. Brad On 8/17/2018 5:53 PM, Anthony Scarpino wrote: > Looks fine. > > Tony > >> On Aug 17, 2018, at 8:45 AM, Jamil Nimeh wrote: >> >> Hello all, >> >> This is a simple doc-only one-liner that fixes the sample code in SSLEngine to use the correct ByteBuffer in the capacity size check. >> >> webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8203614/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8203614 >> >> Thanks, >> --Jamil > From jamil.j.nimeh at oracle.com Mon Aug 20 01:06:02 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 19 Aug 2018 18:06:02 -0700 Subject: RFR: Disable all DES cipher suites Message-ID: <3958cb94-02d7-82e8-8383-822fece98549@oracle.com> Hello all, This change adds all DES cipher suites to the jdk.tls.disabledAlgorithms Security property.? This will have the effect of making all DES-based suites unavailable to SunJSSE SSLSocket and SSLEngine instances, even if explicitly enabled using calls like SSLEngine.setEnabledCipherSuites() or SSLSocket.setEnabledCipherSuites().? Users wishing to re-enable these suites for legacy purposes must first alter the jdk.tls.disabledAlgorithms property in the java.security file. Please note that prior to this change, DES-based suites were available, but not enabled by default on SSLSocket and SSLEngine objects.? This change just makes these suites no longer available without further intervention. This change also removes RC4_40 from this Security property as it is already superseded by the RC4 identifier.? It also cleans up a cut-and-paste bug in a couple of the RC4_40 export suites (those suites are disabled already). Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8208350 CSR: https://bugs.openjdk.java.net/browse/JDK-8209318 Thanks, --Jamil From sean.mullan at oracle.com Mon Aug 20 14:19:22 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 20 Aug 2018 10:19:22 -0400 Subject: RFR: Disable all DES cipher suites In-Reply-To: <3958cb94-02d7-82e8-8383-822fece98549@oracle.com> References: <3958cb94-02d7-82e8-8383-822fece98549@oracle.com> Message-ID: Looks good, just a few minor comments: CustomizedCipherSuites.java - should have both years (2016, 2018) on copyright NoDesRC4CiphSuite.java - does this need to be run in othervm mode? It doesn't look like you are setting any properties dynamically. Lines 30-31 should also be removed, if so. - add comments describing what the testEngAddDisabled method does (similar to the testEngOnlyDisabled method) --Sean On 8/19/18 9:06 PM, Jamil Nimeh wrote: > Hello all, > > This change adds all DES cipher suites to the jdk.tls.disabledAlgorithms > Security property.? This will have the effect of making all DES-based > suites unavailable to SunJSSE SSLSocket and SSLEngine instances, even if > explicitly enabled using calls like SSLEngine.setEnabledCipherSuites() > or SSLSocket.setEnabledCipherSuites().? Users wishing to re-enable these > suites for legacy purposes must first alter the > jdk.tls.disabledAlgorithms property in the java.security file. > > Please note that prior to this change, DES-based suites were available, > but not enabled by default on SSLSocket and SSLEngine objects.? This > change just makes these suites no longer available without further > intervention. > > This change also removes RC4_40 from this Security property as it is > already superseded by the RC4 identifier.? It also cleans up a > cut-and-paste bug in a couple of the RC4_40 export suites (those suites > are disabled already). > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8208350 > CSR: https://bugs.openjdk.java.net/browse/JDK-8209318 > > Thanks, > --Jamil From jamil.j.nimeh at oracle.com Mon Aug 20 14:33:28 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 20 Aug 2018 07:33:28 -0700 Subject: RFR: Disable all DES cipher suites In-Reply-To: References: <3958cb94-02d7-82e8-8383-822fece98549@oracle.com> Message-ID: I can fix the copyright, no problem.? Good catch on the othervm - the original form of the test did set properties but it seemed better to not set them explicitly and just use the new defaults. One would not expect to ever remove DES and RC4 from the disabledAlgorithms identifier set, at least in our delivered code. It doesn't need to be run in othervm mode.? And I can comment those other two tests. Thanks, --Jamil On 8/20/2018 7:19 AM, Sean Mullan wrote: > Looks good, just a few minor comments: > > CustomizedCipherSuites.java > > - should have both years (2016, 2018) on copyright > > NoDesRC4CiphSuite.java > > - does this need to be run in othervm mode? It doesn't look like you > are setting any properties dynamically. Lines 30-31 should also be > removed, if so. > > - add comments? describing what the testEngAddDisabled method does > (similar to the testEngOnlyDisabled method) > > --Sean > > On 8/19/18 9:06 PM, Jamil Nimeh wrote: >> Hello all, >> >> This change adds all DES cipher suites to the >> jdk.tls.disabledAlgorithms Security property.? This will have the >> effect of making all DES-based suites unavailable to SunJSSE >> SSLSocket and SSLEngine instances, even if explicitly enabled using >> calls like SSLEngine.setEnabledCipherSuites() or >> SSLSocket.setEnabledCipherSuites().? Users wishing to re-enable these >> suites for legacy purposes must first alter the >> jdk.tls.disabledAlgorithms property in the java.security file. >> >> Please note that prior to this change, DES-based suites were >> available, but not enabled by default on SSLSocket and SSLEngine >> objects.? This change just makes these suites no longer available >> without further intervention. >> >> This change also removes RC4_40 from this Security property as it is >> already superseded by the RC4 identifier.? It also cleans up a >> cut-and-paste bug in a couple of the RC4_40 export suites (those >> suites are disabled already). >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208350 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8209318 >> >> Thanks, >> --Jamil From xuelei.fan at oracle.com Mon Aug 20 16:01:37 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 20 Aug 2018 09:01:37 -0700 Subject: RFR: Disable all DES cipher suites In-Reply-To: References: <3958cb94-02d7-82e8-8383-822fece98549@oracle.com>

Message-ID: NoDesRC4CiphSuite.java ---------------------- Please move line 30-31 out of the test comment block. The two lines will be parsed as part of the run parameters. I would prefer to use othervm mode. Otherwise, once there is a test case does not run with othervm and changes the context, this test may be not reliable any more. If this test failed, it is hard to evaluate the root cause if it is impacted by other test case. I may prefer to use System.err for new test case as the SunJSSE default debug log now is dumped to System.err. Dumps on System.out and System.err are not synchronized. Using the same stream may make the debug log easier to read. Thanks, Xuelei On 8/20/2018 7:33 AM, Jamil Nimeh wrote: > I can fix the copyright, no problem.? Good catch on the othervm - the > original form of the test did set properties but it seemed better to not > set them explicitly and just use the new defaults. One would not expect > to ever remove DES and RC4 from the disabledAlgorithms identifier set, > at least in our delivered code. It doesn't need to be run in othervm > mode.? And I can comment those other two tests. > > Thanks, > --Jamil > > On 8/20/2018 7:19 AM, Sean Mullan wrote: >> Looks good, just a few minor comments: >> >> CustomizedCipherSuites.java >> >> - should have both years (2016, 2018) on copyright >> >> NoDesRC4CiphSuite.java >> >> - does this need to be run in othervm mode? It doesn't look like you >> are setting any properties dynamically. Lines 30-31 should also be >> removed, if so. >> >> - add comments? describing what the testEngAddDisabled method does >> (similar to the testEngOnlyDisabled method) >> >> --Sean >> >> On 8/19/18 9:06 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This change adds all DES cipher suites to the >>> jdk.tls.disabledAlgorithms Security property.? This will have the >>> effect of making all DES-based suites unavailable to SunJSSE >>> SSLSocket and SSLEngine instances, even if explicitly enabled using >>> calls like SSLEngine.setEnabledCipherSuites() or >>> SSLSocket.setEnabledCipherSuites().? Users wishing to re-enable these >>> suites for legacy purposes must first alter the >>> jdk.tls.disabledAlgorithms property in the java.security file. >>> >>> Please note that prior to this change, DES-based suites were >>> available, but not enabled by default on SSLSocket and SSLEngine >>> objects.? This change just makes these suites no longer available >>> without further intervention. >>> >>> This change also removes RC4_40 from this Security property as it is >>> already superseded by the RC4 identifier.? It also cleans up a >>> cut-and-paste bug in a couple of the RC4_40 export suites (those >>> suites are disabled already). >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.01/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208350 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8209318 >>> >>> Thanks, >>> --Jamil > From jamil.j.nimeh at oracle.com Mon Aug 20 17:42:23 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 20 Aug 2018 10:42:23 -0700 Subject: RFR: Disable all DES cipher suites In-Reply-To: References: <3958cb94-02d7-82e8-8383-822fece98549@oracle.com>

Message-ID: <291fe7d6-574b-9526-f533-791cecc13d7f@oracle.com> Hello all, updated webrev: * Copyright and comment fixes * Leaving NoDesRC4CiphSuite.java in othervm mode per Xuelei's concerns * Changed output to use System.err so it outputs on the same stream as SSLLogger. http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.02 Thanks, --Jamil On 08/20/2018 09:01 AM, Xue-Lei Fan wrote: > NoDesRC4CiphSuite.java > ---------------------- > Please move line 30-31 out of the test comment block.? The two lines > will be parsed as part of the run parameters. > > I would prefer to use othervm mode.? Otherwise, once there is a test > case does not run with othervm and changes the context, this test may > be not reliable any more.? If this test failed, it is hard to evaluate > the root cause if it is impacted by other test case. > > I may prefer to use System.err for new test case as the SunJSSE > default debug log now is dumped to System.err.?? Dumps on System.out > and System.err are not synchronized.? Using the same stream may make > the debug log easier to read. > > Thanks, > Xuelei > > > On 8/20/2018 7:33 AM, Jamil Nimeh wrote: >> I can fix the copyright, no problem.? Good catch on the othervm - the >> original form of the test did set properties but it seemed better to >> not set them explicitly and just use the new defaults. One would not >> expect to ever remove DES and RC4 from the disabledAlgorithms >> identifier set, at least in our delivered code. It doesn't need to be >> run in othervm mode.? And I can comment those other two tests. >> >> Thanks, >> --Jamil >> >> On 8/20/2018 7:19 AM, Sean Mullan wrote: >>> Looks good, just a few minor comments: >>> >>> CustomizedCipherSuites.java >>> >>> - should have both years (2016, 2018) on copyright >>> >>> NoDesRC4CiphSuite.java >>> >>> - does this need to be run in othervm mode? It doesn't look like you >>> are setting any properties dynamically. Lines 30-31 should also be >>> removed, if so. >>> >>> - add comments? describing what the testEngAddDisabled method does >>> (similar to the testEngOnlyDisabled method) >>> >>> --Sean >>> >>> On 8/19/18 9:06 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This change adds all DES cipher suites to the >>>> jdk.tls.disabledAlgorithms Security property.? This will have the >>>> effect of making all DES-based suites unavailable to SunJSSE >>>> SSLSocket and SSLEngine instances, even if explicitly enabled using >>>> calls like SSLEngine.setEnabledCipherSuites() or >>>> SSLSocket.setEnabledCipherSuites().? Users wishing to re-enable >>>> these suites for legacy purposes must first alter the >>>> jdk.tls.disabledAlgorithms property in the java.security file. >>>> >>>> Please note that prior to this change, DES-based suites were >>>> available, but not enabled by default on SSLSocket and SSLEngine >>>> objects.? This change just makes these suites no longer available >>>> without further intervention. >>>> >>>> This change also removes RC4_40 from this Security property as it >>>> is already superseded by the RC4 identifier.? It also cleans up a >>>> cut-and-paste bug in a couple of the RC4_40 export suites (those >>>> suites are disabled already). >>>> >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.01/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208350 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8209318 >>>> >>>> Thanks, >>>> --Jamil >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Aug 20 17:43:50 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 20 Aug 2018 10:43:50 -0700 Subject: RFR: Disable all DES cipher suites In-Reply-To: <291fe7d6-574b-9526-f533-791cecc13d7f@oracle.com> References: <3958cb94-02d7-82e8-8383-822fece98549@oracle.com>

<291fe7d6-574b-9526-f533-791cecc13d7f@oracle.com> Message-ID: <69f806d8-499a-9b9f-50bf-9fff0524c184@oracle.com> Looks fine to me. Thanks, Xuelei On 8/20/2018 10:42 AM, Jamil Nimeh wrote: > Hello all, updated webrev: > > * Copyright and comment fixes > * Leaving NoDesRC4CiphSuite.java in othervm mode per Xuelei's concerns > * Changed output to use System.err so it outputs on the same stream as > SSLLogger. > > http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.02 > > Thanks, > > --Jamil > > On 08/20/2018 09:01 AM, Xue-Lei Fan wrote: >> NoDesRC4CiphSuite.java >> ---------------------- >> Please move line 30-31 out of the test comment block.? The two lines >> will be parsed as part of the run parameters. >> >> I would prefer to use othervm mode.? Otherwise, once there is a test >> case does not run with othervm and changes the context, this test may >> be not reliable any more.? If this test failed, it is hard to evaluate >> the root cause if it is impacted by other test case. >> >> I may prefer to use System.err for new test case as the SunJSSE >> default debug log now is dumped to System.err.?? Dumps on System.out >> and System.err are not synchronized.? Using the same stream may make >> the debug log easier to read. >> >> Thanks, >> Xuelei >> >> >> On 8/20/2018 7:33 AM, Jamil Nimeh wrote: >>> I can fix the copyright, no problem.? Good catch on the othervm - the >>> original form of the test did set properties but it seemed better to >>> not set them explicitly and just use the new defaults. One would not >>> expect to ever remove DES and RC4 from the disabledAlgorithms >>> identifier set, at least in our delivered code. It doesn't need to be >>> run in othervm mode.? And I can comment those other two tests. >>> >>> Thanks, >>> --Jamil >>> >>> On 8/20/2018 7:19 AM, Sean Mullan wrote: >>>> Looks good, just a few minor comments: >>>> >>>> CustomizedCipherSuites.java >>>> >>>> - should have both years (2016, 2018) on copyright >>>> >>>> NoDesRC4CiphSuite.java >>>> >>>> - does this need to be run in othervm mode? It doesn't look like you >>>> are setting any properties dynamically. Lines 30-31 should also be >>>> removed, if so. >>>> >>>> - add comments? describing what the testEngAddDisabled method does >>>> (similar to the testEngOnlyDisabled method) >>>> >>>> --Sean >>>> >>>> On 8/19/18 9:06 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> This change adds all DES cipher suites to the >>>>> jdk.tls.disabledAlgorithms Security property.? This will have the >>>>> effect of making all DES-based suites unavailable to SunJSSE >>>>> SSLSocket and SSLEngine instances, even if explicitly enabled using >>>>> calls like SSLEngine.setEnabledCipherSuites() or >>>>> SSLSocket.setEnabledCipherSuites().? Users wishing to re-enable >>>>> these suites for legacy purposes must first alter the >>>>> jdk.tls.disabledAlgorithms property in the java.security file. >>>>> >>>>> Please note that prior to this change, DES-based suites were >>>>> available, but not enabled by default on SSLSocket and SSLEngine >>>>> objects.? This change just makes these suites no longer available >>>>> without further intervention. >>>>> >>>>> This change also removes RC4_40 from this Security property as it >>>>> is already superseded by the RC4 identifier.? It also cleans up a >>>>> cut-and-paste bug in a couple of the RC4_40 export suites (those >>>>> suites are disabled already). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8208350/webrev.01/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208350 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8209318 >>>>> >>>>> Thanks, >>>>> --Jamil >>> > From sean.mullan at oracle.com Mon Aug 20 18:06:52 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 20 Aug 2018 14:06:52 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> Message-ID: The SealedObjectFilter and SignedObjectFilter tests are almost the same, maybe they should be combined? Also, can you add a test to check that a SecurityException is thrown when an SM is enabled and the SerializablePermission("serialFilter") has not been granted? - SignedObject 69 * called, the {@link ObjectInputFilter.Config#getSerialFilter() 70 * system filter} is used instead. "used instead" sounds like the getSerialFilter method returns the object. Suggest being more specific and saying something like: "the {@link ObjectInputFilter.Config#getSerialFilter() system filter} is called to validate the object before it is returned." - SealedObject 92 * is called, the {@link ObjectInputFilter.Config#getSerialFilter() 93 * system filter} is used instead. Same comment as above on the wording. --Sean On 8/17/18 10:56 AM, Weijun Wang wrote: > Please take a review at the updated webrev at > > http://cr.openjdk.java.net/~weijun/8193859/webrev.01 > > Changes only in doc, including > > 1) The "2018-8-15 updates" in the CSR [1] > > 2) formatting > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8193887 > >> On Aug 14, 2018, at 11:19 PM, Roger Riggs wrote: >> >> Hi, >> >> On 8/14/2018 10:59 AM, Weijun Wang wrote: >>> >>> s/initial process-wide filter/system filter/? >> >> yes >> >> Roger >> >>> >>> --Max >>> >>>> [1] 8202675 Replace process-wide terminology in serial filtering to be consistent >>>> >>>> Regards, Roger >>>> >>> >> > From bradford.wetmore at oracle.com Mon Aug 20 20:33:49 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 20 Aug 2018 13:33:49 -0700 Subject: RFR11(s): 8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy Message-ID: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com> Hi Xuelei, Please review this P1 bug blocking JDK11 RC: https://bugs.openjdk.java.net/browse/JDK-8207317 http://cr.openjdk.java.net/~wetmore/8207317/webrev.00/ Proposed putback comment is inlined in the webrev. Bug analysis/fix explanation is in the last comment of the bug. Brad From anthony.scarpino at oracle.com Mon Aug 20 22:04:11 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 20 Aug 2018 15:04:11 -0700 Subject: RFR11(s): 8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy In-Reply-To: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com> References: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com> Message-ID: <80d4fa09-5309-ac4f-49fb-ec2a95cdffdb@oracle.com> On 08/20/2018 01:33 PM, Bradford Wetmore wrote: > > Hi Xuelei, > > Please review this P1 bug blocking JDK11 RC: > > ??? https://bugs.openjdk.java.net/browse/JDK-8207317 > ??? http://cr.openjdk.java.net/~wetmore/8207317/webrev.00/ > > Proposed putback comment is inlined in the webrev. > > Bug analysis/fix explanation is in the last comment of the bug. > > Brad > Was it intentional to have many edits that are nits and not related to the bug or was there a webrev mistake? Tony From bradford.wetmore at oracle.com Mon Aug 20 22:26:23 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 20 Aug 2018 15:26:23 -0700 Subject: RFR11(s): 8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy In-Reply-To: <80d4fa09-5309-ac4f-49fb-ec2a95cdffdb@oracle.com> References: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com> <80d4fa09-5309-ac4f-49fb-ec2a95cdffdb@oracle.com> Message-ID: <4edee5d4-d6f2-817b-8b14-47961600e03b@oracle.com> Intentional. Very minor things. Brad On 8/20/2018 3:04 PM, Anthony Scarpino wrote: > On 08/20/2018 01:33 PM, Bradford Wetmore wrote: >> >> Hi Xuelei, >> >> Please review this P1 bug blocking JDK11 RC: >> >> ???? https://bugs.openjdk.java.net/browse/JDK-8207317 >> ???? http://cr.openjdk.java.net/~wetmore/8207317/webrev.00/ >> >> Proposed putback comment is inlined in the webrev. >> >> Bug analysis/fix explanation is in the last comment of the bug. >> >> Brad >> > > > Was it intentional to have many edits that are nits and not related to > the bug or was there a webrev mistake? > > Tony From weijun.wang at oracle.com Mon Aug 20 23:08:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Aug 2018 07:08:56 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> Message-ID: <29D55B6D-663A-4941-8477-1675D75F116B@oracle.com> > On Aug 21, 2018, at 2:06 AM, Sean Mullan wrote: > > The SealedObjectFilter and SignedObjectFilter tests are almost the same, maybe they should be combined? I had thought about it but SignedObjectFilter.java is in jdk_security2 and SealedObjectFilter.java is in jdk_security1. I'm afraid that someone only run one of them might miss the chance to catch possible errors. > Also, can you add a test to check that a SecurityException is thrown when an SM is enabled and the SerializablePermission("serialFilter") has not been granted? OK. > > - SignedObject > > 69 * called, the {@link ObjectInputFilter.Config#getSerialFilter() > 70 * system filter} is used instead. > > "used instead" sounds like the getSerialFilter method returns the object. Suggest being more specific and saying something like: > > "the {@link ObjectInputFilter.Config#getSerialFilter() > system filter} is called to validate the object before it is returned." > > - SealedObject > > 92 * is called, the {@link ObjectInputFilter.Config#getSerialFilter() > 93 * system filter} is used instead. > > Same comment as above on the wording. I'll make the change as you suggested. Thanks Max > > --Sean > > On 8/17/18 10:56 AM, Weijun Wang wrote: >> Please take a review at the updated webrev at >> http://cr.openjdk.java.net/~weijun/8193859/webrev.01 >> Changes only in doc, including >> 1) The "2018-8-15 updates" in the CSR [1] >> 2) formatting >> Thanks >> Max >> [1] https://bugs.openjdk.java.net/browse/JDK-8193887 >>> On Aug 14, 2018, at 11:19 PM, Roger Riggs wrote: >>> >>> Hi, >>> >>> On 8/14/2018 10:59 AM, Weijun Wang wrote: >>>> >>>> s/initial process-wide filter/system filter/? >>> >>> yes >>> >>> Roger >>> >>>> >>>> --Max >>>> >>>>> [1] 8202675 Replace process-wide terminology in serial filtering to be consistent >>>>> >>>>> Regards, Roger >>>>> >>>> >>> From xuelei.fan at oracle.com Mon Aug 20 23:28:53 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 20 Aug 2018 16:28:53 -0700 Subject: RFR11(s): 8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy In-Reply-To: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com> References: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com> Message-ID: SSLTransport.java ----------------- line 173, nice to have 4 more indent white spaces. SSLEngineImpl.java ------------------ 942 // If it wasn't a RuntimeException/SSLException, need to wrap it. 943 if (!(exc instanceof RuntimeException) && 944 !(exc instanceof SSLException)) { 945 exc = getTaskThrown(exc); 946 } 947 948 throw (SSLException)exc; In line 948, the exc could be RuntimeException. Is it possible to throw ClassCastException? Otherwise, looks fine to me. Thanks, Xuelei On 8/20/2018 1:33 PM, Bradford Wetmore wrote: > > Hi Xuelei, > > Please review this P1 bug blocking JDK11 RC: > > ??? https://bugs.openjdk.java.net/browse/JDK-8207317 > ??? http://cr.openjdk.java.net/~wetmore/8207317/webrev.00/ > > Proposed putback comment is inlined in the webrev. > > Bug analysis/fix explanation is in the last comment of the bug. > > Brad > From bradford.wetmore at oracle.com Tue Aug 21 00:06:02 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 20 Aug 2018 17:06:02 -0700 Subject: RFR11(s): 8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy In-Reply-To: References: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com> Message-ID: On 8/20/2018 4:28 PM, Xue-Lei Fan wrote: > SSLTransport.java > ----------------- > line 173, nice to have 4 more indent white spaces. Ok, I could go either way on this one. > SSLEngineImpl.java > ------------------ > ?942?? // If it wasn't a RuntimeException/SSLException, need to wrap it. > ?943?? if (!(exc instanceof RuntimeException) && > ?944?????????? !(exc instanceof SSLException)) { > ?945?????? exc = getTaskThrown(exc); > ?946?? } > ?947 > ?948?? throw (SSLException)exc; > > In line 948, the exc could be RuntimeException.? Is it possible to throw > ClassCastException? Good catch. Corrected: http://cr.openjdk.java.net/~wetmore/8207317/webrev.01/ Brad > Otherwise, looks fine to me. > > Thanks, > Xuelei > > On 8/20/2018 1:33 PM, Bradford Wetmore wrote: >> >> Hi Xuelei, >> >> Please review this P1 bug blocking JDK11 RC: >> >> ???? https://bugs.openjdk.java.net/browse/JDK-8207317 >> ???? http://cr.openjdk.java.net/~wetmore/8207317/webrev.00/ >> >> Proposed putback comment is inlined in the webrev. >> >> Bug analysis/fix explanation is in the last comment of the bug. >> >> Brad >> From xuelei.fan at oracle.com Tue Aug 21 00:08:22 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 Aug 2018 17:08:22 -0700 Subject: RFR11(s): 8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy In-Reply-To: References: <66ca6eb5-bcfd-684e-9f94-4a6dc90e863b@oracle.com>

Message-ID: <8ef5c4b4-f190-9fd1-5774-dc7d0d312923@oracle.com> Looks good to me. Xuelei On 8/20/2018 5:06 PM, Bradford Wetmore wrote: > > > On 8/20/2018 4:28 PM, Xue-Lei Fan wrote: >> SSLTransport.java >> ----------------- >> line 173, nice to have 4 more indent white spaces. > > Ok, I could go either way on this one. > >> SSLEngineImpl.java >> ------------------ >> ??942?? // If it wasn't a RuntimeException/SSLException, need to wrap it. >> ??943?? if (!(exc instanceof RuntimeException) && >> ??944?????????? !(exc instanceof SSLException)) { >> ??945?????? exc = getTaskThrown(exc); >> ??946?? } >> ??947 >> ??948?? throw (SSLException)exc; >> >> In line 948, the exc could be RuntimeException.? Is it possible to >> throw ClassCastException? > > Good catch. > > Corrected: > > ??? http://cr.openjdk.java.net/~wetmore/8207317/webrev.01/ > > Brad > > >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> On 8/20/2018 1:33 PM, Bradford Wetmore wrote: >>> >>> Hi Xuelei, >>> >>> Please review this P1 bug blocking JDK11 RC: >>> >>> ???? https://bugs.openjdk.java.net/browse/JDK-8207317 >>> ???? http://cr.openjdk.java.net/~wetmore/8207317/webrev.00/ >>> >>> Proposed putback comment is inlined in the webrev. >>> >>> Bug analysis/fix explanation is in the last comment of the bug. >>> >>> Brad >>> From weijun.wang at oracle.com Tue Aug 21 03:06:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Aug 2018 11:06:01 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: <29D55B6D-663A-4941-8477-1675D75F116B@oracle.com> References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> <29D55B6D-663A-4941-8477-1675D75F116B@oracle.com> Message-ID: <27D20A2B-3DED-4A41-9A28-24669ACF54C5@oracle.com> I might be a little too quick saying "I will". The current class spec has * In this example, an {@link ObjectInputFilter} is used during * deserialization of the original object. If {@link #getObject()} is * called, the {@link ObjectInputFilter.Config#getSerialFilter() * system filter} is used instead. There are two "is used" here and I think people will understand they are the same, i.e. both "during the deserialization of...". That said, I think "before it is returned" is useful. How about this? * In this example, an {@link ObjectInputFilter} is used during * deserialization of the original object before it is returned. If {@link #getObject()} is * called, the {@link ObjectInputFilter.Config#getSerialFilter() * system filter} is used instead. > On Aug 21, 2018, at 7:08 AM, Weijun Wang wrote: > > >> >> - SignedObject >> >> 69 * called, the {@link ObjectInputFilter.Config#getSerialFilter() >> 70 * system filter} is used instead. >> >> "used instead" sounds like the getSerialFilter method returns the object. Suggest being more specific and saying something like: >> >> "the {@link ObjectInputFilter.Config#getSerialFilter() >> system filter} is called to validate the object before it is returned." We cannot say "is called" here. Although the @link points to a method the text is "system filter". Thanks Max >> >> - SealedObject >> >> 92 * is called, the {@link ObjectInputFilter.Config#getSerialFilter() >> 93 * system filter} is used instead. >> >> Same comment as above on the wording. > > I'll make the change as you suggested. >>>> >>>>> >>>>> --Max >>>>> >>>>>> [1] 8202675 Replace process-wide terminology in serial filtering to be consistent >>>>>> >>>>>> Regards, Roger From sean.mullan at oracle.com Tue Aug 21 12:57:33 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 21 Aug 2018 08:57:33 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: <27D20A2B-3DED-4A41-9A28-24669ACF54C5@oracle.com> References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> <29D55B6D-663A-4941-8477-1675D75F116B@oracle.com> <27D20A2B-3DED-4A41-9A28-24669ACF54C5@oracle.com> Message-ID: <7e47eb3a-77e0-bbbf-326e-78212a131f54@oracle.com> On 8/20/18 11:06 PM, Weijun Wang wrote: > That said, I think "before it is returned" is useful. How about this? > > * In this example, an {@link ObjectInputFilter} is used during > * deserialization of the original object before it is returned. If {@link #getObject()} is > * called, the {@link ObjectInputFilter.Config#getSerialFilter() > * system filter} is used instead. Better, but I might be a bit more specific about the purpose of the filter. How about: "In this example, an {@link ObjectInputFilter} is passed in to {@link #getObject(ObjectInputFilter)} and used during deserialization to validate the contents of the object before it is returned. If {@link #getObject()} is called, the {@link ObjectInputFilter.Config#getSerialFilter() system filter} is used instead. Also, I think the specification of the getObject() method should be updated to say that the system filter is used to validate the deserialized object. I realize that this was a previous side-effect of adding the system filter and not part of this change, but this did change the behavior of this method, so I think it should be added to the specification while you are making changes. The CSR will also need to be updated with this change. --Sean From weijun.wang at oracle.com Tue Aug 21 15:19:58 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Aug 2018 23:19:58 +0800 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: <7e47eb3a-77e0-bbbf-326e-78212a131f54@oracle.com> References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<9bc2782f-2ec4-9261-b76b-edaf86d33961@Oracle.com> <8FC72611-0BC9-4F43-95D7-B16160EF0782@oracle.com> <29D55B6D-663A-4941-8477-1675D75F116B@oracle.com> <27D20A2B-3DED-4A41-9A28-24669ACF54C5@oracle.com> <7e47eb3a-77e0-bbbf-326e-78212a131f54@oracle.com> Message-ID: > On Aug 21, 2018, at 8:57 PM, Sean Mullan wrote: > > On 8/20/18 11:06 PM, Weijun Wang wrote: > > >> That said, I think "before it is returned" is useful. How about this? >> * In this example, an {@link ObjectInputFilter} is used during >> * deserialization of the original object before it is returned. If {@link #getObject()} is >> * called, the {@link ObjectInputFilter.Config#getSerialFilter() >> * system filter} is used instead. > > Better, but I might be a bit more specific about the purpose of the filter. How about: > > "In this example, an {@link ObjectInputFilter} is passed in to {@link #getObject(ObjectInputFilter)} and used during deserialization to validate the contents of the object before it is returned. If {@link #getObject()} is called, the {@link ObjectInputFilter.Config#getSerialFilter() > system filter} is used instead. OK. I would like to emphasis "the original object". This word is used in the class spec to differentiate with the "signed object". > > Also, I think the specification of the getObject() method should be updated to say that the system filter is used to validate the deserialized object. I realize that this was a previous side-effect of adding the system filter and not part of this change, but this did change the behavior of this method, so I think it should be added to the specification while you are making changes. The CSR will also need to be updated with this change. I can. In fact, I have always wanted to add a new @throws if the filter rejects the stream. The problem is that even ObjectInputStream::readObject does not clearly list one. *Roger*: According to ObjectInputStream::setObjectInputFilter it's InvalidClassException. Can I say "@throws InvalidClassException if the (system) filter returns REJECTED while deserializing the original object"? Thanks Max > > --Sean From roger.riggs at oracle.com Tue Aug 21 15:27:18 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 21 Aug 2018 11:27:18 -0400 Subject: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject In-Reply-To: References: <3D8F792C-63A3-42C4-9D62-5FF6B814A489@oracle.com>

<7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> Message-ID: Hi Martin, I still observe the TestTLS12 regression test failure with your webrev.07. Judging from the test failure log, it seems that the test fails when run on a machine whose NSS library does not support the TLS v1.2 mechanisms. Generally, the test should check and skip if the to-be-tested algorithms aren't supported. There are some lines in TestTLS12.java which exceeds the 80-chars length. Can you please fix them? That's it. Thanks, Valerie On 8/14/2018 7:43 AM, Martin Balao wrote: > Hi Valerie, > > Here it is Webrev.07: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.07/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.07.zip > > > ?* p11_convert.c: > > ? * L530 and 834: masterKeyDeriveParamToCKMasterKeyDeriveParam and > keyMatParamToCKKeyMatParam functions used to accept "null" value for > class parameter -and, in fact, immediately return in such case-. > Null-checking was in these functions to avoid checking on each call > site (i.e.: jSsl3MasterKeyDeriveParamToCKSsl3MasterKeyDeriveParam and > jTls12MasterKeyDeriveParamToCKTls12MasterKeyDeriveParam call sites for > masterKeyDeriveParamToCKMasterKeyDeriveParam). But I reverted this > change now, so we check on call sites. I couldn't find any not-checked > FindClass call. > > ? * L1262: well spotted! Fixed. > > ?* Author tags removed > > ?* Updated copyright on every modified file > > ?* TestTLS12.java improvements: > ? * initSecmod is now called when starting the test > ? * Better integration with existing NSSDB + FIPS infrastructure > ? ?* RSA+SHA256 certificate (that expires in 2042) was added to FIPS > keystore and NSSDB. > > ?* Putback comment on webrev > > ?* jdk/sun/security/pkcs11 test suite pass-rate experienced no regression > > Thanks, > Martin.- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Wed Aug 22 01:54:05 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 21 Aug 2018 18:54:05 -0700 Subject: RFR 8186186 : GSSContext.isEstablished() can return true on error state Message-ID: Hello! Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186186 WEBREV: http://cr.openjdk.java.net/~igerasim/8186186/01/webrev/ With kind regards, Ivan From weijun.wang at oracle.com Wed Aug 22 02:13:25 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Aug 2018 10:13:25 +0800 Subject: RFR 8186186 : GSSContext.isEstablished() can return true on error state In-Reply-To: References: Message-ID: <94BFF23E-E14D-4157-968A-EEF1313679A2@oracle.com> The change looks fine. Thanks Max > On Aug 22, 2018, at 9:54 AM, Ivan Gerasimov wrote: > > Hello! > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186186 > WEBREV: http://cr.openjdk.java.net/~igerasim/8186186/01/webrev/ > > With kind regards, > Ivan > From david.holmes at oracle.com Wed Aug 22 05:46:47 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2018 15:46:47 +1000 Subject: hg: jdk/jdk: 8186186: GSSContext.isEstablished() can return true on error state In-Reply-To: <201808220320.w7M3KEiJ028916@aojmv0008.oracle.com> References: <201808220320.w7M3KEiJ028916@aojmv0008.oracle.com> Message-ID: Ivan, Did you forget to hg add a file for this? The new test is failing with: Error. Parse Exception: Can't find source file: SpnegoRejected.java David On 22/08/2018 1:20 PM, ivan.gerasimov at oracle.com wrote: > Changeset: 0e4d87cf6caf > Author: igerasim > Date: 2018-08-21 20:19 -0700 > URL: http://hg.openjdk.java.net/jdk/jdk/rev/0e4d87cf6caf > > 8186186: GSSContext.isEstablished() can return true on error state > Reviewed-by: weijun > Contributed-by: weijun.wang at oracle.com > > ! src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoContext.java > + test/jdk/sun/security/krb5/auto/SpnegoUnknownMech.java > From weijun.wang at oracle.com Wed Aug 22 05:49:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Aug 2018 13:49:17 +0800 Subject: hg: jdk/jdk: 8186186: GSSContext.isEstablished() can return true on error state In-Reply-To: References: <201808220320.w7M3KEiJ028916@aojmv0008.oracle.com> Message-ID: <1A8B08B6-EC64-4E71-8BFE-EC93FED88C83@oracle.com> Or, he renamed the test but forgot to rename the name on the @run line. > On Aug 22, 2018, at 1:46 PM, David Holmes wrote: > > Ivan, > > Did you forget to hg add a file for this? The new test is failing with: > > Error. Parse Exception: Can't find source file: SpnegoRejected.java > > David > > On 22/08/2018 1:20 PM, ivan.gerasimov at oracle.com wrote: >> Changeset: 0e4d87cf6caf >> Author: igerasim >> Date: 2018-08-21 20:19 -0700 >> URL: http://hg.openjdk.java.net/jdk/jdk/rev/0e4d87cf6caf >> 8186186: GSSContext.isEstablished() can return true on error state >> Reviewed-by: weijun >> Contributed-by: weijun.wang at oracle.com >> ! src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoContext.java >> + test/jdk/sun/security/krb5/auto/SpnegoUnknownMech.java From weijun.wang at oracle.com Wed Aug 22 05:54:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Aug 2018 13:54:57 +0800 Subject: hg: jdk/jdk: 8186186: GSSContext.isEstablished() can return true on error state In-Reply-To: <1A8B08B6-EC64-4E71-8BFE-EC93FED88C83@oracle.com> References: <201808220320.w7M3KEiJ028916@aojmv0008.oracle.com> <1A8B08B6-EC64-4E71-8BFE-EC93FED88C83@oracle.com> Message-ID: <4CEBFB35-9E92-4785-9B2A-F4D5D43B1BDF@oracle.com> Ivan, I'll file a bug and fix it. > On Aug 22, 2018, at 1:49 PM, Weijun Wang