Re: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v7]
On Thu, 28 Jan 2021 20:12:14 GMT, Clive Verghese wrote: >> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears >> to not be fully fixed >> >> This also fixes JDK-8259516: Alerts sent by peer may not be received >> correctly during TLS handshake > > Clive Verghese has updated the pull request incrementally with one additional > commit since the last revision: > > Address review comments Please make sure all tier1 and tier2 tests passed on all supported platforms. Except the failed I commented in the update, javax/net/ssl/SSLSession/TestEnabledProtocols.java is also failed with a similar stack on Windows. Maybe, the pull request command "/test tier1" and "/test tier2" could help speed up the testing. test/jdk/sun/security/ssl/SSLContextImpl/ShouldThrowSSLExceptionWhenPeerClosesSocket.java line 137: > 135: // Ignore exception as this is expected. > 136: } > 137: } The test cannot pass tier2 test on Windows. java.net.SocketException: An established connection was aborted by the software in your host machine at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420) at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:440) at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:826) at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1045) at java.base/sun.security.ssl.SSLSocketOutputRecord.flush(SSLSocketOutputRecord.java:266) at java.base/sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:89) at java.base/sun.security.ssl.CertificateRequest$T12CertificateRequestProducer.produce(CertificateRequest.java:629) at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440) at java.base/sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1120) at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:853) at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:812) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:199) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1501) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450) at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:915) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1006) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:966) at ShouldThrowSSLExceptionWhenPeerClosesSocket.runServerApplication(ShouldThrowSSLExceptionWhenPeerClosesSocket.java:131) at SSLSocketTemplate.doServerSide(SSLSocketTemplate.java:280) at SSLSocketTemplate.startServer(SSLSocketTemplate.java:584) at SSLSocketTemplate.bootup(SSLSocketTemplate.java:498) at SSLSocketTemplate.run(SSLSocketTemplate.java:83) at ShouldThrowSSLExceptionWhenPeerClosesSocket.main(ShouldThrowSSLExceptionWhenPeerClosesSocket.java:292) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Suppressed: java.net.SocketException: An established connection was aborted by the software in your host machine at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:325) at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:976) at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:160) at java.base/sun.security.ssl
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14]
On Mon, 18 Jan 2021 16:45:00 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be found at
>> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>>
>> old PR: https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update package info to credit LMX algorithm
src/java.base/share/classes/java/util/random/RandomGenerator.java line 110:
> 108: /**
> 109: * Returns an instance of {@link RandomGenerator} that utilizes the
> 110: * {@code name} algorithm.
Shouldn't this method, and related methods, mention the fact that
`RandomGenerator` instances are located as services? I see no mention of of
that fact anywhere, unless I missed it, but I do see the `uses` and `provides`
declarations in the module declaration. A paragraph explaining how services are
used here, perhaps in the package specification, would be ideal.
-
PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v7]
> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears > to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received > correctly during TLS handshake Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Address review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/2057/files - new: https://git.openjdk.java.net/jdk/pull/2057/files/72fef9b8..888162a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=05-06 Stats: 15 lines in 2 files changed: 0 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057
Re: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6]
On Tue, 26 Jan 2021 18:56:57 GMT, Clive Verghese wrote:
>> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears
>> to not be fully fixed
>>
>> This also fixes JDK-8259516: Alerts sent by peer may not be received
>> correctly during TLS handshake
>
> Clive Verghese has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains four commits:
>
> - Update copyright year
> - Add error handling guidelines
> - Fix bugids and use server port passed as a parameter
> - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl
src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1425:
> 1423: } catch (SocketException se) {
> 1424: // don't change exception in case of SocketException
> 1425: throw se;
I may add the SocketException catch line together within line 1420.
src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1491:
> 1489: } catch (SocketException se) {
> 1490: // don't change exception in case of SocketException
> 1491: throw se;
I may add the SocketException catch line together within line 1489.
src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1702:
> 1700: if (!conContext.isInboundClosed()) {
> 1701: try {
> 1702: decode(null);
One decode may be not sufficient if there are multiple pending handshake
messages record, or the connection has been established and application data
transportation is in progress. I'm not sure if an additional decode() here
really solve the problem as described in JDK-8259516.
I did not follow the issue of JDK-8259516. Why an SSLException is desired but
not SocketException, as if the socket has been closed?
src/java.base/share/classes/sun/security/ssl/SSLTransport.java line 146:
> 144: } catch (SocketException se) {
> 145: // don't change exception in case of SocketException
> 146: throw se;
I may add the SocketException catch line together within line 141.
-
PR: https://git.openjdk.java.net/jdk/pull/2057
Re: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program
On Thu, 28 Jan 2021 01:22:52 GMT, Rajan Halade wrote: > Following two roots are added to cacerts store - > > CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic > Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic > Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > Release Note is at - https://bugs.openjdk.java.net/browse/JDK-8260597 Marked as reviewed by hchao (Author). - PR: https://git.openjdk.java.net/jdk/pull/2272
Re: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program
On Thu, 28 Jan 2021 18:13:39 GMT, Hai-May Chao wrote: > Looks good. Thanks!! Can you please approve review with approval on changeset? With that, your OpenJDK id will be added as reviewer to the fix. - PR: https://git.openjdk.java.net/jdk/pull/2272
Re: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program
On Thu, 28 Jan 2021 01:22:52 GMT, Rajan Halade wrote: > Following two roots are added to cacerts store - > > CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic > Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic > Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > Release Note is at - https://bugs.openjdk.java.net/browse/JDK-8260597 Looks good. - PR: https://git.openjdk.java.net/jdk/pull/2272
Re: RFR: 8258915: Temporary buffer cleanup [v5]
> Clean up temporary byte array, char array, and keyspec around keys and > passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: cleanups for key generations - Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/9b17b1a2..48890a61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=03-04 Stats: 156 lines in 19 files changed: 101 ins; 23 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070
Re: RFR: 8258915: Temporary buffer cleanup
On Fri, 22 Jan 2021 21:25:25 GMT, Weijun Wang wrote: >> New commit. However, I was writing test to detect leak in >> `RSAPrivateKeySpec` conversion and add more key->spec->key for other >> algorithms and find more leaks. Will fix in another commit. > > Another new commit. Last time I only fixed KeySpec on PKCS8 format. This time > it's for an algorithm's _own_ spec. New commit for key generations. - PR: https://git.openjdk.java.net/jdk/pull/2070
Re: RFR: 8259801: Enable XML Signature secure validation mode by default [v2]
> This change enables the XML Signature secure validation mode by default. This > will improve out of the box security by restricting signatures that contain > potentially unsafe content by default. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - Minor re-wording of implNote. - Initial fix. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2197/files - new: https://git.openjdk.java.net/jdk/pull/2197/files/0c2e0498..ff15a1d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2197&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2197&range=00-01 Stats: 37355 lines in 801 files changed: 14132 ins; 17886 del; 5337 mod Patch: https://git.openjdk.java.net/jdk/pull/2197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2197/head:pull/2197 PR: https://git.openjdk.java.net/jdk/pull/2197
Integrated: 8259801: Enable XML Signature secure validation mode by default
On Fri, 22 Jan 2021 17:23:12 GMT, Sean Mullan wrote: > This change enables the XML Signature secure validation mode by default. This > will improve out of the box security by restricting signatures that contain > potentially unsafe content by default. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 This pull request has now been integrated. Changeset: baf46bac Author:Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/baf46bac Stats: 55 lines in 3 files changed: 12 ins; 3 del; 40 mod 8259801: Enable XML Signature secure validation mode by default Reviewed-by: weijun, rhalade - PR: https://git.openjdk.java.net/jdk/pull/2197
RFR: Release Note for 8259801: Enable XML Signature secure validation mode by default
Please review the release note for JDK-8259801: https://bugs.openjdk.java.net/browse/JDK-8260551 Thanks, Sean
