From duke at openjdk.java.net Wed Mar 2 11:56:22 2022
From: duke at openjdk.java.net (zzambers)
Date: Wed, 2 Mar 2022 11:56:22 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
Message-ID:
Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
[1] https://bugs.openjdk.java.net/browse/JDK-8208526
[2] https://bugs.openjdk.java.net/browse/JDK-8216326
-------------
Commit messages:
- javax/net/ssl/SSLSocket: Fixed API Note in javadoc
Changes: https://git.openjdk.java.net/jdk/pull/7648/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8282529
Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
Patch: https://git.openjdk.java.net/jdk/pull/7648.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7648/head:pull/7648
PR: https://git.openjdk.java.net/jdk/pull/7648
From duke at openjdk.java.net Wed Mar 2 11:56:23 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Wed, 2 Mar 2022 11:56:23 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To:
References:
Message-ID: <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com>
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
@zzambers I've created a corresponding issue for you in the tracker, please rename your PR title to 8282529 and the system should automatically mark your PR as ready for review
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From duke at openjdk.java.net Wed Mar 2 11:56:24 2022
From: duke at openjdk.java.net (zzambers)
Date: Wed, 2 Mar 2022 11:56:24 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To: <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com>
References:
<_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com>
Message-ID: <1dy03NNttstKhBtGII_CDhF3h4T0zls0dhTl2S9Wbq8=.63d2ff0b-85d0-4f9a-b6ec-4533e983014a@github.com>
On Wed, 2 Mar 2022 07:13:36 GMT, TheShermanTanker wrote:
>> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
>> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
>
> @zzambers I've created a corresponding issue for you in the tracker, please rename your PR title to 8282529 and the system should automatically mark your PR as ready for review
@TheShermanTanker thank you
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From dfuchs at openjdk.java.net Wed Mar 2 12:47:06 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Mar 2022 12:47:06 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To:
References:
Message-ID: <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
On Fri, 25 Feb 2022 15:06:29 GMT, Mahendra Chhipa wrote:
>> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
>> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
>> open/test/jdk/java/net/ProxySelector/ProxyTest.java
>> open/test/jdk/java/net/URL/PerConnectionProxy.java
>> open/test/jdk/java/net/URLConnection/B5052093.java
>> open/test/jdk/sun/net/www/AuthHeaderTest.java
>> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>
> Removed extra whitespace
test/jdk/java/net/ProxySelector/LoopbackAddresses.java line 168:
> 166: try(PrintWriter pw = new PrintWriter(exchange.getResponseBody())) {
> 167: pw.print("Hello .");
> 168: }
I know that now UTF-8 is supposed to be the default - but I'd prefer to either make it explicit, or add a comment stating that since Java 18 PrintWriter will use UTF-8 encoding by default.
test/jdk/java/net/ProxySelector/ProxyTest.java line 116:
> 114: e.printStackTrace();
> 115: }
> 116: try(PrintWriter pw = new PrintWriter(exchange.getResponseBody())) {
Same remark here
test/jdk/java/net/URL/PerConnectionProxy.java line 234:
> 232: } catch (IOException e) {
> 233: }
> 234: try(PrintWriter pw = new PrintWriter(exchange.getResponseBody())) {
And here too
test/jdk/java/net/URLConnection/B5052093.java line 113:
> 111: exchange.close();
> 112: } catch (IOException e) {
> 113: e.printStackTrace();
Are you sure that this results in the same response headers than before?
If I'm not mistaken here we will send both Content-Length and Transfer-Encoding: chunked. Was that what the previous server did, and what the test wants to test?
test/jdk/sun/net/www/AuthHeaderTest.java line 139:
> 137: void okReply (HttpExchange req) throws IOException {
> 138: req.sendResponseHeaders (200, 0);
> 139: try(PrintWriter pw = new PrintWriter(req.getResponseBody())) {
Same remark about UTF-8
test/jdk/sun/net/www/AuthHeaderTest.java line 167:
> 165: }
> 166: }
> 167: }
missing newline at end of file?
test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 157:
> 155: }
> 156:
> 157: class SimpleHttpTransactionHandler implements HttpHandler
the boolean `failed` should at least be volatile
test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 178:
> 176: responseBody[i] = 0x41;
> 177: trans.sendResponseHeaders(200, 0);
> 178: try(PrintWriter pw = new PrintWriter(trans.getResponseBody())) {
Same remark about UTF-8 here again
test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 206:
> 204: // override the Content-length header to be greater than the actual response body
> 205: trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
> 206: trans.sendResponseHeaders(200, 0);
Here again we will be mixing Content-Length and chunked
test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 207:
> 205: trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
> 206: trans.sendResponseHeaders(200, 0);
> 207: try(PrintWriter pw = new PrintWriter(trans.getResponseBody())) {
Same remark for UTF-8
-------------
PR: https://git.openjdk.java.net/jdk/pull/7616
From xuelei at openjdk.java.net Wed Mar 2 15:31:08 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Mar 2022 15:31:08 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To:
References:
Message-ID:
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
Thank you for the nice catch. The update looks good to me. A CSR may be required for spec change.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From wetmore at openjdk.java.net Wed Mar 2 23:40:04 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 2 Mar 2022 23:40:04 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To:
References:
Message-ID:
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
Please update the copyright to include 2022. Thanks.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From wetmore at openjdk.java.net Thu Mar 3 00:28:06 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 3 Mar 2022 00:28:06 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To:
References:
Message-ID: <9rSTeWIbQhJoNbsw_h5Gf3_CkoPp1Mwu6lSFlNcJwik=.f37c22cc-55ef-4b54-b2e2-1c35aaa28642@github.com>
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
Please also update JDK-8282529 to include the description (i.e. above). IMHO, the bug should contain the information for the issue, rather than need to navigate 2 steps to the pull request.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From jwaters at openjdk.java.net Thu Mar 3 08:16:02 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Thu, 3 Mar 2022 08:16:02 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To:
References:
Message-ID:
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
JDK-8282529 has been updated accordingly
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From duke at openjdk.java.net Thu Mar 3 12:36:33 2022
From: duke at openjdk.java.net (zzambers)
Date: Thu, 3 Mar 2022 12:36:33 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
[v2]
In-Reply-To:
References:
Message-ID:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
zzambers has updated the pull request incrementally with one additional commit since the last revision:
Updated copyright for SSLSocket.java
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7648/files
- new: https://git.openjdk.java.net/jdk/pull/7648/files/ff33d3f6..7fe494ab
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/7648.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7648/head:pull/7648
PR: https://git.openjdk.java.net/jdk/pull/7648
From jpai at openjdk.java.net Thu Mar 3 16:21:22 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 3 Mar 2022 16:21:22 GMT
Subject: RFR: 8282617:
sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
lock while dealing with inCache field
Message-ID:
Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617?
The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.
-------------
Commit messages:
- 8282617: sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a lock while dealing with inCache field
Changes: https://git.openjdk.java.net/jdk/pull/7680/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7680&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8282617
Stats: 13 lines in 1 file changed: 7 ins; 2 del; 4 mod
Patch: https://git.openjdk.java.net/jdk/pull/7680.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7680/head:pull/7680
PR: https://git.openjdk.java.net/jdk/pull/7680
From dfuchs at openjdk.java.net Thu Mar 3 16:29:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 3 Mar 2022 16:29:58 GMT
Subject: RFR: 8282617:
sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
lock while dealing with inCache field
In-Reply-To:
References:
Message-ID:
On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617?
>
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
>
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
>
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.
LGTM!
Please run tier1 and tier2 tests before integrating
-------------
Marked as reviewed by dfuchs (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7680
From duke at openjdk.java.net Fri Mar 4 10:41:44 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 10:41:44 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
HttpTransaction, HttpCallback from open/test/jdk/ tests [v4]
In-Reply-To:
References:
Message-ID:
> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
> open/test/jdk/java/net/ProxySelector/ProxyTest.java
> open/test/jdk/java/net/URL/PerConnectionProxy.java
> open/test/jdk/java/net/URLConnection/B5052093.java
> open/test/jdk/sun/net/www/AuthHeaderTest.java
> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
Implemented the review comments.
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7616/files
- new: https://git.openjdk.java.net/jdk/pull/7616/files/d62ba21c..f2218025
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=03
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=02-03
Stats: 27 lines in 6 files changed: 15 ins; 0 del; 12 mod
Patch: https://git.openjdk.java.net/jdk/pull/7616.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7616/head:pull/7616
PR: https://git.openjdk.java.net/jdk/pull/7616
From duke at openjdk.java.net Fri Mar 4 11:10:05 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 11:10:05 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
References:
<3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
Message-ID:
On Wed, 2 Mar 2022 12:35:47 GMT, Daniel Fuchs wrote:
>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Removed extra whitespace
>
> test/jdk/java/net/URLConnection/B5052093.java line 113:
>
>> 111: exchange.close();
>> 112: } catch (IOException e) {
>> 113: e.printStackTrace();
>
> Are you sure that this results in the same response headers than before?
> If I'm not mistaken here we will send both Content-Length and Transfer-Encoding: chunked. Was that what the previous server did, and what the test wants to test?
Yes, previously also, setting the content-length Integer.MAX_VALUE)) + 2, and was not sending any content. Here wanted to test, that URLConnection.getContentLength() does not throw NumberFormatException and return -1 if content-length is long value.
In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., thats why I am using chunked encoding and not writing any data.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7616
From michaelm at openjdk.java.net Fri Mar 4 11:12:25 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 11:12:25 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
Message-ID: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Hi,
Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.enabledDigestAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
- Michael
-------------
Commit messages:
- fix whitespace
- update property name. add documentation
- fixed one more test
- fixed up existing tests using digest auth
- Merge branch 'master' into md5
- added userhash support plus test
- fixed problem in copyright header
- added test
- Merge branch 'master' into md5
- update
- ... and 1 more: https://git.openjdk.java.net/jdk/compare/b6c35ae4...f0fb72de
Changes: https://git.openjdk.java.net/jdk/pull/7688/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8281561
Stats: 302 lines in 11 files changed: 247 ins; 3 del; 52 mod
Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688
PR: https://git.openjdk.java.net/jdk/pull/7688
From michaelm at openjdk.java.net Fri Mar 4 11:12:26 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 11:12:26 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.enabledDigestAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
I have still to add the doc update describing the system property, which will come shortly. I may suggest a change of name to the system property to better reflect its exact meaning/purpose
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From duke at openjdk.java.net Fri Mar 4 11:14:09 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 11:14:09 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
References:
<3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
Message-ID: <0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>
On Wed, 2 Mar 2022 12:42:11 GMT, Daniel Fuchs wrote:
>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Removed extra whitespace
>
> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 206:
>
>> 204: // override the Content-length header to be greater than the actual response body
>> 205: trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
>> 206: trans.sendResponseHeaders(200, 0);
>
> Here again we will be mixing Content-Length and chunked
In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., that's why I am using chunked encoding and writing the data less than the content length.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7616
From dfuchs at openjdk.java.net Fri Mar 4 11:25:02 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 11:25:02 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>
References:
<3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
<0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>
Message-ID:
On Fri, 4 Mar 2022 11:10:40 GMT, Mahendra Chhipa wrote:
>> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 206:
>>
>>> 204: // override the Content-length header to be greater than the actual response body
>>> 205: trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
>>> 206: trans.sendResponseHeaders(200, 0);
>>
>> Here again we will be mixing Content-Length and chunked
>
> In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., that's why I am using chunked encoding and writing the data less than the content length.
I understand why you do it - but the client will react differently if both Content-Length *and* chunk are specified, as opposed to when only Content-Length is specified. So I just want to make sure that we are testing the same thing than before. If we are not testing the same thing, then you might have to use a ServerSocket directly - rather than an HttpServer, to make sure we're sending back the same things than before.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7616
From dfuchs at openjdk.java.net Fri Mar 4 11:29:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 11:29:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Should we instead have a property to disable algorithms, whose default value would contain "MD5" by default?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From michaelm at openjdk.java.net Fri Mar 4 11:37:04 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 11:37:04 GMT
Subject: RFR: 8282617:
sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
lock while dealing with inCache field
In-Reply-To:
References:
Message-ID:
On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617?
>
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
>
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
>
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.
LGTM
-------------
Marked as reviewed by michaelm (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7680
From michaelm at openjdk.java.net Fri Mar 4 12:07:05 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 12:07:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
Message-ID:
On Fri, 4 Mar 2022 11:25:38 GMT, Daniel Fuchs wrote:
> Should we instead have a property to disable algorithms, whose default value would contain "MD5" by default?
I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From dfuchs at openjdk.java.net Fri Mar 4 12:16:05 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 12:16:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
Message-ID:
On Fri, 4 Mar 2022 12:03:44 GMT, Michael McMahon wrote:
> I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
>
> I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From michaelm at openjdk.java.net Fri Mar 4 12:25:05 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 12:25:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
Message-ID:
On Fri, 4 Mar 2022 12:12:25 GMT, Daniel Fuchs wrote:
> > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
>
> Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From duke at openjdk.java.net Fri Mar 4 12:28:41 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 12:28:41 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
HttpTransaction, HttpCallback from open/test/jdk/ tests [v5]
In-Reply-To:
References:
Message-ID:
> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
> open/test/jdk/java/net/ProxySelector/ProxyTest.java
> open/test/jdk/java/net/URL/PerConnectionProxy.java
> open/test/jdk/java/net/URLConnection/B5052093.java
> open/test/jdk/sun/net/www/AuthHeaderTest.java
> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
Mahendra Chhipa 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 11 additional commits since the last revision:
- Removed extra space.
- Removed Transfer encoding chunked from B5045306
- Merge branch 'master' into JDK-8282354
- Implemented the review comments.
- Removed extra whitespace
- Implemented the review comments.
- JDK-8282354 : Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests
- Merge branch 'master' into JDK-8282354
- WIP
- Merge branch 'master' into httptrans
- ... and 1 more: https://git.openjdk.java.net/jdk/compare/b46ce84b...7f947718
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7616/files
- new: https://git.openjdk.java.net/jdk/pull/7616/files/f2218025..7f947718
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=04
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=03-04
Stats: 18347 lines in 450 files changed: 12637 ins; 3117 del; 2593 mod
Patch: https://git.openjdk.java.net/jdk/pull/7616.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7616/head:pull/7616
PR: https://git.openjdk.java.net/jdk/pull/7616
From michaelm at openjdk.java.net Fri Mar 4 12:33:06 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 12:33:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> >
> >
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> >
> >
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From duke at openjdk.java.net Fri Mar 4 12:57:03 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 12:57:03 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To:
References:
<3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
<0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>
Message-ID:
On Fri, 4 Mar 2022 11:21:47 GMT, Daniel Fuchs wrote:
>> In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., that's why I am using chunked encoding and writing the data less than the content length.
>
> I understand why you do it - but the client will react differently if both Content-Length *and* chunk are specified, as opposed to when only Content-Length is specified. So I just want to make sure that we are testing the same thing than before. If we are not testing the same thing, then you might have to use a ServerSocket directly - rather than an HttpServer, to make sure we're sending back the same things than before.
Now not using Transfer-Encoding Chunk.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7616
From dfuchs at openjdk.java.net Fri Mar 4 13:09:08 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 13:09:08 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 12:29:28 GMT, Michael McMahon wrote:
> > So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
>
> Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.
I see - maybe we should have a security property identifying the list of algorithm that are disabled, and then a system property to reenable them?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From dfuchs at openjdk.java.net Fri Mar 4 13:24:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 13:24:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 71:
> 69: // This will probably be expanded to include SHA-1 eventually
> 70: private static final Set defDisabledAlgs =
> 71: Set.of("MD5");
What I'm suggesting is that the content of this set could be seeded with the value of a Security Property, defined in java.security - rather than have the default value hardcoded here.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From michaelm at openjdk.java.net Fri Mar 4 13:41:04 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 13:41:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 13:13:47 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 71:
>
>> 69: // This will probably be expanded to include SHA-1 eventually
>> 70: private static final Set defDisabledAlgs =
>> 71: Set.of("MD5");
>
> What I'm suggesting is that the content of this set could be seeded with the value of a Security Property, defined in java.security - rather than have the default value hardcoded here.
Yes, I think that should work
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From jpai at openjdk.java.net Fri Mar 4 13:54:03 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 13:54:03 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/java/net/doc-files/net-properties.html line 227:
> 225: name.
> 226:
> 227: {@systemProperty http.auth.digest.reEnabledAlgs} (default: <none>)
Hello Michael, from what I understand of `doc-files` directory (which is where this html file resides) the `javadoc` tool considers it an unprocessed files location[1]. So would adding the `systemProperty` javadoc taglet here be necessary? I think this won't end up being listed in the system properties index generated by the javadoc tool and I think this line here will just get rendered literally.
[1] https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From ecki at zusammenkunft.net Fri Mar 4 14:03:53 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 4 Mar 2022 14:03:53 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
Hello,
While I like the idea of the user having to explicitely specify the rexenabled legacy algorithms (as opposed to removing the defaultsdisabled) it is not the style the other algorithm policies in JCE work - so it might be confusing.
But, more critically I would separate the enabling/implementing of new algorithms from disabling old ones. Especially since there needs to be changes on the server side first. (And I wonder if this can be negotiated anyway?).
So why not start with a ?provide new DIGEST Mechanisms? change? Having said that, would it need to start out with disabled new mechanisms so the update won?t change the behavior? (If there is no negotiation?)
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev im Auftrag von Michael McMahon
Gesendet: Friday, March 4, 2022 1:33:06 PM
An: net-dev at openjdk.java.net
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> >
> >
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> >
> >
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jpai at openjdk.java.net Fri Mar 4 14:06:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:06:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 524:
> 522: logger.info(msg + " This constraint may be relaxed by setting " +
> 523: "the \"http.auth.digest.enabledDigestAlgs\" system property.");
> 524: }
I suspect this is a typo and perhaps should have been `http.auth.digest.reEnabledAlgs`?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From dfuchs at openjdk.java.net Fri Mar 4 14:09:07 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 14:09:07 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>
Message-ID: <1IGxBt9tVPyAgq03cWyY6ME2yuZOHJYpej3A1rhp_lg=.2cbeadb1-831c-4e02-a5b8-ecf4ba1b54ce@github.com>
On Fri, 4 Mar 2022 13:50:37 GMT, Jaikiran Pai wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 227:
>
>> 225: name.
>> 226:
>> 227: {@systemProperty http.auth.digest.reEnabledAlgs} (default: <none>)
>
> Hello Michael, from what I understand of `doc-files` directory (which is where this html file resides) the `javadoc` tool considers it an unprocessed files location[1]. So would adding the `systemProperty` javadoc taglet here be necessary? I think this won't end up being listed in the system properties index generated by the javadoc tool and I think this line here will just get rendered literally.
>
> [1] https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html
This actually seems to work. If you build the docs for JDK mainline, you can search for instance, for `http.keepAlive.time.proxy` in the javadoc search box and it will lead you `net-properties.html`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From jpai at openjdk.java.net Fri Mar 4 14:15:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:15:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 443:
> 441: } catch (IOException e) {
> 442: // should not happen since the algorithm has already been
> 443: // validated
Hello Michael, was this comment meant for something else? The comment feels a bit odd since it says "has already been validated" which isn't the case since the `validateAlgorithm` itself has failed here.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From jpai at openjdk.java.net Fri Mar 4 14:23:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:23:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <_-1iD7d6NkfogWVFCWeBYH6H6VmuqXgM7tjGsVN0Nt0=.7a2d558b-ab63-4af5-b9bc-ed0cd794326c@github.com>
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 584:
> 582: boolean truncate256 = false;
> 583:
> 584: if (algorithm.equals("SHA-512-256")) {
It appears that the incoming param `algorithm` can be of any case. In some other places like the `validateAlgorithm`, this `algorithm` value has been first converted to an uppercase value and then used for additional checks. Should a similar upper case conversion be done here before this equality check? Perhaps, we should convert this to upper case once and then pass it around to these `validateAlgorithm` and `computeUserhash` methods?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From jpai at openjdk.java.net Fri Mar 4 14:42:59 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:42:59 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 423:
> 421: String algorithm = params.getAlgorithm ();
> 422: boolean userhash = params.getUserhash ();
> 423: params.incrementNC ();
I am not familiar with the code and the request/response flow involved in this code, so what I mention may not be relevant. However, do you think the algorithm validation that we added in this PR should happen before this `incrementNC()` is called and the `ncString` construction is done? I see that this incremented `ncCount` then gets used in the `checkResponse` part. In the case where the algorithm validation fails and we return `null` from this method (which effectively means not setting the authorization header), do you think the subsequent `checkResponse` would run into issues due to the `incrementNC()` being done here?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From michaelm at openjdk.java.net Fri Mar 4 14:49:05 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 14:49:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 14:11:00 GMT, Jaikiran Pai wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 443:
>
>> 441: } catch (IOException e) {
>> 442: // should not happen since the algorithm has already been
>> 443: // validated
>
> Hello Michael, was this comment meant for something else? The comment feels a bit odd since it says "has already been validated" which isn't the case since the `validateAlgorithm` itself has failed here.
Yes, copy and paste error. Thanks
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 524:
>
>> 522: logger.info(msg + " This constraint may be relaxed by setting " +
>> 523: "the \"http.auth.digest.enabledDigestAlgs\" system property.");
>> 524: }
>
> I suspect this is a typo and perhaps should have been `http.auth.digest.reEnabledAlgs`?
Thanks. I'm going to change the name once more and will update it then.
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 584:
>
>> 582: boolean truncate256 = false;
>> 583:
>> 584: if (algorithm.equals("SHA-512-256")) {
>
> It appears that the incoming param `algorithm` can be of any case. In some other places like the `validateAlgorithm`, this `algorithm` value has been first converted to an uppercase value and then used for additional checks. Should a similar upper case conversion be done here before this equality check? Perhaps, we should convert this to upper case once and then pass it around to these `validateAlgorithm` and `computeUserhash` methods?
Right. I'll check all that for the next round.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From ccleary at openjdk.java.net Fri Mar 4 14:52:32 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 4 Mar 2022 14:52:32 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
Promise that is too large
Message-ID:
**Problem**
When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
java.io.IOException: no statuscode in response
at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
...
This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
**Fix**
To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
- The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
- When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
- In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
-------------
Commit messages:
- 8263031: Created new flow for Push Promises followed by Continuations
- 8263031: Setting END_HEADERS flag where appropriate
- 8263031: Update test name and cleanup
- 8263031: HttpClient throws Exception if it receives a Push Promise that is too large
Changes: https://git.openjdk.java.net/jdk/pull/7696/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8263031
Stats: 423 lines in 4 files changed: 336 ins; 67 del; 20 mod
Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696
PR: https://git.openjdk.java.net/jdk/pull/7696
From jpai at openjdk.java.net Fri Mar 4 14:54:05 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:54:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <1IGxBt9tVPyAgq03cWyY6ME2yuZOHJYpej3A1rhp_lg=.2cbeadb1-831c-4e02-a5b8-ecf4ba1b54ce@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>
<1IGxBt9tVPyAgq03cWyY6ME2yuZOHJYpej3A1rhp_lg=.2cbeadb1-831c-4e02-a5b8-ecf4ba1b54ce@github.com>
Message-ID: <1bn1IMSLVRnlbgkXPTRBNJumESnDdpYYO0gfMe02Qvo=.24dacf0f-501a-49df-a656-5bbc3eea6b76@github.com>
On Fri, 4 Mar 2022 14:06:14 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 227:
>>
>>> 225: name.
>>> 226:
>>> 227: {@systemProperty http.auth.digest.reEnabledAlgs} (default: <none>)
>>
>> Hello Michael, from what I understand of `doc-files` directory (which is where this html file resides) the `javadoc` tool considers it an unprocessed files location[1]. So would adding the `systemProperty` javadoc taglet here be necessary? I think this won't end up being listed in the system properties index generated by the javadoc tool and I think this line here will just get rendered literally.
>>
>> [1] https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html
>
> This actually seems to work. If you build the docs for JDK mainline, you can search for instance, for `http.keepAlive.time.proxy` in the javadoc search box and it will lead you `net-properties.html`.
You are right indeed. I just checked the generated system properties index and it does list these properties and even links back to this document. In fact, I even found a mail which clearly states that this processing of `@systemProperties` is supported for `doc-files` https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056653.html
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From michaelm at openjdk.java.net Fri Mar 4 15:00:00 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 15:00:00 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <078GV9CX_aqW4yp8oI5lfyrJilt8kZEbKMSrdsQVTzA=.b70f2f23-b43a-4b9c-9c12-006ccb94612b@github.com>
On Fri, 4 Mar 2022 14:39:50 GMT, Jaikiran Pai wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 423:
>
>> 421: String algorithm = params.getAlgorithm ();
>> 422: boolean userhash = params.getUserhash ();
>> 423: params.incrementNC ();
>
> I am not familiar with the code and the request/response flow involved in this code, so what I mention may not be relevant. However, do you think the algorithm validation that we added in this PR should happen before this `incrementNC()` is called and the `ncString` construction is done? I see that this incremented `ncCount` then gets used in the `checkResponse` part. In the case where the algorithm validation fails and we return `null` from this method (which effectively means not setting the authorization header), do you think the subsequent `checkResponse` would run into issues due to the `incrementNC()` being done here?
I think there probably wouldn't be a problem as the value would always be increasing and the server is only checking for duplicates, or replays rather than gaps. But, nevertheless, it seems like better practice to do the check before incrementing the counter.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From michael.x.mcmahon at oracle.com Fri Mar 4 15:07:49 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 4 Mar 2022 15:07:49 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
Bernd,
If I understand you correctly, there is no negotiation at this level.
Once Digest is selected, it's up to the server to choose the algorithm
and then the client can either accept it or else reject it and the whole
request fails then.
It's true that with this change, if the server proposes MD5 by default,
then the request will fail. But, that's the point of the change, and the
compatibility impact is considered in the related CSR. In that case,
either the server needs to change or else the system property to
re-enable MD5 must be set.
I'd like to try out (for the next review round) the idea of establishing
the default "insecure" protocols as a fixed security property (including
MD5 and SHA-1) and then provide a settable system or networking property
to override that.
Thanks
Michael
On 04/03/2022 14:03, Bernd Eckenfels wrote:
> Hello,
>
> While I like the idea of the user having to explicitely specify the rexenabled legacy algorithms (as opposed to removing the defaultsdisabled) it is not the style the other algorithm policies in JCE work - so it might be confusing.
>
> But, more critically I would separate the enabling/implementing of new algorithms from disabling old ones. Especially since there needs to be changes on the server side first. (And I wonder if this can be negotiated anyway?).
>
> So why not start with a ?provide new DIGEST Mechanisms? change? Having said that, would it need to start out with disabled new mechanisms so the update won?t change the behavior? (If there is no negotiation?)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: net-dev im Auftrag von Michael McMahon
> Gesendet: Friday, March 4, 2022 1:33:06 PM
> An:net-dev at openjdk.java.net
> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
>
> On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
>
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>>>> I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
>>>> I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
>>>
>>> Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>>
>> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
>
>
>>>> I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
>>>> I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
>>>
>>> Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>>
>> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
> Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/7688
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ccleary at openjdk.java.net Fri Mar 4 15:20:05 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 4 Mar 2022 15:20:05 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
Promise that is too large
In-Reply-To:
References:
Message-ID:
On Fri, 4 Mar 2022 14:42:40 GMT, Conor Cleary wrote:
> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>
>
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
>
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
I see that a couple of imports got changed by my IDE, will address that shortly
-------------
PR: https://git.openjdk.java.net/jdk/pull/7696
From mullan at openjdk.java.net Fri Mar 4 16:32:09 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 4 Mar 2022 16:32:09 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v18]
In-Reply-To:
References:
Message-ID:
On Thu, 17 Feb 2022 18:57:02 GMT, Xue-Lei Andrew Fan wrote:
>> This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>
> more spec update per CSR feedback
Since this new API is also intended to be supported for DTLS, have you added implementation support for that, and if so have you added a test for it?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7252
From weijun at openjdk.java.net Fri Mar 4 16:35:00 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 4 Mar 2022 16:35:00 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Several comments added. Also, I am reading rfc7616 and it will be really nice if we can include the 2 examples at https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 as a known answer test. Of course this means you need a way to provide a hardcoded `cnonce` and it's probably not easy.
src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:
> 230: includes {@code MD5} but other algorithms may be added in future. If it is still
> 231: required to use one of these algorithms, then they can be re-enabled by setting
> 232: this property to a comma separated list of the algorithm names.
Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example: https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:
> 73: // A net property which overrides the disabled set above.
> 74: private static final String enabledAlgPropName = "http.auth.digest." +
> 75: "reEnabledAlgs";
Why not put the string on one line?
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 658:
> 656: // truncate256 means only use the last 256 bits of the digest (32 bytes)
> 657: private String encode(String src, char[] passwd, MessageDigest md, boolean truncate256) {
> 658: md.update(src.getBytes(ISO_8859_1.INSTANCE));
Maybe we can support the "charset" parameter as well. The only allowed value is "UTF-8".
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
> 668: if (truncate256) {
> 669: assert digest.length >= 32;
> 670: start = digest.length - 32;
Does this mean the left half is truncated? My understanding is that the right half should be.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From duke at openjdk.java.net Fri Mar 4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of
lines
Message-ID:
Hi
I have reviewed the code for removing double semicolons at the end of lines
all the best
matteo
-------------
Commit messages:
- Removed double semicolon at the end of lines
Changes: https://git.openjdk.java.net/jdk/pull/7268/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7268&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8282657
Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod
Patch: https://git.openjdk.java.net/jdk/pull/7268.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7268/head:pull/7268
PR: https://git.openjdk.java.net/jdk/pull/7268
From duke at openjdk.java.net Fri Mar 4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Hi
I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
Now: what is the next step?
This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.
ciao
matteo
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From jwaters at openjdk.java.net Fri Mar 4 16:56:26 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Fri, 4 Mar 2022 16:56:26 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> Hi
>
> I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
> Now: what is the next step?
>
> This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.
>
> ciao
> matteo
Hi @matteobaccan
The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry.
Cheers,
Julian
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From lancea at openjdk.java.net Fri Mar 4 17:07:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Mar 2022 17:07:59 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
The changes look OK. The copyright year probably should be updated as part of this PR
-------------
Marked as reviewed by lancea (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7268
From duke at openjdk.java.net Fri Mar 4 17:14:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 17:14:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Hi Lance
I can make a second commit updating the copyright year
Tell me if this is necessary
ciao
matteo
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From rriggs at openjdk.java.net Fri Mar 4 17:20:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 17:20:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot.
And corresponding tests.
This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
If you had ask ahead of time, I would have suggested finding something with more value.
-------------
Changes requested by rriggs (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7268
From ihse at openjdk.java.net Fri Mar 4 17:50:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Mar 2022 17:50:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot.
> And corresponding tests.
> This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
> If you had ask ahead of time, I would have suggested finding something with more value.
@RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done.
I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From prr at openjdk.java.net Fri Mar 4 19:10:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 19:10:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Marked as reviewed by prr (Reviewer).
Looks like there's only one client source code file touched
Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From rriggs at openjdk.java.net Fri Mar 4 19:33:06 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 19:33:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Marked as reviewed by rriggs (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From iris at openjdk.java.net Fri Mar 4 19:43:03 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 4 Mar 2022 19:43:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Nice tidy of the code.
Is there anything that can be done to prevent re-introduction of this trivial problem? Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace?
-------------
Marked as reviewed by iris (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7268
From wetmore at openjdk.java.net Fri Mar 4 19:56:03 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Mar 2022 19:56:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com>
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
LGTM also.
Similar suggestion for updating copyrights.
-------------
Marked as reviewed by wetmore (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7268
From ecki at zusammenkunft.net Fri Mar 4 20:50:50 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 4 Mar 2022 20:50:50 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
Thanks for the clarification Michael,
I was actually wrongly assuming that the client has to propose the method. If the server can do that, then it is relative risk free to support additional algorithms on the client side (and ignore a challenge if it requests disabled algorithm (this would include md5 default for absent attribute)).
Did not know the WWW-Authenticate header does that.
Still I would Seperate the md5 deprecation from the implementation of alternative algorithms to make a larger cut-over window (maybe even schedule it in the Oracle crypto roadmap)
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Michael McMahon
Gesendet: Friday, March 4, 2022 4:07:49 PM
An: Bernd Eckenfels ; net-dev at openjdk.java.net
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
Bernd,
If I understand you correctly, there is no negotiation at this level. Once Digest is selected, it's up to the server to choose the algorithm and then the client can either accept it or else reject it and the whole request fails then.
It's true that with this change, if the server proposes MD5 by default, then the request will fail. But, that's the point of the change, and the compatibility impact is considered in the related CSR. In that case, either the server needs to change or else the system property to re-enable MD5 must be set.
I'd like to try out (for the next review round) the idea of establishing the default "insecure" protocols as a fixed security property (including MD5 and SHA-1) and then provide a settable system or networking property to override that.
Thanks
Michael
On 04/03/2022 14:03, Bernd Eckenfels wrote:
Hello,
While I like the idea of the user having to explicitely specify the rexenabled legacy algorithms (as opposed to removing the defaultsdisabled) it is not the style the other algorithm policies in JCE work - so it might be confusing.
But, more critically I would separate the enabling/implementing of new algorithms from disabling old ones. Especially since there needs to be changes on the server side first. (And I wonder if this can be negotiated anyway?).
So why not start with a ?provide new DIGEST Mechanisms? change? Having said that, would it need to start out with disabled new mechanisms so the update won?t change the behavior? (If there is no negotiation?)
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev im Auftrag von Michael McMahon
Gesendet: Friday, March 4, 2022 1:33:06 PM
An: net-dev at openjdk.java.net
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
Hi,
Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
- Michael
I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From darcy at openjdk.java.net Fri Mar 4 21:23:30 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:23:30 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException
Message-ID: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
-------------
Commit messages:
- JDK-8282686: Add constructors take a cause to SocketException
Changes: https://git.openjdk.java.net/jdk/pull/7705/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8282686
Stats: 48 lines in 6 files changed: 23 ins; 12 del; 13 mod
Patch: https://git.openjdk.java.net/jdk/pull/7705.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705
PR: https://git.openjdk.java.net/jdk/pull/7705
From darcy at openjdk.java.net Fri Mar 4 21:33:07 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:33:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Marked as reviewed by darcy (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From wetmore at openjdk.java.net Fri Mar 4 23:47:07 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Mar 2022 23:47:07 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
[v2]
In-Reply-To:
References:
Message-ID:
On Thu, 3 Mar 2022 12:36:33 GMT, zzambers wrote:
>> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
>> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
>
> Updated copyright for SSLSocket.java
There are more changes needed, and should probably be done as part of this issue since we're already in this code anyway. The current code only talks about shutdownInput/shutdownOutput, but makes no mention of the duplex close(), which is the other way to shutdown the SSLSocket. It only needs a few words.
https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029167.html
These two changes will require a CSR to update the @apiNote.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From dholmes at openjdk.java.net Sat Mar 5 05:52:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 5 Mar 2022 05:52:04 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com>
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
I eyeballed the diff file and all seems okay.
Thanks,
David
-------------
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7268
From jwaters at openjdk.java.net Sat Mar 5 06:52:13 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Sat, 5 Mar 2022 06:52:13 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Nice, good work matteo
Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From duke at openjdk.java.net Sat Mar 5 07:22:03 2022
From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=)
Date: Sat, 5 Mar 2022 07:22:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From alanb at openjdk.java.net Sat Mar 5 09:50:03 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 5 Mar 2022 09:50:03 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID:
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
This looks good, I just wonder if we should add a test for the new constructors. One of them will be tested by the usages in the JDK, the cause-only constructor may not be exercised by any code.
-------------
Marked as reviewed by alanb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7705
From jpai at openjdk.java.net Sat Mar 5 15:11:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 5 Mar 2022 15:11:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 514:
> 512: if (getAuthType() == AuthCacheValue.Type.Server &&
> 513: getProtocolScheme().equals("https")) {
> 514: // HTTPS server authentication can use any algorithm
Hello Michael,
Should it be noted somewhere in the text of the linked CSR that the property values play no role if the request URL's scheme is HTTPS (and proxy isn't involved)?
As a related question - should the implementation even bother about this HTTP vs HTTPS protocol check? As far as I understand, the reason why we are proposing to disable support for MD5 is because of its cryptographic weakness/vulnerabilities. So irrespective of whether or not the computed MD5 (or any other disabled algorithm) digest value gets transferred over HTTP or HTTPS, the value would still be cryptographically vulnerable isn't it?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From xuelei at openjdk.java.net Sat Mar 5 16:16:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 5 Mar 2022 16:16:55 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <6YOD-AAXJFwPkF-qNokBEUTyQaX2BnN4MIXPnuGng-4=.b1a042d3-b548-4fd4-bacf-45aa8f4cb315@github.com>
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
Looks good to me. I may file a new RFE and use this constructor in the JSSE implementation.
-------------
Marked as reviewed by xuelei (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7705
From lancea at openjdk.java.net Sat Mar 5 16:48:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 5 Mar 2022 16:48:59 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID:
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
Looks fine, would be worth including a couple of tests for coverage
-------------
Marked as reviewed by lancea (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7705
From xuelei at openjdk.java.net Sun Mar 6 05:40:59 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 6 Mar 2022 05:40:59 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v19]
In-Reply-To:
References:
Message-ID:
> This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290
Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
add test for DTLS
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7252/files
- new: https://git.openjdk.java.net/jdk/pull/7252/files/5a98c921..ca006ee0
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=18
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=17-18
Stats: 134 lines in 1 file changed: 134 ins; 0 del; 0 mod
Patch: https://git.openjdk.java.net/jdk/pull/7252.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252
PR: https://git.openjdk.java.net/jdk/pull/7252
From xuelei at openjdk.java.net Sun Mar 6 05:40:59 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 6 Mar 2022 05:40:59 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v18]
In-Reply-To:
References:
Message-ID:
On Fri, 4 Mar 2022 16:29:04 GMT, Sean Mullan wrote:
> Since this new API is also intended to be supported for DTLS, have you added implementation support for that, and if so have you added a test for it?
Yes, the DTLS implementation is included. I added a test case for DTLS.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7252
From jpai at openjdk.java.net Sun Mar 6 06:43:00 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 6 Mar 2022 06:43:00 GMT
Subject: RFR: 8282617:
sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
lock while dealing with inCache field
In-Reply-To:
References:
Message-ID:
On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617?
>
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
>
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
>
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.
Thank you Michael and Daniel for the reviews. The tier1 and tier2 testing came back as successful.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7680
From jpai at openjdk.java.net Sun Mar 6 08:20:05 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 6 Mar 2022 08:20:05 GMT
Subject: Integrated: 8282617:
sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
lock while dealing with "inCache" field
In-Reply-To:
References:
Message-ID:
On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617?
>
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
>
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
>
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.
This pull request has now been integrated.
Changeset: 974ef554
Author: Jaikiran Pai
URL: https://git.openjdk.java.net/jdk/commit/974ef5542fe52f9cb8ffd8751df8a020bca503c9
Stats: 13 lines in 1 file changed: 7 ins; 2 del; 4 mod
8282617: sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a lock while dealing with "inCache" field
Reviewed-by: dfuchs, michaelm
-------------
PR: https://git.openjdk.java.net/jdk/pull/7680
From xuelei at openjdk.java.net Mon Mar 7 08:03:29 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 08:03:29 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
Message-ID: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
-------------
Commit messages:
- 8282723: Add constructors taking a cause to JSSE exceptions
Changes: https://git.openjdk.java.net/jdk/pull/7722/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8282723
Stats: 174 lines in 19 files changed: 64 ins; 48 del; 62 mod
Patch: https://git.openjdk.java.net/jdk/pull/7722.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722
PR: https://git.openjdk.java.net/jdk/pull/7722
From ccleary at openjdk.java.net Mon Mar 7 08:23:46 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Mar 2022 08:23:46 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
Promise that is too large [v2]
In-Reply-To:
References:
Message-ID:
> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>
>
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
>
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
8263031: Tidied up import statements
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7696/files
- new: https://git.openjdk.java.net/jdk/pull/7696/files/527cfacb..664a1105
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=00-01
Stats: 35 lines in 1 file changed: 31 ins; 0 del; 4 mod
Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696
PR: https://git.openjdk.java.net/jdk/pull/7696
From ccleary at openjdk.java.net Mon Mar 7 08:23:47 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Mar 2022 08:23:47 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
Promise that is too large
In-Reply-To:
References:
Message-ID:
On Fri, 4 Mar 2022 15:17:11 GMT, Conor Cleary wrote:
> I see that a couple of imports got changed by my IDE, will address that shortly
Now resolved
-------------
PR: https://git.openjdk.java.net/jdk/pull/7696
From dfuchs at openjdk.java.net Mon Mar 7 10:27:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 10:27:58 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID:
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
Marked as reviewed by dfuchs (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7705
From michaelm at openjdk.java.net Mon Mar 7 11:04:02 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 7 Mar 2022 11:04:02 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:
>
>> 230: includes {@code MD5} but other algorithms may be added in future. If it is still
>> 231: required to use one of these algorithms, then they can be re-enabled by setting
>> 232: this property to a comma separated list of the algorithm names.
>
> Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example: https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228
Right, probably better to allow whitespace, which seems to be commonly used in the existing security properties
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:
>
>> 73: // A net property which overrides the disabled set above.
>> 74: private static final String enabledAlgPropName = "http.auth.digest." +
>> 75: "reEnabledAlgs";
>
> Why not put the string on one line?
I'll try and see if it fits the normal line width
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
>
>> 668: if (truncate256) {
>> 669: assert digest.length >= 32;
>> 670: start = digest.length - 32;
>
> Does this mean the left half is truncated? My understanding is that the right half should be.
Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From ecki at zusammenkunft.net Mon Mar 7 11:27:45 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 7 Mar 2022 11:27:45 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
Message-ID:
Hello,
SHA-512/256 is normally not a simple truncation (because similiar hashes are not a robust crypto practice, instead it is using different initialisation vectors).
Haven?t checked the example vectors in rfc 7616, but I would asume they refer to FIPS 180-4 truncation variants.
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev im Auftrag von Michael McMahon
Gesendet: Monday, March 7, 2022 12:04:02 PM
An: net-dev at openjdk.java.net
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:
>
>> 230: includes {@code MD5} but other algorithms may be added in future. If it is still
>> 231: required to use one of these algorithms, then they can be re-enabled by setting
>> 232: this property to a comma separated list of the algorithm names.
>
> Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example: https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228
Right, probably better to allow whitespace, which seems to be commonly used in the existing security properties
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:
>
>> 73: // A net property which overrides the disabled set above.
>> 74: private static final String enabledAlgPropName = "http.auth.digest." +
>> 75: "reEnabledAlgs";
>
> Why not put the string on one line?
I'll try and see if it fits the normal line width
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
>
>> 668: if (truncate256) {
>> 669: assert digest.length >= 32;
>> 670: start = digest.length - 32;
>
> Does this mean the left half is truncated? My understanding is that the right half should be.
Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ccleary at openjdk.java.net Mon Mar 7 11:41:05 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Mar 2022 11:41:05 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
Promise that is too large [v2]
In-Reply-To:
References:
Message-ID:
On Mon, 7 Mar 2022 08:23:46 GMT, Conor Cleary wrote:
>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>>
>>
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>>
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>>
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>>
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>>
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>
> 8263031: Tidied up import statements
test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 227:
> 225: map.put("x-promise", List.of(mainPromiseBody));
> 226: HttpHeaders headers = HttpHeaders.of(map, ACCEPT_ALL);
> 227: exchange.serverPush(uri, headers, is);
Could create all of the headers here instead of in Http2LPPTestExchangeImpl, might improve readability of test.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7696
From michaelm at openjdk.java.net Mon Mar 7 12:00:59 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 7 Mar 2022 12:00:59 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Fri, 4 Mar 2022 16:26:52 GMT, Weijun Wang wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 658:
>
>> 656: // truncate256 means only use the last 256 bits of the digest (32 bytes)
>> 657: private String encode(String src, char[] passwd, MessageDigest md, boolean truncate256) {
>> 658: md.update(src.getBytes(ISO_8859_1.INSTANCE));
>
> Maybe we can support the "charset" parameter as well. The only allowed value is "UTF-8".
I'll look into supporting that.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From dfuchs at openjdk.java.net Mon Mar 7 12:09:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 12:09:04 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan wrote:
> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
LGTM. Someone from security-dev should probably review this too.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7722
From michaelm at openjdk.java.net Mon Mar 7 12:24:08 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 7 Mar 2022 12:24:08 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID:
On Sat, 5 Mar 2022 15:07:15 GMT, Jaikiran Pai wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 514:
>
>> 512: if (getAuthType() == AuthCacheValue.Type.Server &&
>> 513: getProtocolScheme().equals("https")) {
>> 514: // HTTPS server authentication can use any algorithm
>
> Hello Michael,
> Should it be noted somewhere in the text of the linked CSR that the property values play no role if the request URL's scheme is HTTPS (and proxy isn't involved)?
>
> As a related question - should the implementation even bother about this HTTP vs HTTPS protocol check? As far as I understand, the reason why we are proposing to disable support for MD5 is because of its cryptographic weakness/vulnerabilities. So irrespective of whether or not the computed MD5 (or any other disabled algorithm) digest value gets transferred over HTTP or HTTPS, the value would still be cryptographically vulnerable isn't it?
The distinction may be worth mentioning in the CSR and the docs. The distinction is useful because like Basic authentication which is completely insecure with plaintext HTTP, it is secure and a potentially useful web authentication scheme controlled by the browser when run over HTTPS (except when authenticating with HTTPS to a proxy).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From michael.x.mcmahon at oracle.com Mon Mar 7 12:24:36 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 7 Mar 2022 12:24:36 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
Message-ID:
Bernd,
In that case we should defer to the security libraries to implement
SHA-512-256, which does not seem to be supported currently. We already
support SHA-512 so that should be sufficient at this point.
Thanks
Michael.
On 07/03/2022 11:27, Bernd Eckenfels wrote:
> Hello,
>
> SHA-512/256 is normally not a simple truncation (because similiar hashes are not a robust crypto practice, instead it is using different initialisation vectors).
>
> Haven?t checked the example vectors in rfc 7616, but I would asume they refer to FIPS 180-4 truncation variants.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: net-dev im Auftrag von Michael McMahon
> Gesendet: Monday, March 7, 2022 12:04:02 PM
> An:net-dev at openjdk.java.net
> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
>
> On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang wrote:
>
>>> Hi,
>>>
>>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>>
>>> - Michael
>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:
>>
>>> 230: includes {@code MD5} but other algorithms may be added in future. If it is still
>>> 231: required to use one of these algorithms, then they can be re-enabled by setting
>>> 232: this property to a comma separated list of the algorithm names.
>> Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example:https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228
> Right, probably better to allow whitespace, which seems to be commonly used in the existing security properties
>
>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:
>>
>>> 73: // A net property which overrides the disabled set above.
>>> 74: private static final String enabledAlgPropName = "http.auth.digest." +
>>> 75: "reEnabledAlgs";
>> Why not put the string on one line?
> I'll try and see if it fits the normal line width
>
>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
>>
>>> 668: if (truncate256) {
>>> 669: assert digest.length >= 32;
>>> 670: start = digest.length - 32;
>> Does this mean the left half is truncated? My understanding is that the right half should be.
> Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/7688
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dfuchs at openjdk.java.net Mon Mar 7 12:35:07 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 12:35:07 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
Promise that is too large [v2]
In-Reply-To:
References:
Message-ID:
On Mon, 7 Mar 2022 08:23:46 GMT, Conor Cleary wrote:
>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>>
>>
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>>
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>>
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>>
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>>
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>
> 8263031: Tidied up import statements
src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 82:
> 80: import java.util.function.Function;
> 81: import java.util.function.Supplier;
> 82:
Could we keep the original alphabetical ordering and have the java.* imports come before the jdk.* imports?
src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 780:
> 778:
> 779: if (!(frame instanceof ResetFrame)) {
> 780: if (frame instanceof DataFrame) {
we could use instanceof pattern matching here to get rid of the cast
src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 799:
> 797: }
> 798:
> 799: // While pus frame is not null, the only acceptable frame on this
is there a letter missing in `pus` ?
src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 803:
> 801: if (pcs != null) {
> 802: if (frame instanceof ContinuationFrame cf) {
> 803: handlePushContinuation(stream, cf);
IOException should probably be caught and transformed in protocol error here to?
In case of protocol error when handling push promise (or their continuation) - should `pcs` be reset to null?
Maybe it doesn't matter since we're closing the connection anyway.
src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 805:
> 803: handlePushContinuation(stream, cf);
> 804: } else {
> 805: // TODO: Maybe say what kind of frame was received instead
We should either do it or remove the TODO. @Michael-Mc-Mahon what would you suggest here?
src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 855:
> 853:
> 854: private record PushContinuationState(HeaderDecoder pushContDecoder, PushPromiseFrame pushContFrame) {}
> 855: private volatile PushContinuationState pcs;
I'd prefer to have a longer name than `pcs` - `pushContinuationState` would make it less mysterious at the place where it's used. Also it could be good to move these declarations (linew 854 and 855) higher in the file, where other instance variables are declared.
test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 25:
> 23:
> 24: /*
> 25: * @test
Please add an `@bug 8263031` tag here
test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 33:
> 31: * java.net.http/jdk.internal.net.http.hpack
> 32: * @run testng/othervm PushPromiseContinuation
> 33: */
It would be good to add an @summary tag to explain the purpose of this test
test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 176:
> 174: ContinuationFrame cf = new ContinuationFrame(streamid, HeaderFrame.END_HEADERS, encodedHeaders);
> 175:
> 176: try {
It would be good to have a test-case that creates 2 continuation frames too.
test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 231:
> 229: }
> 230: }
> 231: }
missing newline at end of file?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7696
From michael.x.mcmahon at oracle.com Mon Mar 7 12:43:20 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 7 Mar 2022 12:43:20 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
Message-ID: <31668053-0d17-99a9-3feb-2254274790d6@oracle.com>
I'm wrong. It is implemented in the security libs. So, that means we can
support it also
Michael
On 07/03/2022 12:24, Michael McMahon wrote:
> Bernd,
>
> In that case we should defer to the security libraries to implement
> SHA-512-256, which does not seem to be supported currently. We already
> support SHA-512 so that should be sufficient at this point.
>
> Thanks
>
> Michael.
>
> On 07/03/2022 11:27, Bernd Eckenfels wrote:
>> Hello,
>>
>> SHA-512/256 is normally not a simple truncation (because similiar
>> hashes are not a robust crypto practice, instead it is using
>> different initialisation vectors).
>>
>> Haven?t checked the example vectors in rfc 7616, but I would asume
>> they refer to FIPS 180-4 truncation variants.
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> ________________________________
>> Von: net-dev? im Auftrag von Michael
>> McMahon
>> Gesendet: Monday, March 7, 2022 12:04:02 PM
>> An:net-dev at openjdk.java.net
>> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by
>> default
>>
>> On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang? wrote:
>>
>>>> Hi,
>>>>
>>>> Could I get the following change reviewed please, which is to
>>>> disable the MD5 message digest algorithm by default in the HTTP
>>>> Digest authentication mechanism? The algorithm can be opted into by
>>>> setting a new system property "http.auth.digest.reEnabledAlgs" to
>>>> include the value MD5. The change also updates the Digest
>>>> authentication implementation to use some of the more secure
>>>> features defined in RFC7616, such as username hashing and
>>>> additional digest algorithms like SHA256 and SHA512-256.
>>>>
>>>> - Michael
>>> src/java.base/share/classes/java/net/doc-files/net-properties.html
>>> line 232:
>>>
>>>> 230:???????? includes {@code MD5} but other algorithms may be added
>>>> in future. If it is still
>>>> 231:???????? required to use one of these algorithms, then they can
>>>> be re-enabled by setting
>>>> 232:???????? this property to a comma separated list of the
>>>> algorithm names.
>>> Is it necessary to emphasize that no whitespace is allowed around
>>> the comma in the property value? Or is it better to modify the
>>> implementation below to allow whitespaces? I notice that whitespace
>>> is allowed in some of the other properties. For
>>> example:https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228
>> Right, probably better to allow whitespace, which seems to be
>> commonly used in the existing security properties
>>
>>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>>> line 75:
>>>
>>>> 73:???? // A net property which overrides the disabled set above.
>>>> 74:???? private static final String enabledAlgPropName =
>>>> "http.auth.digest." +
>>>> 75:???????? "reEnabledAlgs";
>>> Why not put the string on one line?
>> I'll try and see if it fits the normal line width
>>
>>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>>> line 670:
>>>
>>>> 668:???????? if (truncate256) {
>>>> 669:???????????? assert digest.length >= 32;
>>>> 670:???????????? start = digest.length - 32;
>>> Does this mean the left half is truncated? My understanding is that
>>> the right half should be.
>> Okay, I'll double check that. I haven't found any server
>> implementations of this feature to test with yet,
>>
>> -------------
>>
>> PR:https://git.openjdk.java.net/jdk/pull/7688
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From erikj at openjdk.java.net Mon Mar 7 13:44:05 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 7 Mar 2022 13:44:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters wrote:
> Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?
They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From weijun at openjdk.java.net Mon Mar 7 14:26:08 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 7 Mar 2022 14:26:08 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
Message-ID:
On Mon, 7 Mar 2022 11:01:16 GMT, Michael McMahon wrote:
>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
>>
>>> 668: if (truncate256) {
>>> 669: assert digest.length >= 32;
>>> 670: start = digest.length - 32;
>>
>> Does this mean the left half is truncated? My understanding is that the right half should be.
>
> Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,
2nd test of https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 is on this algorithm, but it requires UTF-8 charset support and a way to provide a predefined cnonce. If it's not worth modifying our implementation to create a regression test, I think at least we can temporarily hack our own JDK and try on it. And I think it's most likely true that this algorithm is using a different initialization vector as Bernd pointed out.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From weijun at openjdk.java.net Mon Mar 7 14:45:04 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 7 Mar 2022 14:45:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To:
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
<4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
Message-ID:
On Mon, 7 Mar 2022 14:22:58 GMT, Weijun Wang wrote:
>> Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,
>
> 2nd test of https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 is on this algorithm, but it requires UTF-8 charset support and a way to provide a predefined cnonce. If it's not worth modifying our implementation to create a regression test, I think at least we can temporarily hack our own JDK and try on it. And I think it's most likely true that this algorithm is using a different initialization vector as Bernd pointed out.
As https://www.rfc-editor.org/errata_search.php?rfc=7616&rec_status=0 shows, that 2nd test in rfc7616 was wrong in the initial version as it used a truncated version of SHA-512. The real SHA-512/256 algorithm should be used.
$ jshell
jshell> import java.security.MessageDigest
jshell> HexFormat.of().formatHex(MessageDigest.getInstance("SHA-512").digest("J\u00e4s\u00f8n Doe:api at example.org".getBytes("UTF-8")))
$2 ==> "488869477bf257147b804c45308cd62ac4e25eb717b12b298c79e62dcea254ec5211a6631b181289b4dd8c14890f38f04bff8a388106dabb900c6984ba592b6a"
jshell> HexFormat.of().formatHex(MessageDigest.getInstance("SHA-512/256").digest("J\u00e4s\u00f8n Doe:api at example.org".getBytes("UTF-8")))
$3 ==> "793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b"
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From jwaters at openjdk.java.net Mon Mar 7 16:24:00 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Mon, 7 Mar 2022 16:24:00 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson wrote:
> > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?
>
> They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.
Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From duke at openjdk.java.net Mon Mar 7 16:37:07 2022
From: duke at openjdk.java.net (zzambers)
Date: Mon, 7 Mar 2022 16:37:07 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
[v2]
In-Reply-To:
References:
Message-ID:
On Fri, 4 Mar 2022 23:43:30 GMT, Bradford Wetmore wrote:
>> zzambers has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Updated copyright for SSLSocket.java
>
> There are more changes needed, and should probably be done as part of this issue since we're already in this code anyway. The current code only talks about shutdownInput/shutdownOutput, but makes no mention of the duplex close(), which is the other way to shutdown the SSLSocket. It only needs a few words.
>
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029167.html
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html
>
> These two changes will require a CSR to update the @ apiNote.
@bradfordwetmore Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7648
From lancea at openjdk.java.net Mon Mar 7 16:43:08 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Mar 2022 16:43:08 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
What problem are you having editing the PR header? You should be able to do so as the author of the PR
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From kcr at openjdk.java.net Mon Mar 7 16:52:07 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:52:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote:
> What problem are you having editing the PR header? You should be able to do so as the author of the PR
Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image:

-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From kcr at openjdk.java.net Mon Mar 7 16:56:06 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:56:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
But as the JBS title and PR title now match, this is a moot point.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From kcr at openjdk.java.net Mon Mar 7 17:18:03 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie wrote:
> TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.
Ah, that explains it then.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From ihse at openjdk.java.net Mon Mar 7 17:18:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
of lines
In-Reply-To:
References:
Message-ID:
On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> What problem are you having editing the PR header? You should be able to do so as the author of the PR
@LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7268
From darcy at openjdk.java.net Mon Mar 7 17:43:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:43:50 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
SocketException [v2]
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID:
> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
Joe Darcy 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:
- Add regression test.
- Merge branch 'master' into JDK-8282686
- JDK-8282686: Add constructors take a cause to SocketException
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7705/files
- new: https://git.openjdk.java.net/jdk/pull/7705/files/e65f9ae5..978b379d
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=00-01
Stats: 8268 lines in 175 files changed: 6072 ins; 1565 del; 631 mod
Patch: https://git.openjdk.java.net/jdk/pull/7705.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705
PR: https://git.openjdk.java.net/jdk/pull/7705
From darcy at openjdk.java.net Mon Mar 7 17:55:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:55:45 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
SocketException [v3]
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>
> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Improve test.
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7705/files
- new: https://git.openjdk.java.net/jdk/pull/7705/files/978b379d..da863692
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=01-02
Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod
Patch: https://git.openjdk.java.net/jdk/pull/7705.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705
PR: https://git.openjdk.java.net/jdk/pull/7705
From darcy at openjdk.java.net Mon Mar 7 17:55:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:55:47 GMT
Subject: Integrated: JDK-8282686: Add constructors taking a cause to
SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID:
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
This pull request has now been integrated.
Changeset: 1faa5c80
Author: Joe Darcy
URL: https://git.openjdk.java.net/jdk/commit/1faa5c8092f8baec3ca08ed059653876ec46db46
Stats: 102 lines in 7 files changed: 77 ins; 12 del; 13 mod
8282686: Add constructors taking a cause to SocketException
Reviewed-by: alanb, xuelei, lancea, dfuchs
-------------
PR: https://git.openjdk.java.net/jdk/pull/7705
From djelinski at openjdk.java.net Mon Mar 7 17:59:08 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 7 Mar 2022 17:59:08 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
environments [v7]
In-Reply-To:
References:
Message-ID:
On Mon, 7 Feb 2022 09:14:51 GMT, Daniel Jeli?ski wrote:
>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>
> Initialize return value in all cases
Hi!
Would it help with the review if I split this patch into smaller portions? It contains 20-ish independent fixes for memory leaks, invalid free, and incorrect return value handling; I could easily put each of these changes in a separate PR if that helps.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6090
From wetmore at openjdk.java.net Mon Mar 7 19:24:04 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 19:24:04 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan wrote:
> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
src/java.base/share/classes/javax/net/ssl/SSLException.java line 52:
> 50: */
> 51: public SSLException(String reason)
> 52: {
Thanks for changing the style. I've always hated the extra vertical space. :)
-------------
PR: https://git.openjdk.java.net/jdk/pull/7722
From xuelei at openjdk.java.net Mon Mar 7 19:42:47 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 19:42:47 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
[v2]
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
typo correction
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7722/files
- new: https://git.openjdk.java.net/jdk/pull/7722/files/20c0c6b6..edb185ec
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/7722.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722
PR: https://git.openjdk.java.net/jdk/pull/7722
From alanb at openjdk.java.net Mon Mar 7 19:44:13 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 7 Mar 2022 19:44:13 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
SocketException [v3]
In-Reply-To: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
<7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>
Message-ID:
On Mon, 7 Mar 2022 17:55:45 GMT, Joe Darcy wrote:
>> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>>
>> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>
> Improve test.
Hmm, this seems to have been integrated without any Reviewer on the final commit. How did that happen?
test/jdk/java/net/SocketException/TestSocketExceptionCtor.java line 32:
> 30: import java.util.Objects;
> 31:
> 32: public class TestSocketExceptionCtor {
I don't think this is a good name for the test because it tests mores than the constructors. So I think drop the suffix from the name.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7705
From rhalade at openjdk.java.net Mon Mar 7 20:06:57 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 7 Mar 2022 20:06:57 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
[v2]
In-Reply-To:
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>>
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>
> typo correction
Please consider adding simple tests to cover new APIs, similar to https://github.com/openjdk/jdk/pull/7705/files#diff-28e1041be519b6266b3b92aea29c5d8917c279880da7e5e9823a518196e96ea5
-------------
PR: https://git.openjdk.java.net/jdk/pull/7722
From rhalade at openjdk.java.net Mon Mar 7 20:26:56 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 7 Mar 2022 20:26:56 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
[v2]
In-Reply-To:
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>>
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>
> typo correction
Update following for SSLPeerUnverifiedException -
https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java#L439
-------------
PR: https://git.openjdk.java.net/jdk/pull/7722
From wetmore at openjdk.java.net Mon Mar 7 20:33:01 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 20:33:01 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
[v2]
In-Reply-To:
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>>
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>
> typo correction
src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158:
> 156: } catch (GeneralSecurityException gse) {
> 157: throw new SSLHandshakeException(
> 158: "Could not generate secret", gse);
I can't quite tell given the coloring, but did this get changed into a tab?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7722
From mullan at openjdk.java.net Mon Mar 7 20:38:03 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Mar 2022 20:38:03 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <5mHz6hrcfrSlsZOjP7VFi0VhF3k29LBmX2xm8HpGiEI=.b7da60be-6b1e-492d-9100-1e4752d5a2b3@github.com>
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael
src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 514:
> 512: if (getAuthType() == AuthCacheValue.Type.Server &&
> 513: getProtocolScheme().equals("https")) {
> 514: // HTTPS server authentication can use any algorithm
A more security conscious user may want to disable MD5 digest authentication, even when used over HTTPS, even though the risks are far less than when used over HTTP. Is there a way to do that?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7688
From wetmore at openjdk.java.net Mon Mar 7 20:45:05 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 20:45:05 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
[v2]
In-Reply-To:
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>>
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>
> typo correction
Didn't see any unit tests for the new methods. Can approve after they are included.
src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204:
> 202: } catch (GeneralSecurityException | java.io.IOException e) {
> 203: throw new SSLHandshakeException(
> 204: "Could not generate ECPublicKey", e);
Nit: I think combining these lines would be < 80 chars
src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 263:
> 261: fragment = plaintext.fragment;
> 262: contentType = plaintext.contentType;
> 263: } catch (BadPaddingException bpe) {
Does the copyright need to get updated?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7722
From xuelei at openjdk.java.net Mon Mar 7 20:45:06 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 20:45:06 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
[v2]
In-Reply-To:
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID:
On Mon, 7 Mar 2022 20:30:07 GMT, Bradford Wetmore wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>>
>> typo correction
>
> src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158:
>
>> 156: } catch (GeneralSecurityException gse) {
>> 157: throw new SSLHandshakeException(
>> 158: "Could not generate secret", gse);
>
> I can't quite tell given the coloring, but did this get changed into a tab?
Yes, I added 4 more whitespaces in line 158.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7722
From wetmore at openjdk.java.net Mon Mar 7 20:45:06 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 20:45:06 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
[v2]
In-Reply-To:
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: