From jpai at openjdk.java.net Mon Jan 3 04:34:57 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 3 Jan 2022 04:34:57 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v4] In-Reply-To: References: Message-ID: > This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137. > > The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections. Jaikiran Pai 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 17 additional commits since the last revision: - Merge latest master branch - Merge latest from master branch - add a security manager test to verify proper permission checks happen when local address is configured on HTTPClient - Merge latest from master branch - add a note to the javadoc of the new API to explain that calling localAddress() is only for advanced usages - move the security checks to the HttpClient itself instead of the builder - first round of security manager checks - use IPSupport in test and don't rely on ipv4/ipv6 being available - use correct IPv6 "any address" - Refactor the test to use the HttpServerAdapters test infrastructure - ... and 7 more: https://git.openjdk.java.net/jdk/compare/7aa67031...e2fd98c0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/b7a894c4..e2fd98c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=02-03 Stats: 6359 lines in 262 files changed: 4655 ins; 896 del; 808 mod Patch: https://git.openjdk.java.net/jdk/pull/6690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690 PR: https://git.openjdk.java.net/jdk/pull/6690 From jpai at openjdk.java.net Mon Jan 3 05:19:44 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 3 Jan 2022 05:19:44 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v5] In-Reply-To: References: Message-ID: > This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137. > > The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - copyright year - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/e2fd98c0..55ff2c13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=03-04 Stats: 10 lines in 9 files changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690 PR: https://git.openjdk.java.net/jdk/pull/6690 From duke at openjdk.java.net Tue Jan 4 09:15:16 2022 From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 4 Jan 2022 09:15:16 GMT Subject: RFR: 8262442 (windows) use all proxy configuration sources when java.net.useSystemProxies=true In-Reply-To: References: Message-ID: <68wMNRqwiMOhCzLWnu_8w1kyJL0LNMq6IGJxrM4NwUY=.881d4568-f690-4714-b096-4996d1209ae3@github.com> On Mon, 18 Oct 2021 19:25:12 GMT, Daniel Jeli?ski wrote: > With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available. > If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available) > If both the above options fail, selector uses the configured proxy. > > Verified on Windows 10 that: > - when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used > - when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method > - when `lpszAutoConfigUrl` is set and usable, the proxy returned is used > - when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method > - when `lpszProxy` is configured, that proxy is used > - otherwise selector uses direct connection > > The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate. bump ------------- PR: https://git.openjdk.java.net/jdk/pull/5995 From duke at openjdk.java.net Fri Jan 7 20:44:32 2022 From: duke at openjdk.java.net (duke) Date: Fri, 7 Jan 2022 20:44:32 GMT Subject: Withdrawn: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: On Wed, 13 Oct 2021 22:04:23 GMT, Mahendra Chhipa wrote: > There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : > JDK-8273142 > JDK-8268464 > JDK-8268133 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5937 From duke at openjdk.java.net Sat Jan 8 09:11:05 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Sat, 8 Jan 2022 09:11:05 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: > Clean up of various issues related to error handling and memory management Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: Address problems reported by clang-tidy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6090/files - new: https://git.openjdk.java.net/jdk/pull/6090/files/f440a6e0..ab24e7e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=01-02 Stats: 9 lines in 1 file changed: 5 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6090/head:pull/6090 PR: https://git.openjdk.java.net/jdk/pull/6090 From msheppar at openjdk.java.net Sat Jan 8 18:20:29 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 8 Jan 2022 18:20:29 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote: >> Clean up of various issues related to error handling and memory management > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Address problems reported by clang-tidy src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 256: > 254: > 255: ret = enumInterfaces(env, netifPP); > 256: if (ret == -1) { this change is questionable: enumInterfaces returns -2 to allows processing to continue with IPv6 data ... this change will prohibit that policy ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From msheppar at openjdk.java.net Sat Jan 8 19:04:29 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 8 Jan 2022 19:04:29 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote: >> Clean up of various issues related to error handling and memory management > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Address problems reported by clang-tidy src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 271: > 269: curr = *netifPP; > 270: ret = lookupIPAddrTable(env, &tableP); > 271: if (ret == -1) { on the face of it, this change looks reasonable as one might think "let the processing continue for IPv6", however it introduces some problems in subsequent processing. Most notably, it assigns a NULL value to tableP , which is then fed to the function enumAddresses_win_ipaddrtable and this performs a sanity check for tableP == NULL and returns 0. Also enumAddresses_win_ipaddrtable takes the inout parameter netaddr *netaddrP; which is a local variable (stack variable) which hasn't been properly initialized and only has a valid value assigned for a successful return from enumAddresses_win_ipaddrtable. Thus, this inout varaiable has indeterminates values (i.e. what ever is on the stack) which are then assigned in the else block (for the return 0 case) else{ curr->addrs = netaddrP; curr->naddrs += ret; curr = curr->next; } and so subsequent indeterminate processing and potental crash is significant as the netif data structures spurious pointer assignments I think the current coded return policy is good, but should probably include *netifPP = NULL as nothing is being returned. The function getAllInterfacesAndAddresses also inconsistently handles the out value of *netifPP as it is not always assigned a value in enumAddresses_win_ipaddrtable. As such the addition of call to free_netif on this pointer may lead to indeterminate behavious -- Thus the assignment and update of netifPP needs to be addressed src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 285: > 283: ret = enumAddresses_win_ipaddrtable(env, curr, &netaddrP, tableP); > 284: if (ret < 0) { > 285: free_netif(*netifPP); seems like the right thing to do, but *netifPP may not be properly assigned a valid pointer ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From msheppar at openjdk.java.net Sat Jan 8 19:14:26 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 8 Jan 2022 19:14:26 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote: >> Clean up of various issues related to error handling and memory management > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Address problems reported by clang-tidy I'm working through a number of related issues in this area .... I have applied your changes and run InetAddress and NetworkInterface sanity checks, and encountered some problems with these changes - as such we're working through the failures analysis - will provide approriate feedback in due course ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From msheppar at openjdk.java.net Sat Jan 8 20:32:28 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 8 Jan 2022 20:32:28 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote: >> Clean up of various issues related to error handling and memory management > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Address problems reported by clang-tidy src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 282: > 280: } > 281: while (curr != NULL) { > 282: netaddr *netaddrP; netaddr *netaddrP = NULL; just in case enumAddresses_win_ipaddrtable does not update it for an error return ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Mon Jan 10 07:40:31 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Mon, 10 Jan 2022 07:40:31 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 18:17:29 GMT, Mark Sheppard wrote: >> Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: >> >> Address problems reported by clang-tidy > > src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 256: > >> 254: >> 255: ret = enumInterfaces(env, netifPP); >> 256: if (ret == -1) { > > this change is questionable: enumInterfaces returns -2 to allows processing to continue with IPv6 data ... this change will prohibit that policy In my experiments the `enumInterfaces` succeeded in IPv6-only environment. The function only fails with -2 when a new interface is added during enumeration. I could modify the function to stop returning -2 if you think it makes sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Mon Jan 10 08:32:30 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Mon, 10 Jan 2022 08:32:30 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: <7DQCgUpsyE-gLpEOPW0NVequutEATLAVAi17K7_MCP4=.9d3542a0-41eb-4388-8fe5-81a034bdb1fc@github.com> On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote: >> Clean up of various issues related to error handling and memory management > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Address problems reported by clang-tidy Thanks for the review! Let me know if I can assist with the failure analysis. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Mon Jan 10 08:32:31 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Mon, 10 Jan 2022 08:32:31 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 19:00:52 GMT, Mark Sheppard wrote: >> Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: >> >> Address problems reported by clang-tidy > > src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 271: > >> 269: curr = *netifPP; >> 270: ret = lookupIPAddrTable(env, &tableP); >> 271: if (ret == -1) { > > on the face of it, this change looks reasonable as one might think "let the processing continue for IPv6", however it introduces some problems in subsequent processing. Most notably, it assigns a NULL value to tableP , which is then fed to the function enumAddresses_win_ipaddrtable and this performs a sanity check for tableP == NULL and returns 0. Also enumAddresses_win_ipaddrtable takes the inout parameter netaddr *netaddrP; which is a local variable (stack variable) which hasn't been properly initialized and only has a valid value assigned for a successful return from enumAddresses_win_ipaddrtable. Thus, this inout varaiable has indeterminates values (i.e. what ever is on the stack) which are then assigned in the else block (for the return 0 case) > else{ > curr->addrs = netaddrP; > curr->naddrs += ret; > curr = curr->next; > } > and so subsequent indeterminate processing and potental crash is significant as the netif data structures spurious pointer assignments > > I think the current coded return policy is good, but should probably include *netifPP = NULL as nothing is being returned. > > The function getAllInterfacesAndAddresses also inconsistently handles the out value of *netifPP as it is not always assigned a value in enumAddresses_win_ipaddrtable. As such the addition of call to free_netif on this pointer may lead to indeterminate behavious -- Thus the assignment and update of netifPP needs to be addressed I modified all functions to return sensible pointer values (possibly null) in all success (nonnegative) return cases. Returned pointers may contain nonsense only in failure cases. In particular, `enumAddresses_win_ipaddrtable` was fixed to set `*netaddrPP = NULL;` in 784d5fb332aee4215c02751636c848ffbb0da2b9. > src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 282: > >> 280: } >> 281: while (curr != NULL) { >> 282: netaddr *netaddrP; > > netaddr *netaddrP = NULL; just in case enumAddresses_win_ipaddrtable does not update it for an error return netaddrP is always updated when `enumAddresses_win_ipaddrtable` returns a nonnegative value > src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 285: > >> 283: ret = enumAddresses_win_ipaddrtable(env, curr, &netaddrP, tableP); >> 284: if (ret < 0) { >> 285: free_netif(*netifPP); > > seems like the right thing to do, but *netifPP may not be properly assigned a valid pointer `netifPP` is always assigned by `enumInterfaces` in nonnegative return cases. If `enumInterfaces` returns a negative value, this function (`getAllInterfacesAndAddresses`) aborts much earlier. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Mon Jan 10 09:42:38 2022 From: duke at openjdk.java.net (Pushkar N Kulkarni) Date: Mon, 10 Jan 2022 09:42:38 GMT Subject: RFR: JDK-8243376: java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation [v9] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 17:32:30 GMT, Jayashree S Kumar wrote: >> Issue >> >> https://bugs.openjdk.java.net/browse/JDK-8243376 >> >> Problem >> >> The scenario is: >> - Some specified target hostname resolves to two IP addresses (always the same address pair). >> - The DNS resolved order of the two ip addresses changes (a usual LoadBalancer type behavior). >> - The CNAME of the two ip addresses differ. >> >> In SocketPermission class(void getIP() method), it internally resolves and saves only the first IP address resolved, not all the IP addresses resolved. >> - Depending on when the implier/implied SocketPermission hostname is resolved, the resolved addresses order differs, and the internally saved IP address mismatches, resulting on SocketPermission#implies() false. >> >> >> Michael McMahon kindly reviewed and suggested changes: https://mail.openjdk.java.net/pipermail/net-dev/2020-May/014001.html > > Jayashree S Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Jcheck Review: Corrected the tab error @jaysk1 Thanks for this PR! I've left some questions inline. src/java.base/share/classes/java/net/SocketPermission.java line 1090: > 1088: > 1089: if (this.cnames != null) { > 1090: return this.cnames[0].equalsIgnoreCase(that.cnames[0]); @jaysk1 Can this comparison fail for SocketPermission objects that have multiple cname entries in different orders? src/java.base/share/classes/java/net/SocketPermission.java line 1123: > 1121: return this.getName().hashCode(); > 1122: else > 1123: return this.cnames[0].hashCode(); @jaysk1 Can this cause "equal" `SocketPermission` objects with the identical, multiple cname entries, but in a different order, to have unequal hash codes? test/jdk/java/net/SocketPermission/SocketPermissionIm.java line 26: > 24: break; > 25: } > 26: addIpToHostsFile(hostname, "1.2.3."+testPass, hostsFileName); nit: Looks like these needs an indentation correction. test/jdk/java/net/SocketPermission/SocketPermissionIm.java line 34: > 32: private static void addIpToHostsFile(String host, String addr, String hostsFileName) > 33: throws Exception { > 34: String mapping = addr + " " + host; nit: indentation? ------------- Changes requested by pushkarnk at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/1916 From duke at openjdk.java.net Mon Jan 10 09:59:36 2022 From: duke at openjdk.java.net (Pushkar N Kulkarni) Date: Mon, 10 Jan 2022 09:59:36 GMT Subject: RFR: JDK-8243376: java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation [v9] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 17:32:30 GMT, Jayashree S Kumar wrote: >> Issue >> >> https://bugs.openjdk.java.net/browse/JDK-8243376 >> >> Problem >> >> The scenario is: >> - Some specified target hostname resolves to two IP addresses (always the same address pair). >> - The DNS resolved order of the two ip addresses changes (a usual LoadBalancer type behavior). >> - The CNAME of the two ip addresses differ. >> >> In SocketPermission class(void getIP() method), it internally resolves and saves only the first IP address resolved, not all the IP addresses resolved. >> - Depending on when the implier/implied SocketPermission hostname is resolved, the resolved addresses order differs, and the internally saved IP address mismatches, resulting on SocketPermission#implies() false. >> >> >> Michael McMahon kindly reviewed and suggested changes: https://mail.openjdk.java.net/pipermail/net-dev/2020-May/014001.html > > Jayashree S Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Jcheck Review: Corrected the tab error src/java.base/share/classes/java/net/SocketPermission.java line 1002: > 1000: that.getCanonName(); > 1001: } > 1002: return this.cnames[0].equalsIgnoreCase(that.cnames[0]); @jaysk1 On the event of us reaching here, won't `this` and `that` have multiple canonical names each, in different orders? Do you think we need to compare the arrays here? ------------- PR: https://git.openjdk.java.net/jdk/pull/1916 From duke at openjdk.java.net Mon Jan 10 16:24:36 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 10 Jan 2022 16:24:36 GMT Subject: Integrated: 8274809: Update java.base classes to use try-with-resources In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov wrote: > 8274809: Update java.base classes to use try-with-resources This pull request has now been integrated. Changeset: dee447f8 Author: Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/dee447f8ae788c6c1f6cd1e1fcb93faceab37b6c Stats: 60 lines in 7 files changed: 2 ins; 40 del; 18 mod 8274809: Update java.base classes to use try-with-resources Reviewed-by: mullan, alanb, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5818 From msheppar at openjdk.java.net Mon Jan 10 20:02:30 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Mon, 10 Jan 2022 20:02:30 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v3] In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 07:37:24 GMT, Daniel Jelinski wrote: >> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 256: >> >>> 254: >>> 255: ret = enumInterfaces(env, netifPP); >>> 256: if (ret == -1) { >> >> this change is questionable: enumInterfaces returns -2 to allows processing to continue with IPv6 data ... this change will prohibit that policy > > In my experiments the `enumInterfaces` succeeded in IPv6-only environment. The function only fails with -2 when a new interface is added during enumeration. > I could modify the function to stop returning -2 if you think it makes sense. yes, that's what I have onserved also It looks like the error handling in enumInterfaces is cut and paste from lookupIPAddrTable, as per the comment // this different error code is to handle the case when we call // GetIpAddrTable in pure IPv6 environment return -2; when in fact it is calling GetIfTable and if that returns an error, it seems reasonable to terminate processing at that stage by throwing an appropriate exception ... I can't see how it can continue So it would seems that enumInterfaces curennt return value -2 is misleading ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From vyommani at gmail.com Tue Jan 11 06:50:07 2022 From: vyommani at gmail.com (Vyom Tiwari) Date: Tue, 11 Jan 2022 12:20:07 +0530 Subject: jdk11u build failure on Windows Message-ID: Hi, I am facing the build issue with OpenJDK11(jdk11u). I am trying to build jdk11u on Windows and I am getting the below error. #################### ./src/java.base/windows/native/libnet/net_util_md.c(792): error C2065: 'TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS': undeclared identifier make[3]: *** [Lib-java.base.gmk:44: /cygdrive/d/source/mirrors_github_jdk11u/build/windows-x86_64-normal-server-release/support/native/java.base/libnet/net_util_md.obj] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2 ERROR: Build failed for target 'images' in configuration 'windows-x86_64-normal-server-release' (exit code 2) Stopping sjavac server ################### I found that the back-port of JDK-8250521 is causing this failure. My environment details are as follows. OS: Windows Server 2016 Standard, Visual Studio professional 2017 version 15.2(26430.14) When I updated my Visual Studio to 15.9.42(which contains Windows 10 SDK(10.0.17134.0)) the problem went away. My question is do we have a minimum supported Visual Studio(15.9.42) to build jdk11u(11.0.14) ?. If this is not the case then I would like to fix this build failure. Thanks, Vyom -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Jan 11 11:00:46 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 11 Jan 2022 11:00:46 +0000 Subject: jdk11u build failure on Windows In-Reply-To: References: Message-ID: Hi Vyom, That's probably a question to ask on the jdk-updates-dev list, which I put in cc: best regards, -- daniel On 11/01/2022 06:50, Vyom Tiwari wrote: > Hi, > I am facing the build issue with ?OpenJDK11(jdk11u). I am trying to > build jdk11u on Windows and I am ?getting the below error. > > #################### > ./src/java.base/windows/native/libnet/net_util_md.c(792): error C2065: > 'TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS': undeclared identifier > make[3]: *** [Lib-java.base.gmk:44: > /cygdrive/d/source/mirrors_github_jdk11u/build/windows-x86_64-normal-server-release/support/native/java.base/libnet/net_util_md.obj] > Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2 > > ERROR: Build failed for target 'images' in configuration > 'windows-x86_64-normal-server-release' (exit code 2) > Stopping sjavac server > ################### > > I found that the back-port of JDK-8250521 > ? is causing this failure. > > My ?environment details are as follows. > OS: Windows Server 2016 Standard, Visual Studio professional 2017 > version 15.2(26430.14) > > When I updated my Visual Studio to 15.9.42(which contains Windows 10 > SDK(10.0.17134.0)) the problem went away. > > My question is do we have a minimum supported Visual Studio(15.9.42) to > build jdk11u(11.0.14) ?. If this is not the case then I would like to > fix this build failure. > > Thanks, > Vyom From daniel.fuchs at oracle.com Tue Jan 11 12:22:10 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 11 Jan 2022 12:22:10 +0000 Subject: Result: New Networking Group Member: Aleksei Efimov Message-ID: <5b94074b-0457-19a3-dbd3-5deb164f3ca9@oracle.com> The vote for Aleksei Efimov [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. --daniel [1] https://mail.openjdk.java.net/pipermail/net-dev/2021-November/017048.html From dfuchs at openjdk.java.net Tue Jan 11 12:35:24 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 11 Jan 2022 12:35:24 GMT Subject: RFR: 8262442 (windows) use all proxy configuration sources when java.net.useSystemProxies=true In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 19:25:12 GMT, Daniel Jelinski wrote: > With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available. > If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available) > If both the above options fail, selector uses the configured proxy. > > Verified on Windows 10 that: > - when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used > - when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method > - when `lpszAutoConfigUrl` is set and usable, the proxy returned is used > - when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method > - when `lpszProxy` is configured, that proxy is used > - otherwise selector uses direct connection > > The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate. Hi Daniel - could you update the second copyright year in the file header to 2022? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5995 From duke at openjdk.java.net Tue Jan 11 16:33:57 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Tue, 11 Jan 2022 16:33:57 GMT Subject: RFR: 8262442 (windows) use all proxy configuration sources when java.net.useSystemProxies=true [v2] In-Reply-To: References: Message-ID: <7Vu9jUaLSAIAc3PvO9xHj1v3ppdYY2tZkWeZcJwwkzA=.79439733-ad77-4e3c-9785-758ebed32639@github.com> > With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available. > If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available) > If both the above options fail, selector uses the configured proxy. > > Verified on Windows 10 that: > - when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used > - when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method > - when `lpszAutoConfigUrl` is set and usable, the proxy returned is used > - when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method > - when `lpszProxy` is configured, that proxy is used > - otherwise selector uses direct connection > > The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate. Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5995/files - new: https://git.openjdk.java.net/jdk/pull/5995/files/d8a72e34..f4d3bad1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5995&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5995&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5995/head:pull/5995 PR: https://git.openjdk.java.net/jdk/pull/5995 From dfuchs at openjdk.java.net Tue Jan 11 18:11:37 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 11 Jan 2022 18:11:37 GMT Subject: RFR: 8262442 (windows) use all proxy configuration sources when java.net.useSystemProxies=true [v2] In-Reply-To: <7Vu9jUaLSAIAc3PvO9xHj1v3ppdYY2tZkWeZcJwwkzA=.79439733-ad77-4e3c-9785-758ebed32639@github.com> References: <7Vu9jUaLSAIAc3PvO9xHj1v3ppdYY2tZkWeZcJwwkzA=.79439733-ad77-4e3c-9785-758ebed32639@github.com> Message-ID: On Tue, 11 Jan 2022 16:33:57 GMT, Daniel Jelinski wrote: >> With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available. >> If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available) >> If both the above options fail, selector uses the configured proxy. >> >> Verified on Windows 10 that: >> - when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used >> - when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method >> - when `lpszAutoConfigUrl` is set and usable, the proxy returned is used >> - when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method >> - when `lpszProxy` is configured, that proxy is used >> - otherwise selector uses direct connection >> >> The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate. > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5995 From duke at openjdk.java.net Tue Jan 11 18:39:23 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Tue, 11 Jan 2022 18:39:23 GMT Subject: RFR: 8262442 (windows) use all proxy configuration sources when java.net.useSystemProxies=true [v2] In-Reply-To: <7Vu9jUaLSAIAc3PvO9xHj1v3ppdYY2tZkWeZcJwwkzA=.79439733-ad77-4e3c-9785-758ebed32639@github.com> References: <7Vu9jUaLSAIAc3PvO9xHj1v3ppdYY2tZkWeZcJwwkzA=.79439733-ad77-4e3c-9785-758ebed32639@github.com> Message-ID: On Tue, 11 Jan 2022 16:33:57 GMT, Daniel Jelinski wrote: >> With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available. >> If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available) >> If both the above options fail, selector uses the configured proxy. >> >> Verified on Windows 10 that: >> - when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used >> - when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method >> - when `lpszAutoConfigUrl` is set and usable, the proxy returned is used >> - when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method >> - when `lpszProxy` is configured, that proxy is used >> - otherwise selector uses direct connection >> >> The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate. > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5995 From duke at openjdk.java.net Wed Jan 12 08:09:59 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Wed, 12 Jan 2022 08:09:59 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v4] In-Reply-To: References: Message-ID: > Clean up of various issues related to error handling and memory management Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: Remove unused / incorrect exit code -2 from enumInterfaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6090/files - new: https://git.openjdk.java.net/jdk/pull/6090/files/ab24e7e2..28f5f531 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6090/head:pull/6090 PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Wed Jan 12 08:10:00 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Wed, 12 Jan 2022 08:10:00 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v4] In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 19:58:56 GMT, Mark Sheppard wrote: >> In my experiments the `enumInterfaces` succeeded in IPv6-only environment. The function only fails with -2 when a new interface is added during enumeration. >> I could modify the function to stop returning -2 if you think it makes sense. > > yes, that's what I have observed also It looks like the error handling in enumInterfaces is cut and paste from lookupIPAddrTable, as per the comment > > // this different error code is to handle the case when we call > // GetIpAddrTable in pure IPv6 environment > return -2; > when in fact it is calling GetIfTable > > and if that returns an error, it seems reasonable to terminate processing at that stage by throwing an appropriate exception ... I can't see how it can continue > > So it would seems that enumInterfaces curennt return value -2 is misleading Right. Removed. `enumInterfaces` returns -1 on all failures now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From jpai at openjdk.java.net Wed Jan 12 08:48:12 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 12 Jan 2022 08:48:12 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v6] In-Reply-To: References: Message-ID: > This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137. > > The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections. Jaikiran Pai 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 20 additional commits since the last revision: - Merge latest from master branch - copyright year - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient - Merge latest master branch - Merge latest from master branch - add a security manager test to verify proper permission checks happen when local address is configured on HTTPClient - Merge latest from master branch - add a note to the javadoc of the new API to explain that calling localAddress() is only for advanced usages - move the security checks to the HttpClient itself instead of the builder - first round of security manager checks - ... and 10 more: https://git.openjdk.java.net/jdk/compare/a1bd778f...0217e1c1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/55ff2c13..0217e1c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=04-05 Stats: 9558 lines in 301 files changed: 6609 ins; 2089 del; 860 mod Patch: https://git.openjdk.java.net/jdk/pull/6690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690 PR: https://git.openjdk.java.net/jdk/pull/6690 From jboes at openjdk.java.net Wed Jan 12 09:27:20 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 12 Jan 2022 09:27:20 GMT Subject: RFR: 8276166: Remove dead code from MimeTable and MimeEntry In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 11:20:57 GMT, ?????? ??????? wrote: > There are unused methods/constructors in mentioned classes that can be safely removed. The changes look good to me. I also ran tier 1-3 across platforms - all clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/6169 From msheppar at openjdk.java.net Wed Jan 12 11:06:26 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Wed, 12 Jan 2022 11:06:26 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v4] In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 08:09:59 GMT, Daniel Jelinski wrote: >> Clean up of various issues related to error handling and memory management > > Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused / incorrect exit code -2 from enumInterfaces src/java.base/windows/native/libnet/NetworkInterface.c line 216: > 214: break; > 215: } > 216: return -1; *netifPP = NULL; and a similar NULL out value for all return -1 in this function ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Wed Jan 12 12:35:01 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Wed, 12 Jan 2022 12:35:01 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v5] In-Reply-To: References: Message-ID: > Clean up of various issues related to error handling and memory management Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: Remove redundant initialization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6090/files - new: https://git.openjdk.java.net/jdk/pull/6090/files/28f5f531..0626aca7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6090/head:pull/6090 PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Wed Jan 12 12:37:24 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Wed, 12 Jan 2022 12:37:24 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v4] In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 11:01:03 GMT, Mark Sheppard wrote: >> Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused / incorrect exit code -2 from enumInterfaces > > src/java.base/windows/native/libnet/NetworkInterface.c line 216: > >> 214: break; >> 215: } >> 216: return -1; > > *netifPP = NULL; > > and a similar NULL out value for all return -1 in this function Why? No users of `enumInterfaces` rely on the value returned in the second parameter when `enumInterfaces` returns a negative result. The same is true for `getAllInterfacesAndAddresses`. The second parameter was NULL-initialized in a few places; this initialization was not necessary and I just removed it to avoid confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From jpai at openjdk.java.net Wed Jan 12 13:39:23 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 12 Jan 2022 13:39:23 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java In-Reply-To: <5yZPgrTTEoiJZwgwgOWhONcrtOqKQGe7xbMwDyQ_R0E=.0432a686-2dd4-4966-99a9-a35042be19ed@github.com> References: <8gBBIZyzsxck4JhaIVFz73WtsWfrTnICFyK6LOHSJmY=.8ef2e3d3-632b-444d-ab27-50516dff6d5a@github.com> <5yZPgrTTEoiJZwgwgOWhONcrtOqKQGe7xbMwDyQ_R0E=.0432a686-2dd4-4966-99a9-a35042be19ed@github.com> Message-ID: On Mon, 20 Dec 2021 17:36:50 GMT, Mark Sheppard wrote: >> Right. Looks like `OSsupportsFeature` was used to filter out systems that don't send "port unreachable"; we could probably use it here if the failure turns out to be OS-specific. >> >> Additional logs look fine. > > as I indicated below, we have tracked and investigated this issue and it is not purely a macosx-aarch64 issue. It may also be a test env issue. As such using the OS filtering in the test, which is designed to primarily exclued AIX, wouldn't be the appropraite approach. If we wish to exclude the test on macosx-aarch64, then use of Problemlist is more appropriate. Hello Mark, I just noticed this comment. My understanding of the comment is that you don't expect any other changes to this test other than what has already been done in this PR to enable the debug logs? Is that correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/6883 From dfuchs at openjdk.java.net Wed Jan 12 14:26:27 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 12 Jan 2022 14:26:27 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 14:52:53 GMT, Jaikiran Pai wrote: > Can I please get a review for this test only change which proposes to enable debug logs from the test that failed intermittently? This change addresses https://bugs.openjdk.java.net/browse/JDK-8278961. > > The change passes the (test specific) `-d` option to enable logs from that test by default. While I was at it, I even added a few more debug logs hoping it might provide some hints if/when it fails next. > > For reference, a (successful) run of this test will now print something like: > > > ----------System.out:(18/930)---------- > running on OS that supports ICMP port unreachable > Testing with class java.net.DatagramSocket > tests will be run against destination address localhost/127.0.0.1 port 52682 > Checking send to connected address ... > socket is locally bound to address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > Checking send to non-connected address ... > received data from address /127.0.0.1 port 52681 > Checking send to invalid address ... > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException Hi Jaikiran, What you have seems appropriate to me. Hopefully the added debug information can help us better diagnose the issue (validate/invalidate some hypothesis) next time the test fails. test/jdk/java/net/DatagramSocket/SendDatagramToBadAddress.java line 27: > 25: * @test > 26: * > 27: * @bug 4204320 8278961 Ah - can you remove 8278961 from the bug list before integrating? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6883 From dfuchs at openjdk.java.net Wed Jan 12 14:26:27 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 12 Jan 2022 14:26:27 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 14:21:20 GMT, Daniel Fuchs wrote: >> Can I please get a review for this test only change which proposes to enable debug logs from the test that failed intermittently? This change addresses https://bugs.openjdk.java.net/browse/JDK-8278961. >> >> The change passes the (test specific) `-d` option to enable logs from that test by default. While I was at it, I even added a few more debug logs hoping it might provide some hints if/when it fails next. >> >> For reference, a (successful) run of this test will now print something like: >> >> >> ----------System.out:(18/930)---------- >> running on OS that supports ICMP port unreachable >> Testing with class java.net.DatagramSocket >> tests will be run against destination address localhost/127.0.0.1 port 52682 >> Checking send to connected address ... >> socket is locally bound to address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> Checking send to non-connected address ... >> received data from address /127.0.0.1 port 52681 >> Checking send to invalid address ... >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException > > test/jdk/java/net/DatagramSocket/SendDatagramToBadAddress.java line 27: > >> 25: * @test >> 26: * >> 27: * @bug 4204320 8278961 > > Ah - can you remove 8278961 from the bug list before integrating? `@bug` is supposed to be used to list the bugs that the test is verifying... ------------- PR: https://git.openjdk.java.net/jdk/pull/6883 From jboes at openjdk.java.net Wed Jan 12 17:07:40 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 12 Jan 2022 17:07:40 GMT Subject: RFR: 8278398: jwebserver: Add test to confirm maximum request time Message-ID: This new test confirms that the jwebserver does not wait indefinitely for a request to arrive, but instead closes the connection when the maximum request time is reached. To facilitate this, Exchange::run is amended to process cancelled keys in the case where the current thread is the dispatcher thread (which is the case for the jwebserver). Testing: tier 1-3 all clear. ------------- Commit messages: - Merge branch 'master' into 8278398 - initial commit Changes: https://git.openjdk.java.net/jdk/pull/7052/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7052&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278398 Stats: 219 lines in 2 files changed: 218 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7052.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7052/head:pull/7052 PR: https://git.openjdk.java.net/jdk/pull/7052 From msheppar at openjdk.java.net Wed Jan 12 19:35:29 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Wed, 12 Jan 2022 19:35:29 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 14:52:53 GMT, Jaikiran Pai wrote: > Can I please get a review for this test only change which proposes to enable debug logs from the test that failed intermittently? This change addresses https://bugs.openjdk.java.net/browse/JDK-8278961. > > The change passes the (test specific) `-d` option to enable logs from that test by default. While I was at it, I even added a few more debug logs hoping it might provide some hints if/when it fails next. > > For reference, a (successful) run of this test will now print something like: > > > ----------System.out:(18/930)---------- > running on OS that supports ICMP port unreachable > Testing with class java.net.DatagramSocket > tests will be run against destination address localhost/127.0.0.1 port 52682 > Checking send to connected address ... > socket is locally bound to address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > Checking send to non-connected address ... > received data from address /127.0.0.1 port 52681 > Checking send to invalid address ... > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException Marked as reviewed by msheppar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6883 From msheppar at openjdk.java.net Wed Jan 12 19:35:29 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Wed, 12 Jan 2022 19:35:29 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java In-Reply-To: References: <8gBBIZyzsxck4JhaIVFz73WtsWfrTnICFyK6LOHSJmY=.8ef2e3d3-632b-444d-ab27-50516dff6d5a@github.com> <5yZPgrTTEoiJZwgwgOWhONcrtOqKQGe7xbMwDyQ_R0E=.0432a686-2dd4-4966-99a9-a35042be19ed@github.com> Message-ID: On Wed, 12 Jan 2022 13:36:19 GMT, Jaikiran Pai wrote: >> as I indicated below, we have tracked and investigated this issue and it is not purely a macosx-aarch64 issue. It may also be a test env issue. As such using the OS filtering in the test, which is designed to primarily exclued AIX, wouldn't be the appropraite approach. If we wish to exclude the test on macosx-aarch64, then use of Problemlist is more appropriate. > > Hello Mark, > > I just noticed this comment. My understanding of the comment is that you don't expect any other changes to this test other than what has already been done in this PR to enable the debug logs? Is that correct? yes, the addition of the diagnostics is useful ------------- PR: https://git.openjdk.java.net/jdk/pull/6883 From jpai at openjdk.java.net Thu Jan 13 03:26:58 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 13 Jan 2022 03:26:58 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java [v2] In-Reply-To: References: Message-ID: <5Aiv_euLBCLFKKsTR4nVLjLhxhYdVaHg6I97sBGwHic=.2bcb0a43-533d-483e-9f57-0ba6ef81b123@github.com> > Can I please get a review for this test only change which proposes to enable debug logs from the test that failed intermittently? This change addresses https://bugs.openjdk.java.net/browse/JDK-8278961. > > The change passes the (test specific) `-d` option to enable logs from that test by default. While I was at it, I even added a few more debug logs hoping it might provide some hints if/when it fails next. > > For reference, a (successful) run of this test will now print something like: > > > ----------System.out:(18/930)---------- > running on OS that supports ICMP port unreachable > Testing with class java.net.DatagramSocket > tests will be run against destination address localhost/127.0.0.1 port 52682 > Checking send to connected address ... > socket is locally bound to address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > Checking send to non-connected address ... > received data from address /127.0.0.1 port 52681 > Checking send to invalid address ... > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: fix @bug in test definition and fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6883/files - new: https://git.openjdk.java.net/jdk/pull/6883/files/721cd07d..387dc5d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6883&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6883&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6883.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6883/head:pull/6883 PR: https://git.openjdk.java.net/jdk/pull/6883 From jpai at openjdk.java.net Thu Jan 13 03:27:00 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 13 Jan 2022 03:27:00 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 14:22:14 GMT, Daniel Fuchs wrote: >> test/jdk/java/net/DatagramSocket/SendDatagramToBadAddress.java line 27: >> >>> 25: * @test >>> 26: * >>> 27: * @bug 4204320 8278961 >> >> Ah - can you remove 8278961 from the bug list before integrating? > > `@bug` is supposed to be used to list the bugs that the test is verifying... Hello Daniel, I removed that bug id and also updated the copyright year to the new year and updated the PR. No other changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/6883 From jpai at openjdk.java.net Thu Jan 13 04:58:27 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 13 Jan 2022 04:58:27 GMT Subject: RFR: 8278398: jwebserver: Add test to confirm maximum request time In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 16:59:14 GMT, Julia Boes wrote: > This new test confirms that the jwebserver does not wait indefinitely for a request to arrive, but instead closes the connection when the maximum request time is reached. To facilitate this, Exchange::run is amended to process cancelled keys in the case where the current thread is the dispatcher thread (which is the case for the jwebserver). > > Testing: tier 1-3 all clear. src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 525: > 523: logger.log(Level.TRACE, "exchange started"); > 524: > 525: if (dispatcherThread != null && dispatcherThread == Thread.currentThread()) { Hello Julia, Minor thing - With the `dispatcherThread == Thread.currentThread()` check, the `dispatcherThread != null` would be redundant and perhaps can be removed? test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java line 104: > 102: sendHTTPRequest(); // server expected to respond successfully > 103: > 104: p.destroy(); Since the `sendXXXRequest()` methods above could potentially throw exceptions, do you think it would be better to destroy the process in a finally block? Or maybe manage the process start and destroy as testng before/after lifecycle methods? ------------- PR: https://git.openjdk.java.net/jdk/pull/7052 From dfuchs at openjdk.java.net Thu Jan 13 09:52:38 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 13 Jan 2022 09:52:38 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java [v2] In-Reply-To: <5Aiv_euLBCLFKKsTR4nVLjLhxhYdVaHg6I97sBGwHic=.2bcb0a43-533d-483e-9f57-0ba6ef81b123@github.com> References: <5Aiv_euLBCLFKKsTR4nVLjLhxhYdVaHg6I97sBGwHic=.2bcb0a43-533d-483e-9f57-0ba6ef81b123@github.com> Message-ID: <58rs_LAPVXOd_rvbqvL5tY6f_U6j0Li840vYT0dUV0A=.ea9fbd3e-1f2e-48ba-a840-5de374ef4b12@github.com> On Thu, 13 Jan 2022 03:26:58 GMT, Jaikiran Pai wrote: >> Can I please get a review for this test only change which proposes to enable debug logs from the test that failed intermittently? This change addresses https://bugs.openjdk.java.net/browse/JDK-8278961. >> >> The change passes the (test specific) `-d` option to enable logs from that test by default. While I was at it, I even added a few more debug logs hoping it might provide some hints if/when it fails next. >> >> For reference, a (successful) run of this test will now print something like: >> >> >> ----------System.out:(18/930)---------- >> running on OS that supports ICMP port unreachable >> Testing with class java.net.DatagramSocket >> tests will be run against destination address localhost/127.0.0.1 port 52682 >> Checking send to connected address ... >> socket is locally bound to address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> Checking send to non-connected address ... >> received data from address /127.0.0.1 port 52681 >> Checking send to invalid address ... >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fix @bug in test definition and fix copyright year LGTM. Please integrate :-) ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6883 From jpai at openjdk.java.net Thu Jan 13 13:27:32 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 13 Jan 2022 13:27:32 GMT Subject: RFR: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 16:35:18 GMT, Daniel Jelinski wrote: >> Can I please get a review for this test only change which proposes to enable debug logs from the test that failed intermittently? This change addresses https://bugs.openjdk.java.net/browse/JDK-8278961. >> >> The change passes the (test specific) `-d` option to enable logs from that test by default. While I was at it, I even added a few more debug logs hoping it might provide some hints if/when it fails next. >> >> For reference, a (successful) run of this test will now print something like: >> >> >> ----------System.out:(18/930)---------- >> running on OS that supports ICMP port unreachable >> Testing with class java.net.DatagramSocket >> tests will be run against destination address localhost/127.0.0.1 port 52682 >> Checking send to connected address ... >> socket is locally bound to address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> received data from address /127.0.0.1 port 52681 >> Checking send to non-connected address ... >> received data from address /127.0.0.1 port 52681 >> Checking send to invalid address ... >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException >> Got expected exception: java.net.PortUnreachableException > > Does the `OSsupportsFeature` method still make sense? It mentions Windows 2000; I'm pretty sure every Windows version supports this today. > > Also, I took a peek at JDK-8278858. The logs mention >> elapsed time (seconds): 20.069 > > which is consistent with 5 (tries) *4seconds (timeout), which suggests that either the host firewalls ICMP "destination unreachable" packets, or our `serversock.close ();` call is somehow broken on that machine. Thank you Daniel, Mark and @djelinski for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/6883 From jpai at openjdk.java.net Thu Jan 13 13:27:33 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 13 Jan 2022 13:27:33 GMT Subject: Integrated: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 14:52:53 GMT, Jaikiran Pai wrote: > Can I please get a review for this test only change which proposes to enable debug logs from the test that failed intermittently? This change addresses https://bugs.openjdk.java.net/browse/JDK-8278961. > > The change passes the (test specific) `-d` option to enable logs from that test by default. While I was at it, I even added a few more debug logs hoping it might provide some hints if/when it fails next. > > For reference, a (successful) run of this test will now print something like: > > > ----------System.out:(18/930)---------- > running on OS that supports ICMP port unreachable > Testing with class java.net.DatagramSocket > tests will be run against destination address localhost/127.0.0.1 port 52682 > Checking send to connected address ... > socket is locally bound to address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > received data from address /127.0.0.1 port 52681 > Checking send to non-connected address ... > received data from address /127.0.0.1 port 52681 > Checking send to invalid address ... > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException > Got expected exception: java.net.PortUnreachableException This pull request has now been integrated. Changeset: c17a0122 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/c17a0122c4b5f17b85dc0bee0777b2a831debf6d Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java Reviewed-by: dfuchs, msheppar ------------- PR: https://git.openjdk.java.net/jdk/pull/6883 From jpai at openjdk.java.net Thu Jan 13 13:41:39 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 13 Jan 2022 13:41:39 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v6] In-Reply-To: References: Message-ID: <22LkwjSU7Vz910pg4n7sxzFP9kn-YHEu358FzPhSW0I=.0cff9919-5ab0-4705-96da-debbca91174e@github.com> On Wed, 12 Jan 2022 08:48:12 GMT, Jaikiran Pai wrote: >> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137. >> >> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections. > > Jaikiran Pai 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 20 additional commits since the last revision: > > - Merge latest from master branch > - copyright year > - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient > - Merge latest master branch > - Merge latest from master branch > - add a security manager test to verify proper permission checks happen when local address is configured on HTTPClient > - Merge latest from master branch > - add a note to the javadoc of the new API to explain that calling localAddress() is only for advanced usages > - move the security checks to the HttpClient itself instead of the builder > - first round of security manager checks > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/57f286de...0217e1c1 Any further reviews on this PR, please? ------------- PR: https://git.openjdk.java.net/jdk/pull/6690 From duke at openjdk.java.net Thu Jan 13 14:44:45 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Thu, 13 Jan 2022 14:44:45 GMT Subject: Integrated: 8262442: (windows) Use all proxy configuration sources when java.net.useSystemProxies=true In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 19:25:12 GMT, Daniel Jelinski wrote: > With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available. > If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available) > If both the above options fail, selector uses the configured proxy. > > Verified on Windows 10 that: > - when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used > - when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method > - when `lpszAutoConfigUrl` is set and usable, the proxy returned is used > - when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method > - when `lpszProxy` is configured, that proxy is used > - otherwise selector uses direct connection > > The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate. This pull request has now been integrated. Changeset: 6fcaa322 Author: Daniel Jelinski Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/6fcaa322d90f06ba79a8fc30ebe314aa9ea8e959 Stats: 15 lines in 1 file changed: 7 ins; 5 del; 3 mod 8262442: (windows) Use all proxy configuration sources when java.net.useSystemProxies=true Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5995 From jboes at openjdk.java.net Thu Jan 13 15:39:28 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 13 Jan 2022 15:39:28 GMT Subject: RFR: 8278398: jwebserver: Add test to confirm maximum request time [v2] In-Reply-To: References: Message-ID: <3cSuclZFXolVEV7XyxI-SFOOnq5U7wivjibHWcMtJjo=.47f905ab-375c-49f1-92aa-3d7a264d8687@github.com> > This new test confirms that the jwebserver does not wait indefinitely for a request to arrive, but instead closes the connection when the maximum request time is reached. To facilitate this, Exchange::run is amended to process cancelled keys in the case where the current thread is the dispatcher thread (which is the case for the jwebserver). > > Testing: tier 1-3 all clear. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: address PR comments: * remove redundant null check * use try-finally to stop process in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7052/files - new: https://git.openjdk.java.net/jdk/pull/7052/files/3eff7258..2b3eadd8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7052&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7052&range=00-01 Stats: 11 lines in 2 files changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7052.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7052/head:pull/7052 PR: https://git.openjdk.java.net/jdk/pull/7052 From jboes at openjdk.java.net Thu Jan 13 15:39:29 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 13 Jan 2022 15:39:29 GMT Subject: RFR: 8278398: jwebserver: Add test to confirm maximum request time [v2] In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 04:52:25 GMT, Jaikiran Pai wrote: >> Julia Boes has updated the pull request incrementally with one additional commit since the last revision: >> >> address PR comments: >> * remove redundant null check >> * use try-finally to stop process in test > > src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 525: > >> 523: logger.log(Level.TRACE, "exchange started"); >> 524: >> 525: if (dispatcherThread != null && dispatcherThread == Thread.currentThread()) { > > Hello Julia, > Minor thing - With the `dispatcherThread == Thread.currentThread()` check, the `dispatcherThread != null` would be redundant and perhaps can be removed? You're right, removed. > test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java line 104: > >> 102: sendHTTPRequest(); // server expected to respond successfully >> 103: >> 104: p.destroy(); > > Since the `sendXXXRequest()` methods above could potentially throw exceptions, do you think it would be better to destroy the process in a finally block? Or maybe manage the process start and destroy as testng before/after lifecycle methods? Good point, I'll update that. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7052 From jai.forums2013 at gmail.com Fri Jan 14 01:33:25 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 14 Jan 2022 07:03:25 +0530 Subject: RFR: 8278398: jwebserver: Add test to confirm maximum request time [v2] In-Reply-To: References: Message-ID: <94366fa3-5aac-188d-6c68-b32cef15af61@gmail.com> Thank you Julia, these new changes look fine to me. -Jaikiran On 13/01/22 9:09 pm, Julia Boes wrote: > On Thu, 13 Jan 2022 04:52:25 GMT, Jaikiran Pai wrote: > >>> Julia Boes has updated the pull request incrementally with one additional commit since the last revision: >>> >>> address PR comments: >>> * remove redundant null check >>> * use try-finally to stop process in test >> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 525: >> >>> 523: logger.log(Level.TRACE, "exchange started"); >>> 524: >>> 525: if (dispatcherThread != null && dispatcherThread == Thread.currentThread()) { >> Hello Julia, >> Minor thing - With the `dispatcherThread == Thread.currentThread()` check, the `dispatcherThread != null` would be redundant and perhaps can be removed? > You're right, removed. > >> test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java line 104: >> >>> 102: sendHTTPRequest(); // server expected to respond successfully >>> 103: >>> 104: p.destroy(); >> Since the `sendXXXRequest()` methods above could potentially throw exceptions, do you think it would be better to destroy the process in a finally block? Or maybe manage the process start and destroy as testng before/after lifecycle methods? > Good point, I'll update that. Thanks! > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7052 From dfuchs at openjdk.java.net Fri Jan 14 10:29:27 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 10:29:27 GMT Subject: RFR: 8278398: jwebserver: Add test to confirm maximum request time [v2] In-Reply-To: <3cSuclZFXolVEV7XyxI-SFOOnq5U7wivjibHWcMtJjo=.47f905ab-375c-49f1-92aa-3d7a264d8687@github.com> References: <3cSuclZFXolVEV7XyxI-SFOOnq5U7wivjibHWcMtJjo=.47f905ab-375c-49f1-92aa-3d7a264d8687@github.com> Message-ID: On Thu, 13 Jan 2022 15:39:28 GMT, Julia Boes wrote: >> This new test confirms that the jwebserver does not wait indefinitely for a request to arrive, but instead closes the connection when the maximum request time is reached. To facilitate this, Exchange::run is amended to process cancelled keys in the case where the current thread is the dispatcher thread (which is the case for the jwebserver). >> >> Testing: tier 1-3 all clear. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comments: > * remove redundant null check > * use try-finally to stop process in test LGTM. @Michael-Mc-Mahon is that the fix you had in mind? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7052 From michaelm at openjdk.java.net Fri Jan 14 11:09:46 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 14 Jan 2022 11:09:46 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Message-ID: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Hi, This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. A test will be added separately to the implementation. Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 Thanks, Michael ------------- Commit messages: - cleanup but still no test. Will be added in closed repo - First version of fix. No test and feature enabled always. Changes: https://git.openjdk.java.net/jdk/pull/7065/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279842 Stats: 149 lines in 7 files changed: 143 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 14 11:09:46 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 14 Jan 2022 11:09:46 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 18:18:24 GMT, Daniel Fuchs wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180: > >> 178: static String normalizeCBT(String s) { >> 179: if (s == null || ! (s.equals("always") || >> 180: s.equals("never") || s.startsWith("domain:"))) { > > I guess there's a `!` missing in front of `s.startsWith("domain:")` here? This is what was intended (equivalent) `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 14 11:09:46 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 11:09:46 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180: > 178: static String normalizeCBT(String s) { > 179: if (s == null || ! (s.equals("always") || > 180: s.equals("never") || s.startsWith("domain:"))) { I guess there's a `!` missing in front of `s.startsWith("domain:")` here? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 14 11:09:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 11:09:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> On Fri, 14 Jan 2022 10:03:37 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180: >> >>> 178: static String normalizeCBT(String s) { >>> 179: if (s == null || ! (s.equals("always") || >>> 180: s.equals("never") || s.startsWith("domain:"))) { >> >> I guess there's a `!` missing in front of `s.startsWith("domain:")` here? > > This is what was intended (equivalent) > > `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as ! (s.equals("always")) || ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From serb at openjdk.java.net Fri Jan 14 12:21:55 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 14 Jan 2022 12:21:55 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. The code change looks fine, but can you please check the actual performance impact, will the perf be the same after the change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From duke at openjdk.java.net Fri Jan 14 12:21:54 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 14 Jan 2022 12:21:54 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load Message-ID: `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. ------------- Commit messages: - [PATCH] Remove double buffering of InputStream for Properties.load - [PATCH] Remove double buffering of InputStream for Properties.load Changes: https://git.openjdk.java.net/jdk/pull/7021/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7021&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280010 Stats: 30 lines in 8 files changed: 0 ins; 11 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7021.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7021/head:pull/7021 PR: https://git.openjdk.java.net/jdk/pull/7021 From duke at openjdk.java.net Fri Jan 14 12:21:56 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 14 Jan 2022 12:21:56 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Checked. `BufferedInputStream` add a bit of overhead. Benchmark @BenchmarkMode(value = Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(iterations = 6, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Fork(1) @State(Scope.Benchmark) public class PropertiesLoad { Properties properties; private InputStream arrayInputStream; private InputStream fileInputStream; private Path filePath; @Setup public void setupStrings() throws IOException { properties = new Properties(); String content = """ currentVersion=IdealGraphVisualizer {0} LBL_splash_window_title=Starting IdealGraphVisualizer SPLASH_WIDTH=475 SplashProgressBarBounds=0,273,475,6 SplashProgressBarColor=0xFFFFFF SplashRunningTextBounds=10,283,460,12 SplashRunningTextColor=0xFFFFFF """; filePath = Files.createTempFile("benchmark", ".properties"); Files.writeString(filePath, content); arrayInputStream = new ByteArrayInputStream(content.getBytes(StandardCharsets.UTF_8)); fileInputStream = Files.newInputStream(filePath); } @TearDown public void tearDown() throws IOException { fileInputStream.close(); Files.delete(filePath); } @Benchmark public Properties plain_ByteStream() throws IOException { properties.load(arrayInputStream); return properties; } @Benchmark public Properties plain_fileStream() throws IOException { properties.load(fileInputStream); return properties; } @Benchmark public Properties buffered_ByteStream() throws IOException { properties.load(new BufferedInputStream(arrayInputStream)); return properties; } @Benchmark public Properties buffered_fileStream() throws IOException { properties.load(new BufferedInputStream(fileInputStream)); return properties; } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(PropertiesLoad.class.getSimpleName()) .build(); new Runner(opt).run(); } } Results: Benchmark Mode Cnt Score Error Units PropertiesLoad.buffered_ByteStream avgt 5 2416,364 ? 46,209 ns/op PropertiesLoad.buffered_fileStream avgt 5 4276,015 ? 139,094 ns/op PropertiesLoad.plain_ByteStream avgt 5 1445,864 ? 649,779 ns/op PropertiesLoad.plain_fileStream avgt 5 3183,012 ? 198,974 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From michaelm at openjdk.java.net Fri Jan 14 12:41:26 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 14 Jan 2022 12:41:26 GMT Subject: RFR: 8278398: jwebserver: Add test to confirm maximum request time [v2] In-Reply-To: <3cSuclZFXolVEV7XyxI-SFOOnq5U7wivjibHWcMtJjo=.47f905ab-375c-49f1-92aa-3d7a264d8687@github.com> References: <3cSuclZFXolVEV7XyxI-SFOOnq5U7wivjibHWcMtJjo=.47f905ab-375c-49f1-92aa-3d7a264d8687@github.com> Message-ID: <5M-VlKZ5Otlo9e0RxfZd2MJHjtODU0_r_J0HbchCQxc=.4efbb099-b208-4423-9f28-9dcebaedd03b@github.com> On Thu, 13 Jan 2022 15:39:28 GMT, Julia Boes wrote: >> This new test confirms that the jwebserver does not wait indefinitely for a request to arrive, but instead closes the connection when the maximum request time is reached. To facilitate this, Exchange::run is amended to process cancelled keys in the case where the current thread is the dispatcher thread (which is the case for the jwebserver). >> >> Testing: tier 1-3 all clear. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comments: > * remove redundant null check > * use try-finally to stop process in test LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7052 From jboes at openjdk.java.net Fri Jan 14 12:51:28 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 14 Jan 2022 12:51:28 GMT Subject: Integrated: 8278398: jwebserver: Add test to confirm maximum request time In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 16:59:14 GMT, Julia Boes wrote: > This new test confirms that the jwebserver does not wait indefinitely for a request to arrive, but instead closes the connection when the maximum request time is reached. To facilitate this, Exchange::run is amended to process cancelled keys in the case where the current thread is the dispatcher thread (which is the case for the jwebserver). > > Testing: tier 1-3 all clear. This pull request has now been integrated. Changeset: 9f30ec17 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/9f30ec174faae10484766308996cab136a779658 Stats: 220 lines in 2 files changed: 219 ins; 0 del; 1 mod 8278398: jwebserver: Add test to confirm maximum request time Reviewed-by: dfuchs, michaelm ------------- PR: https://git.openjdk.java.net/jdk/pull/7052 From amenkov at openjdk.java.net Fri Jan 14 13:15:22 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 14 Jan 2022 13:15:22 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From dfuchs at openjdk.java.net Fri Jan 14 14:51:23 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 14:51:23 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Changes to `java.util.logging` look fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From dfuchs at openjdk.java.net Fri Jan 14 15:09:25 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 15:09:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Have you been able to test this on a specific setup? Would be good to hear from @msheppar too. src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: > 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include > 151: * a channel binding token for the destination server. The default behavior and setting for the > 152: * property is "never" Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too? src/java.security.jgss/share/classes/module-info.java line 36: > 34: module java.security.jgss { > 35: requires java.naming; > 36: requires java.security.sasl; Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From sspitsyn at openjdk.java.net Fri Jan 14 17:59:29 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 14 Jan 2022 17:59:29 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From michaelm at openjdk.java.net Fri Jan 14 18:45:27 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 14 Jan 2022 18:45:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 14 Jan 2022 14:52:13 GMT, Daniel Fuchs wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: > >> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include >> 151: * a channel binding token for the destination server. The default behavior and setting for the >> 152: * property is "never" > > Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too? It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > src/java.security.jgss/share/classes/module-info.java line 36: > >> 34: module java.security.jgss { >> 35: requires java.naming; >> 36: requires java.security.sasl; > > Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK. Yes. I would like the security team to validate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Sat Jan 15 00:30:28 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 15 Jan 2022 00:30:28 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 14 Jan 2022 18:42:08 GMT, Michael McMahon wrote: >> src/java.security.jgss/share/classes/module-info.java line 36: >> >>> 34: module java.security.jgss { >>> 35: requires java.naming; >>> 36: requires java.security.sasl; >> >> Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK. > > Yes. I would like the security team to validate this. I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. You might need to modify the types of exceptions thrown in the class and move the 2 final strings to some other class inside `java.security.sasl`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Sat Jan 15 00:47:27 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 15 Jan 2022 00:47:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> On Fri, 14 Jan 2022 18:40:41 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: >> >>> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include >>> 151: * a channel binding token for the destination server. The default behavior and setting for the >>> 152: * property is "never" >> >> Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too? > > It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". BTW, will you reuse this system property if we decide to support CBT in NTLM as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Sat Jan 15 00:52:27 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 15 Jan 2022 00:52:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> Message-ID: On Fri, 14 Jan 2022 10:18:50 GMT, Daniel Fuchs wrote: >> This is what was intended (equivalent) >> >> `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` > > Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as > > ! (s.equals("always")) || ... Shall we log a message if the value is not one of the 3 forms? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From serb at openjdk.java.net Sat Jan 15 02:32:32 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 15 Jan 2022 02:32:32 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From duke at openjdk.java.net Sat Jan 15 14:05:21 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Sat, 15 Jan 2022 14:05:21 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Sat, 15 Jan 2022 00:23:31 GMT, Weijun Wang wrote: >> Yes. I would like the security team to validate this. > > I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. It's even not restricted to GSS-API. According to https://www.rfc-editor.org/rfc/rfc5056, "Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS-API applications". > > If so, you might need to modify the types of exceptions thrown in the class, and move the 2 final strings to some other class inside `java.security.sasl`. Seems like `com.sun.jndi.ldap.sasl.TlsChannelBinding` is not misplaced.... ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Mon Jan 17 05:29:32 2022 From: duke at openjdk.java.net (prasad-bit) Date: Mon, 17 Jan 2022 05:29:32 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang wrote: >> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > > This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". > > BTW, will you reuse this system property if we decide to support CBT in NTLM as well? I vote for "jdk.https.tls.cbt" ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From pkoppula at openjdk.java.net Mon Jan 17 06:35:30 2022 From: pkoppula at openjdk.java.net (Prasadrao Koppula) Date: Mon, 17 Jan 2022 06:35:30 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang wrote: >> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > > This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". > > BTW, will you reuse this system property if we decide to support CBT in NTLM as well? I vote for "jdk.https.tls.cbt" ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From pkoppula at openjdk.java.net Mon Jan 17 11:48:25 2022 From: pkoppula at openjdk.java.net (Prasadrao Koppula) Date: Mon, 17 Jan 2022 11:48:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Add Release note and Doc subtasks to the JBS ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Mon Jan 17 13:47:26 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 17 Jan 2022 13:47:26 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> Message-ID: On Sat, 15 Jan 2022 00:49:05 GMT, Weijun Wang wrote: >> Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as >> >> ! (s.equals("always")) || ... > > Shall we log a message if the value is not one of the 3 forms? Usually malformed values are just ignored - and the property takes its default value. But yes - s.n.w.h.HttpClient has a logger so it wouldn't be much effort to log it as a DEBUG trace for better diagnostic. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Mon Jan 17 13:52:26 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 17 Jan 2022 13:52:26 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Mon, 17 Jan 2022 06:32:13 GMT, Prasadrao Koppula wrote: >> This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". >> >> BTW, will you reuse this system property if we decide to support CBT in NTLM as well? > > I vote for "jdk.https.tls.cbt" > It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? AFAICS this file documents properties used by the networking task - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property) ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From aturbanov at openjdk.java.net Tue Jan 18 15:52:31 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 18 Jan 2022 15:52:31 GMT Subject: Integrated: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. This pull request has now been integrated. Changeset: 9eb50a5e Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/9eb50a5ee4a069fbb248748ebee09132e2450420 Stats: 30 lines in 8 files changed: 0 ins; 11 del; 19 mod 8280010: Remove double buffering of InputStream for Properties.load Reviewed-by: amenkov, sspitsyn, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From duke at openjdk.java.net Wed Jan 19 08:15:24 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Wed, 19 Jan 2022 08:15:24 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v6] In-Reply-To: References: Message-ID: > Clean up of various issues related to error handling and memory management Daniel Jelinski 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 12 additional commits since the last revision: - Fix invalid free - Merge remote-tracking branch 'origin' into interface-cleanup - Remove redundant initialization - Remove unused / incorrect exit code -2 from enumInterfaces - Address problems reported by clang-tidy - Restore support for IPv6-only operation - Fix memory leak - Fixup getAllInterfacesAndAddresses - Fixup getAddrsFromAdapter - Fixup enumAddresses_win - ... and 2 more: https://git.openjdk.java.net/jdk/compare/bccc9a2c...98b40812 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6090/files - new: https://git.openjdk.java.net/jdk/pull/6090/files/0626aca7..98b40812 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=04-05 Stats: 984368 lines in 3461 files changed: 521300 ins; 441453 del; 21615 mod Patch: https://git.openjdk.java.net/jdk/pull/6090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6090/head:pull/6090 PR: https://git.openjdk.java.net/jdk/pull/6090 From duke at openjdk.java.net Wed Jan 19 08:18:40 2022 From: duke at openjdk.java.net (Daniel Jelinski) Date: Wed, 19 Jan 2022 08:18:40 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v4] In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 12:34:35 GMT, Daniel Jelinski wrote: >> src/java.base/windows/native/libnet/NetworkInterface.c line 216: >> >>> 214: break; >>> 215: } >>> 216: return -1; >> >> *netifPP = NULL; >> >> and a similar NULL out value for all return -1 in this function > > Why? > No users of `enumInterfaces` rely on the value returned in the second parameter when `enumInterfaces` returns a negative result. The same is true for `getAllInterfacesAndAddresses`. > The second parameter was NULL-initialized in a few places; this initialization was not necessary and I just removed it to avoid confusion. ahh... I see your point now. I missed a few cases where the returned value was referenced (free'd) even though the function failed. These should be fixed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From michaelm at openjdk.java.net Wed Jan 19 15:40:35 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 15:40:35 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Mon, 17 Jan 2022 13:49:35 GMT, Daniel Fuchs wrote: >> I vote for "jdk.https.tls.cbt" > >> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > > AFAICS this file documents properties used by the networking task - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property) Okay, good idea to document it in the properties file. Also, I think "jdk.https.tls.cbt" is a reasonable name for the property. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Wed Jan 19 15:40:36 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 15:40:36 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> Message-ID: <0_k-W6vPKT_r3U_Tgj9-S8Dn2RxBIiMFsZ8vZI4p23E=.15d85a8b-5ca5-4cc4-a413-9c8a87c138f4@github.com> On Mon, 17 Jan 2022 13:44:06 GMT, Daniel Fuchs wrote: >> Shall we log a message if the value is not one of the 3 forms? > > Usually malformed values are just ignored - and the property takes its default value. But yes - s.n.w.h.HttpClient has a logger so it wouldn't be much effort to log it as a DEBUG trace for better diagnostic. Yes, I will log it using the same debug/logging mechanism already in the same source file.. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Wed Jan 19 15:40:36 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 15:40:36 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <5zco_5V9sMUkWNWNVmjFyvHNVkR5iZicq_0DBQWtRp4=.55489b7e-8f53-4c83-acd8-66141b5021af@github.com> On Sat, 15 Jan 2022 14:02:15 GMT, Michael Osipov wrote: >> I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. It's even not restricted to GSS-API. According to https://www.rfc-editor.org/rfc/rfc5056, "Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS-API applications". >> >> If so, you might need to modify the types of exceptions thrown in the class, and move the 2 final strings to some other class inside `java.security.sasl`. > > Seems like `com.sun.jndi.ldap.sasl.TlsChannelBinding` is not misplaced.... Okay, I'll look at doing this refactoring. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Wed Jan 19 16:00:40 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 19 Jan 2022 16:00:40 GMT Subject: RFR: 8276166: Remove dead code from MimeTable and MimeEntry In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 11:20:57 GMT, ?????? ??????? wrote: > There are unused methods/constructors in mentioned classes that can be safely removed. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6169 From michaelm at openjdk.java.net Wed Jan 19 16:12:34 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 16:12:34 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: <0ebQZroTY3tTQW9cy5g6Y9yTK_nv6CBRtr-ne3tEF6k=.c4f10a2c-2ff8-452a-8cfb-cffedc5f0249@github.com> On Wed, 19 Jan 2022 15:36:16 GMT, Michael McMahon wrote: >>> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? >> >> AFAICS this file documents properties used by the networking stack - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property) > > Okay, good idea to document it in the properties file. Also, I think "jdk.https.tls.cbt" is a reasonable name for the property. Sorry, on reflection, something like "jdk.https.negotiate.cbt" might be better. There's no need for tls and https in the name and "negotiate" or "spnego" should be in it, but "negotiate" is probably better ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From jboes at openjdk.java.net Wed Jan 19 16:58:41 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 19 Jan 2022 16:58:41 GMT Subject: RFR: 8276166: Remove dead code from MimeTable and MimeEntry In-Reply-To: References: Message-ID: On Fri, 24 Dec 2021 20:12:39 GMT, ?????? ??????? wrote: >> There are unused methods/constructors in mentioned classes that can be safely removed. > > Not now Happy to /sponsor once you /integrate, @stsypanov. ------------- PR: https://git.openjdk.java.net/jdk/pull/6169 From jboes at openjdk.java.net Wed Jan 19 17:07:43 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 19 Jan 2022 17:07:43 GMT Subject: RFR: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException Message-ID: Small test-only fix that generalizes the expected exception type from SSLHandshakeException to SSLException (a super class of the former). Testing: tier 1-3 and repeated runs of test in question all clear ------------- Commit messages: - initial commit Changes: https://git.openjdk.java.net/jdk/pull/7144/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7144&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280161 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7144.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7144/head:pull/7144 PR: https://git.openjdk.java.net/jdk/pull/7144 From michaelm at openjdk.java.net Wed Jan 19 17:12:31 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 17:12:31 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <4Tld3QrBk91X9ZBtF4Ad7DCiIfGD203YePBmy7FIAHs=.9964426c-6244-4818-8479-18044a833db1@github.com> On Fri, 14 Jan 2022 15:06:12 GMT, Daniel Fuchs wrote: > Have you been able to test this on a specific setup? Would be good to hear from @msheppar too. I have tested it with the server setup by Prajwal. Security SQE are looking into configuring a server with a similar setup which can be tested with an infra test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Wed Jan 19 17:20:22 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 19 Jan 2022 17:20:22 GMT Subject: RFR: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:01:22 GMT, Julia Boes wrote: > Small test-only fix that generalizes the expected exception type from SSLHandshakeException to SSLException (a super class of the former). > > Testing: tier 1-3 and repeated runs of test in question all clear LGTM - just remove 8280161 from the @bug tag list. test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8278398 8280161 No need to add 8280161 since 8280161 is marked as noreg-self. In principle we only list bugs whose fix contain code changes that can be verified by the test. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7144 From michaelm at openjdk.java.net Wed Jan 19 22:20:47 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 22:20:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: changes after first review round ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/853ed4db..f2ee58ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=00-01 Stats: 111 lines in 7 files changed: 88 ins; 5 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Wed Jan 19 22:29:53 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 Jan 2022 22:29:53 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> Message-ID: <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com> On Wed, 19 Jan 2022 22:20:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > changes after first review round src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); > 132: } catch (ChannelBindingException e) { > 133: throw new SaslException(e.getMessage()); How about setting `e` as cause of new exception? In `TlsChannelBinding.java` the when the original exception was thrown (the 2nd throws) there was a cause. src/java.security.jgss/share/classes/module-info.java line 36: > 34: module java.security.jgss { > 35: requires java.naming; > 36: requires java.security.sasl; Can this be removed now? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From jwilhelm at openjdk.java.net Thu Jan 20 00:40:42 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 00:40:42 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling - 8272058: 25 Null pointer dereference defect groups in 4 files - 8280234: AArch64 "core" variant does not build after JDK-8270947 - 8280155: [PPC64, s390] frame size checks are not yet correct - 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS - 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE - 8278417: Closed test fails after JDK-8276108 on aarch64 - 8274096: Improve decoding of image files - ... and 30 more: https://git.openjdk.java.net/jdk/compare/98d96a77...e0d83a07 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7151/files Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/7151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7151/head:pull/7151 PR: https://git.openjdk.java.net/jdk/pull/7151 From jwilhelm at openjdk.java.net Thu Jan 20 01:21:56 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 01:21:56 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 4616c13c Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5 Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7151 From xuelei at openjdk.java.net Thu Jan 20 07:18:04 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 20 Jan 2022 07:18:04 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters Message-ID: In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method. The update is a minor correction so that the specification is not rely on the "protocols" variable. ------------- Commit messages: - 8280363: Minor correction of ALPN specification in SSLParameters Changes: https://git.openjdk.java.net/jdk/pull/7152/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7152&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280363 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7152.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7152/head:pull/7152 PR: https://git.openjdk.java.net/jdk/pull/7152 From duke at openjdk.java.net Thu Jan 20 08:42:50 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 20 Jan 2022 08:42:50 GMT Subject: RFR: 8276166: Remove dead code from MimeTable and MimeEntry In-Reply-To: References: Message-ID: <4SM3jAGGb_TBmY2OUuj3RPhoy4PKDRVEq5AbXU_iQJ8=.9a18623f-032a-4936-9aa6-9402163c3b4e@github.com> On Wed, 19 Jan 2022 16:55:44 GMT, Julia Boes wrote: >> Not now > > Happy to /sponsor once you /integrate, @stsypanov. @FrauBoes thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/6169 From duke at openjdk.java.net Thu Jan 20 09:18:53 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 20 Jan 2022 09:18:53 GMT Subject: Integrated: 8276166: Remove dead code from MimeTable and MimeEntry In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 11:20:57 GMT, ?????? ??????? wrote: > There are unused methods/constructors in mentioned classes that can be safely removed. This pull request has now been integrated. Changeset: cf977e88 Author: Sergey Tsypanov Committer: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/cf977e88ecc64b549f332efe01578fca9f435060 Stats: 44 lines in 2 files changed: 0 ins; 41 del; 3 mod 8276166: Remove dead code from MimeTable and MimeEntry Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/6169 From jboes at openjdk.java.net Thu Jan 20 09:20:25 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 20 Jan 2022 09:20:25 GMT Subject: RFR: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException [v2] In-Reply-To: References: Message-ID: > Small test-only fix that generalizes the expected exception type from SSLHandshakeException to SSLException (a super class of the former). > > Testing: tier 1-3 and repeated runs of test in question all clear Julia Boes has updated the pull request incrementally with one additional commit since the last revision: address PR comment: remove bug id in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7144/files - new: https://git.openjdk.java.net/jdk/pull/7144/files/4fd75abe..6565fcef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7144&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7144&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7144.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7144/head:pull/7144 PR: https://git.openjdk.java.net/jdk/pull/7144 From jboes at openjdk.java.net Thu Jan 20 09:20:28 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 20 Jan 2022 09:20:28 GMT Subject: RFR: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:16:30 GMT, Daniel Fuchs wrote: >> Julia Boes has updated the pull request incrementally with one additional commit since the last revision: >> >> address PR comment: remove bug id in test > > test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 8278398 8280161 > > No need to add 8280161 since 8280161 is marked as noreg-self. In principle we only list bugs whose fix contain code changes that can be verified by the test. Makes sense, thanks for picking up on that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7144 From michaelm at openjdk.java.net Thu Jan 20 10:58:27 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 20 Jan 2022 10:58:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: removed sasl module dependency and added SaslException cause ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/f2ee58ec..fd56b5e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Thu Jan 20 10:58:32 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 20 Jan 2022 10:58:32 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com> Message-ID: On Wed, 19 Jan 2022 22:25:43 GMT, Weijun Wang wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> changes after first review round > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > >> 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); >> 132: } catch (ChannelBindingException e) { >> 133: throw new SaslException(e.getMessage()); > > How about setting `e` as cause of new exception? In `TlsChannelBinding.java` the when the original exception was thrown (the 2nd throws) there was a cause. Agreed. > src/java.security.jgss/share/classes/module-info.java line 36: > >> 34: module java.security.jgss { >> 35: requires java.naming; >> 36: requires java.security.sasl; > > Can this be removed now? Yes, well spotted! ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Thu Jan 20 11:17:49 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Thu, 20 Jan 2022 11:17:49 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> On Thu, 20 Jan 2022 10:58:27 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > removed sasl module dependency and added SaslException cause src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); > 132: } catch (ChannelBindingException e) { > 133: throw new SaslException(e.getMessage(), e); Why not ust pass the exception if the API allows? This looks like message duplication. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Thu Jan 20 11:21:52 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 20 Jan 2022 11:21:52 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 20 Jan 2022 10:58:27 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > removed sasl module dependency and added SaslException cause src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos > 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with > 220: {@code HttpURLConnection}. There are three possible settings:

Should it be `{@code HttpsURLConnection}`? (BTW - can we use {@code } here ? Would be worth checking the generated doc) src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189: > 187: } else { > 188: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); > 189: return s; Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here. src/java.base/share/classes/sun/security/util/ChannelBindingException.java line 31: > 29: * Thrown by TlsChannelBinding if an error occurs > 30: */ > 31: public class ChannelBindingException extends Exception { Should this extend `GeneralSecurityException` instead? Or should we just remove this class and throw plain `GeneralSecurityException` in `TlsChannelBinding` ? src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 143: > 141: tlsCB = TlsChannelBinding.create(cert); > 142: } catch (ChannelBindingException e) { > 143: throw new SaslException(e.getMessage()); Why is there a difference compared to line 133? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Thu Jan 20 11:33:50 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 20 Jan 2022 11:33:50 GMT Subject: RFR: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 09:20:25 GMT, Julia Boes wrote: >> Small test-only fix that generalizes the expected exception type from SSLHandshakeException to SSLException (a super class of the former). >> >> Testing: tier 1-3 and repeated runs of test in question all clear > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comment: remove bug id in test Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7144 From dfuchs at openjdk.java.net Thu Jan 20 12:12:49 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 20 Jan 2022 12:12:49 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 07:12:42 GMT, Xue-Lei Andrew Fan wrote: > In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method. > > The update is a minor correction so that the specification is not rely on the "protocols" variable. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7152 From jboes at openjdk.java.net Thu Jan 20 12:19:51 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 20 Jan 2022 12:19:51 GMT Subject: Integrated: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:01:22 GMT, Julia Boes wrote: > Small test-only fix that generalizes the expected exception type from SSLHandshakeException to SSLException (a super class of the former). > > Testing: tier 1-3 and repeated runs of test in question all clear This pull request has now been integrated. Changeset: 20297dea Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/20297deaeb64fb1e025ed1fcde19867c6875f9a0 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7144 From mullan at openjdk.java.net Thu Jan 20 14:19:56 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 20 Jan 2022 14:19:56 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 07:12:42 GMT, Xue-Lei Andrew Fan wrote: > In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method. > > The update is a minor correction so that the specification is not rely on the "protocols" variable. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 619: > 617: * > 618: * @return a non-null, possibly zero-length array of application protocol > 619: * {@code String}s. The array is placed in descending order of The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred." ------------- PR: https://git.openjdk.java.net/jdk/pull/7152 From xuelei at openjdk.java.net Thu Jan 20 14:46:28 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 20 Jan 2022 14:46:28 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters [v2] In-Reply-To: References: Message-ID: > In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method. > > The update is a minor correction so that the specification is not rely on the "protocols" variable. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Update per feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7152/files - new: https://git.openjdk.java.net/jdk/pull/7152/files/c16bf6c6..3992327e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7152&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7152&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7152.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7152/head:pull/7152 PR: https://git.openjdk.java.net/jdk/pull/7152 From xuelei at openjdk.java.net Thu Jan 20 14:46:30 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 20 Jan 2022 14:46:30 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters [v2] In-Reply-To: References: Message-ID: <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com> On Thu, 20 Jan 2022 14:16:43 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update per feedback > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 619: > >> 617: * >> 618: * @return a non-null, possibly zero-length array of application protocol >> 619: * {@code String}s. The array is placed in descending order of > > The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred." Hm, much better. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7152 From mullan at openjdk.java.net Thu Jan 20 15:04:48 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 20 Jan 2022 15:04:48 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 14:46:28 GMT, Xue-Lei Andrew Fan wrote: >> In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method. >> >> The update is a minor correction so that the specification is not rely on the "protocols" variable. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Update per feedback Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7152 From dfuchs at openjdk.java.net Thu Jan 20 15:34:49 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 20 Jan 2022 15:34:49 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters [v2] In-Reply-To: <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com> References: <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com> Message-ID: On Thu, 20 Jan 2022 14:42:56 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 619: >> >>> 617: * >>> 618: * @return a non-null, possibly zero-length array of application protocol >>> 619: * {@code String}s. The array is placed in descending order of >> >> The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred." > > Hm, much better. Thanks! > The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred." Thanks Sean - I had the same comment - but for some reason it seemed to have been lost when I clicked on Approve. Not sure what happened to it :-( ------------- PR: https://git.openjdk.java.net/jdk/pull/7152 From xuelei at openjdk.java.net Thu Jan 20 16:53:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 20 Jan 2022 16:53:55 GMT Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters [v2] In-Reply-To: References: <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com> Message-ID: On Thu, 20 Jan 2022 15:31:55 GMT, Daniel Fuchs wrote: >> Hm, much better. Thanks! > >> The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred." > > Thanks Sean - I had the same comment - but for some reason it seemed to have been lost when I clicked on Approve. Not sure what happened to it :-( Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/7152 From xuelei at openjdk.java.net Thu Jan 20 16:53:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 20 Jan 2022 16:53:56 GMT Subject: Integrated: 8280363: Minor correction of ALPN specification in SSLParameters In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 07:12:42 GMT, Xue-Lei Andrew Fan wrote: > In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method. > > The update is a minor correction so that the specification is not rely on the "protocols" variable. This pull request has now been integrated. Changeset: 0ea2b390 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/0ea2b39035f1b535a53770379c94ae43f0ddb8b6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8280363: Minor correction of ALPN specification in SSLParameters Reviewed-by: dfuchs, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/7152 From djelinski at openjdk.java.net Fri Jan 21 08:31:05 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 21 Jan 2022 08:31:05 GMT Subject: RFR: 8280414: Memory leak in DefaultProxySelector Message-ID: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> We were leaking the list returned by `createProxyList`. Verified that the leak is no longer present with this patch. Also removed a few unused variables. Reported by clang-tidy. ------------- Commit messages: - Fix memory leak Changes: https://git.openjdk.java.net/jdk/pull/7172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7172&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280414 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7172/head:pull/7172 PR: https://git.openjdk.java.net/jdk/pull/7172 From aturbanov at openjdk.java.net Fri Jan 21 08:56:52 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 21 Jan 2022 08:56:52 GMT Subject: Integrated: 8277120: Use Optional.isEmpty instead of !Optional.isPresent in java.net.http In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 07:55:52 GMT, Andrey Turbanov wrote: > I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method. > It's makes code a bit easier to read. This pull request has now been integrated. Changeset: 47b1c51b Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/47b1c51bbd28582d209db07052e553a76acced65 Stats: 11 lines in 5 files changed: 0 ins; 2 del; 9 mod 8277120: Use Optional.isEmpty instead of !Optional.isPresent in java.net.http Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5985 From dfuchs at openjdk.java.net Fri Jan 21 10:43:51 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 10:43:51 GMT Subject: RFR: 8280414: Memory leak in DefaultProxySelector In-Reply-To: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> References: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> Message-ID: On Fri, 21 Jan 2022 08:25:30 GMT, Daniel Jeli?ski wrote: > We were leaking the list returned by `createProxyList`. Verified that the leak is no longer present with this patch. Also removed a few unused variables. > > Reported by clang-tidy. Look reasonable to me. Did you run tier1 - tier2 and tested locally? ------------- PR: https://git.openjdk.java.net/jdk/pull/7172 From djelinski at openjdk.java.net Fri Jan 21 10:59:52 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 21 Jan 2022 10:59:52 GMT Subject: RFR: 8280414: Memory leak in DefaultProxySelector In-Reply-To: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> References: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> Message-ID: On Fri, 21 Jan 2022 08:25:30 GMT, Daniel Jeli?ski wrote: > We were leaking the list returned by `createProxyList`. Verified that the leak is no longer present with this patch. Also removed a few unused variables. > > Reported by clang-tidy. Tested locally. Returned values look correct, and the leak is removed. I also run jdk_net test suite, all green. ------------- PR: https://git.openjdk.java.net/jdk/pull/7172 From djelinski at openjdk.java.net Fri Jan 21 13:21:50 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 21 Jan 2022 13:21:50 GMT Subject: RFR: 8280414: Memory leak in DefaultProxySelector In-Reply-To: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> References: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> Message-ID: <0MwjgW7ZYCkbECFX2t_95rlrIlkxxJvLbj2XUiivAwY=.0ff3d770-0761-4692-baa9-6e35738412b5@github.com> On Fri, 21 Jan 2022 08:25:30 GMT, Daniel Jeli?ski wrote: > We were leaking the list returned by `createProxyList`. Verified that the leak is no longer present with this patch. Also removed a few unused variables. > > Reported by clang-tidy. tier1 and tier2 also passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7172 From michaelm at openjdk.java.net Fri Jan 21 13:41:54 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 13:41:54 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 20 Jan 2022 11:04:18 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed sasl module dependency and added SaslException cause > > src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > >> 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos >> 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with >> 220: {@code HttpURLConnection}. There are three possible settings:

> > Should it be `{@code HttpsURLConnection}`? > (BTW - can we use {@code } here ? Would be worth checking the generated doc) Right HttpsURLConnection is better. {@code} works here. > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189: > >> 187: } else { >> 188: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); >> 189: return s; > > Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here. It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 13:41:55 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 13:41:55 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> Message-ID: <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> On Thu, 20 Jan 2022 11:14:40 GMT, Michael Osipov wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed sasl module dependency and added SaslException cause > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > >> 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); >> 132: } catch (ChannelBindingException e) { >> 133: throw new SaslException(e.getMessage(), e); > > Why not ust pass the exception if the API allows? This looks like message duplication. Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 14:14:33 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 14:14:33 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 20 Jan 2022 11:16:16 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed sasl module dependency and added SaslException cause > > src/java.base/share/classes/sun/security/util/ChannelBindingException.java line 31: > >> 29: * Thrown by TlsChannelBinding if an error occurs >> 30: */ >> 31: public class ChannelBindingException extends Exception { > > Should this extend `GeneralSecurityException` instead? Or should we just remove this class and throw plain `GeneralSecurityException` in `TlsChannelBinding` ? I think a distinct exception is necessary. I don't have a strong opinion on whether it should extend GeneralSecurityException. > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 143: > >> 141: tlsCB = TlsChannelBinding.create(cert); >> 142: } catch (ChannelBindingException e) { >> 143: throw new SaslException(e.getMessage()); > > Why is there a difference compared to line 133? Right, that was a mistake. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Fri Jan 21 14:14:45 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Fri, 21 Jan 2022 14:14:45 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> Message-ID: <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> On Fri, 21 Jan 2022 13:35:53 GMT, Michael McMahon wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: >> >>> 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); >>> 132: } catch (ChannelBindingException e) { >>> 133: throw new SaslException(e.getMessage(), e); >> >> Why not ust pass the exception if the API allows? This looks like message duplication. > > Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception. `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 14:24:39 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 14:24:39 GMT Subject: RFR: 8280414: Memory leak in DefaultProxySelector In-Reply-To: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> References: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> Message-ID: On Fri, 21 Jan 2022 08:25:30 GMT, Daniel Jeli?ski wrote: > We were leaking the list returned by `createProxyList`. Verified that the leak is no longer present with this patch. Also removed a few unused variables. > > Reported by clang-tidy. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7172 From djelinski at openjdk.java.net Fri Jan 21 14:52:47 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 21 Jan 2022 14:52:47 GMT Subject: RFR: 8280414: Memory leak in DefaultProxySelector In-Reply-To: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> References: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> Message-ID: On Fri, 21 Jan 2022 08:25:30 GMT, Daniel Jeli?ski wrote: > We were leaking the list returned by `createProxyList`. Verified that the leak is no longer present with this patch. Also removed a few unused variables. > > Reported by clang-tidy. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/7172 From jboes at openjdk.java.net Fri Jan 21 14:56:17 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 21 Jan 2022 14:56:17 GMT Subject: [jdk18] RFR: 8280441: "classpath exception" in several files from jdk.httpserver Message-ID: This change adds the classpath exception to the copyright header of the files in question. As source files, they should have both the GPL and the classpath exception. ------------- Commit messages: - initial commit Changes: https://git.openjdk.java.net/jdk18/pull/111/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=111&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280441 Stats: 28 lines in 7 files changed: 14 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk18/pull/111.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/111/head:pull/111 PR: https://git.openjdk.java.net/jdk18/pull/111 From dfuchs at openjdk.java.net Fri Jan 21 14:56:17 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 14:56:17 GMT Subject: [jdk18] RFR: 8280441: "classpath exception" in several files from jdk.httpserver In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 14:38:08 GMT, Julia Boes wrote: > This change adds the classpath exception to the copyright header of the files in question. As source files, they should have both the GPL and the classpath exception. Should you make this PR against jdk-18 repo instead? ------------- PR: https://git.openjdk.java.net/jdk18/pull/111 From alanb at openjdk.java.net Fri Jan 21 15:10:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 21 Jan 2022 15:10:48 GMT Subject: [jdk18] RFR: 8280441: "classpath exception" in several files from jdk.httpserver In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 14:38:08 GMT, Julia Boes wrote: > This change adds the classpath exception to the copyright header of the files in question. As source files, they should have both the GPL and the classpath exception. P1?P5 doc bugs are okay to integrate in JDK 18 RDP2, I think fixes copyright header are in the same bucket. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/111 From michaelm at openjdk.java.net Fri Jan 21 15:11:42 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 15:11:42 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 13:38:08 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189: >> >>> 187: } else { >>> 188: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); >>> 189: return s; >> >> Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here. > > It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here. Sorry, I should have checked back to the source rather than the snippet quoted. The problem is that the logError call is in the wrong place. It should be before line 186. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 15:26:33 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 15:26:33 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: more tidy-up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/fd56b5e3..c9975fd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=02-03 Stats: 12 lines in 4 files changed: 5 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 15:27:52 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 15:27:52 GMT Subject: [jdk18] RFR: 8280441: Missing "classpath exception" in several files from jdk.httpserver In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 14:38:08 GMT, Julia Boes wrote: > This change adds the classpath exception to the copyright header of the files in question. As source files, they should have both the GPL and the classpath exception. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/111 From dfuchs at openjdk.java.net Fri Jan 21 15:35:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 15:35:43 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 15:08:58 GMT, Michael McMahon wrote: >> It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here. > > Sorry, I should have checked back to the source rather than the snippet quoted. The problem is that the logError call is in the wrong place. It should be before line 186. Though some other adjustments are also required Ah! Yes - I was also bitten again by the negation in the `if` too. The presence of `logError` in the body of the `if` will make it clearer :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 15:35:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 15:35:44 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <7Zv8iD7zLtr7WSXkcyMCSnG6aHOLuEH7GOWsrmNTvTs=.f88978ea-ddb9-4c78-8634-f762071e4ec9@github.com> On Fri, 21 Jan 2022 15:26:33 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > more tidy-up src/java.base/share/classes/sun/net/www/http/HttpClient.java line 191: > 189: } else { > 190: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); > 191: return "never"; Much easier to review now :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 15:43:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 15:43:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 15:26:33 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > more tidy-up Marked as reviewed by dfuchs (Reviewer). src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144: > 142: } catch (ChannelBindingException e) { > 143: throw new NamingException(e.getMessage()); > 144: } Should we call initCause here and above? I see that we do call initCause in NegotiatorImpl.java. On the one hand it's better for diagnostic. On the other hand it exposes a module-internal exception class which is not great. Or maybe we should set the cause of the CBE as the cause of NamingException. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 15:54:59 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 15:54:59 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> Message-ID: <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com> On Fri, 21 Jan 2022 13:39:06 GMT, Michael Osipov wrote: >> Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception. > > `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained. Yes, I can do that. Though it will cause the existing LDAP channel binding test to fail which is checking for an empty root cause. That is checking unspecified behavior and I can change it to check for a `ChannelBindingException` as root cause. So long as we are okay having a non public exception type as the root cause, it's probably helpful to have the full stack there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 16:02:29 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 16:02:29 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: added root cause to NamingException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/c9975fd1..058c3830 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=03-04 Stats: 16 lines in 2 files changed: 8 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Fri Jan 21 16:02:31 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Fri, 21 Jan 2022 16:02:31 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com> Message-ID: On Fri, 21 Jan 2022 15:51:10 GMT, Michael McMahon wrote: >> `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained. > > Yes, I can do that. Though it will cause the existing LDAP channel binding test to fail which is checking for an empty root cause. That is checking unspecified behavior and I can change it to check for a `ChannelBindingException` as root cause. So long as we are okay having a non public exception type as the root cause, it's probably helpful to have the full stack there. Yes please retain as much information as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From djelinski at openjdk.java.net Fri Jan 21 16:57:08 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 21 Jan 2022 16:57:08 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC Message-ID: Fix RFC compliance. Tier1 and tier2 passed. ------------- Commit messages: - Fix default Accept header Changes: https://git.openjdk.java.net/jdk/pull/7181/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7181&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8163921 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7181/head:pull/7181 PR: https://git.openjdk.java.net/jdk/pull/7181 From dfuchs at openjdk.java.net Fri Jan 21 17:53:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 17:53:44 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > added root cause to NamingException Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 17:55:42 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 17:55:42 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 16:51:20 GMT, Daniel Jeli?ski wrote: > Fix RFC compliance. > Tier1 and tier2 passed. Could you update the copyright years and add `8163921` to the `@bug` tag in the test? ------------- PR: https://git.openjdk.java.net/jdk/pull/7181 From weijun at openjdk.java.net Fri Jan 21 19:51:12 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 Jan 2022 19:51:12 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com> On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > added root cause to NamingException src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos > 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with > 220: {@code HttpsURLConnection}. There are three possible settings:

You can probably mention here that the 'tls-server-end-point' Channel Binding Type defined in RFC 5929 is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From djelinski at openjdk.java.net Fri Jan 21 19:53:55 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 21 Jan 2022 19:53:55 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2] In-Reply-To: References: Message-ID: <72bs-I25CVCeElNeMNQQUQEI-ST5zYjtOaCbRiBeLRY=.c2a1ef8c-ccd0-4976-97f3-f045dc2d31cf@github.com> > Fix RFC compliance. > Tier1 and tier2 passed. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7181/files - new: https://git.openjdk.java.net/jdk/pull/7181/files/be017d19..86d6d6d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7181&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7181&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7181/head:pull/7181 PR: https://git.openjdk.java.net/jdk/pull/7181 From weijun at openjdk.java.net Fri Jan 21 19:59:25 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 Jan 2022 19:59:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <7hhc0sEj6x1SvXw2uNKpTvyM4Ye65jpUdYTF1IV8dz8=.65223e7a-defb-4737-be99-f3d14bf153af@github.com> On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > added root cause to NamingException Please move // TLS channel binding type property public static final String CHANNEL_BINDING_TYPE = "com.sun.jndi.ldap.tls.cbtype"; // internal TLS channel binding property public static final String CHANNEL_BINDING = "jdk.internal.sasl.tlschannelbinding"; outside of the `TlsChannelBinding` class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From thomas.stuefe at gmail.com Sat Jan 22 10:23:19 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 22 Jan 2022 11:23:19 +0100 Subject: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected In-Reply-To: <4cd329f0-766b-3f50-da29-c1908a0f1bd1@oracle.com> References: <4cd329f0-766b-3f50-da29-c1908a0f1bd1@oracle.com> Message-ID: Redirecting to net-dev On Sat, Jan 22, 2022 at 11:00 AM Alan Bateman wrote: > On 22/01/2022 08:40, Thomas St?fe wrote: > > Hi Micheal, > > > > welcome, and thank you for your contribution! > > > > I opened a bug id for you to track this: > > https://bugs.openjdk.java.net/browse/JDK-8280498 . I can sponsor this > patch > > for you. > > > > You need one reviewer, I think. I don't have the cycles right now to > think > > this through. I cc core-libs dev since this is a networking issue and one > > of their tests. > > > The networking tests are maintained on net-dev so if there is a PR then > it should go to that list. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.java.net Sat Jan 22 21:15:29 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 22 Jan 2022 21:15:29 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build Message-ID: Use presumed syntax that will be introduced by JDK-8280488. ------------- Commit messages: - JDK-8280492: Address remaining doclint issues in JDK build Changes: https://git.openjdk.java.net/jdk/pull/7189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280492 Stats: 57 lines in 17 files changed: 0 ins; 0 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/7189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7189/head:pull/7189 PR: https://git.openjdk.java.net/jdk/pull/7189 From darcy at openjdk.java.net Sat Jan 22 21:38:04 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 22 Jan 2022 21:38:04 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. This should be the (near) final step to fully enable all doclint checks during the javac portion of the build. The "reference" doclint check is currently disabled in the build command for several modules. The problematic references are cross-module @see and @link tags. This PR changes those tags to use a to a new proposed syntax for cross-module references. Before this PR is pushed, the javadoc changes need to be made and I'll update the make files to enable the "reference" warning category. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From iris at openjdk.java.net Sun Jan 23 04:20:09 2022 From: iris at openjdk.java.net (Iris Clark) Date: Sun, 23 Jan 2022 04:20:09 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From serb at openjdk.java.net Sun Jan 23 08:09:08 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 23 Jan 2022 08:09:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From lancea at openjdk.java.net Sun Jan 23 11:48:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 23 Jan 2022 11:48:06 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: <2G0jVnCjP0i0VZhKN-fy0jDFtkT3BbBVcBiOJdxT56c=.870ed070-ad3c-4c88-bced-9ccb6155867b@github.com> On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From jboes at openjdk.java.net Mon Jan 24 10:07:08 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 24 Jan 2022 10:07:08 GMT Subject: [jdk18] Integrated: 8280441: Missing "classpath exception" in several files from jdk.httpserver In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 14:38:08 GMT, Julia Boes wrote: > This change adds the classpath exception to the copyright header of the files in question. As source files, they should have both the GPL and the classpath exception. This pull request has now been integrated. Changeset: ead9fecc Author: Julia Boes URL: https://git.openjdk.java.net/jdk18/commit/ead9feccae75ab0491ce86a707f5056d88ac899a Stats: 28 lines in 7 files changed: 14 ins; 0 del; 14 mod 8280441: Missing "classpath exception" in several files from jdk.httpserver Reviewed-by: alanb, dfuchs ------------- PR: https://git.openjdk.java.net/jdk18/pull/111 From aixtools at felt.demon.nl Sun Jan 23 10:49:14 2022 From: aixtools at felt.demon.nl (Michael Felt) Date: Sun, 23 Jan 2022 11:49:14 +0100 Subject: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected In-Reply-To: References: <4cd329f0-766b-3f50-da29-c1908a0f1bd1@oracle.com> Message-ID: <05de01d81046$dcbd53a0$9637fae0$@felt.demon.nl> Thank you Thomas! From: Thomas St?fe Sent: Saturday, 22 January 2022 11:23 To: Alan Bateman Cc: Michael Felt ; ppc-aix-port-dev ; net-dev Subject: Re: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected Redirecting to net-dev On Sat, Jan 22, 2022 at 11:00 AM Alan Bateman > wrote: On 22/01/2022 08:40, Thomas St?fe wrote: > Hi Micheal, > > welcome, and thank you for your contribution! > > I opened a bug id for you to track this: > https://bugs.openjdk.java.net/browse/JDK-8280498 . I can sponsor this patch > for you. > > You need one reviewer, I think. I don't have the cycles right now to think > this through. I cc core-libs dev since this is a networking issue and one > of their tests. > The networking tests are maintained on net-dev so if there is a PR then it should go to that list. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.java.net Mon Jan 24 11:04:04 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 11:04:04 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by dfuchs (Reviewer). LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`... ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From prappo at openjdk.java.net Mon Jan 24 11:21:08 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 Jan 2022 11:21:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> References: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> Message-ID: On Mon, 24 Jan 2022 11:00:37 GMT, Daniel Fuchs wrote: > LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`... They will do it quicker, if you create new or support existing bugs in their bug trackers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From prappo at openjdk.java.net Mon Jan 24 11:36:04 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 Jan 2022 11:36:04 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From dfuchs at openjdk.java.net Mon Jan 24 12:03:05 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 12:03:05 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2] In-Reply-To: <72bs-I25CVCeElNeMNQQUQEI-ST5zYjtOaCbRiBeLRY=.c2a1ef8c-ccd0-4976-97f3-f045dc2d31cf@github.com> References: <72bs-I25CVCeElNeMNQQUQEI-ST5zYjtOaCbRiBeLRY=.c2a1ef8c-ccd0-4976-97f3-f045dc2d31cf@github.com> Message-ID: On Fri, 21 Jan 2022 19:53:55 GMT, Daniel Jeli?ski wrote: >> Fix RFC compliance. >> Tier1 and tier2 passed. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM. @Michael-Mc-Mahon what's your take? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7181 From michaelm at openjdk.java.net Mon Jan 24 13:36:47 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 13:36:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon 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 eight additional commits since the last revision: - fixed failing test issue and update for latest comments - Merge branch 'master' into spnego - added root cause to NamingException - more tidy-up - removed sasl module dependency and added SaslException cause - changes after first review round - cleanup but still no test. Will be added in closed repo - First version of fix. No test and feature enabled always. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/058c3830..ad80dfa2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=04-05 Stats: 17855 lines in 614 files changed: 12290 ins; 2870 del; 2695 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Mon Jan 24 13:36:50 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 13:36:50 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com> Message-ID: On Fri, 21 Jan 2022 19:48:02 GMT, Weijun Wang wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> added root cause to NamingException > > src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > >> 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos >> 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with >> 220: {@code HttpsURLConnection}. There are three possible settings:

> > You can probably mention here that the 'tls-server-end-point' Channel Binding Type defined in RFC 5929 is used. I've updated this and moved the two properties to LdapSasl where they are used. Also, the test that was failing before needed some further updates. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Mon Jan 24 13:57:10 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 13:57:10 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon 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 eight additional commits since the last revision: > > - fixed failing test issue and update for latest comments > - Merge branch 'master' into spnego > - added root cause to NamingException > - more tidy-up > - removed sasl module dependency and added SaslException cause > - changes after first review round > - cleanup but still no test. Will be added in closed repo > - First version of fix. No test and feature enabled always. src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 260: > 258: * @throws ChannelBindingException > 259: */ > 260: private static TlsChannelBindingType parseType(String cbType) throws ChannelBindingException { Maybe this method could throw NamingException directly now? That would avoid wrapping CBE into NamingException? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Mon Jan 24 14:32:37 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 14:32:37 GMT Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom Executor rejects a task Message-ID: This changes makes sure that pending requests are terminated if the selector manager thread exits due to exceptions. This includes: 1. completing CompletableFutures that were returned to the caller code 2. cancelling requests that are in flight 3. calling onError on BodySubscribers that may not have been completed Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too. ------------- Commit messages: - 8277969: HttpClient SelectorManager shuts down when custom Executor rejects a task Changes: https://git.openjdk.java.net/jdk/pull/7196/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7196&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277969 Stats: 1979 lines in 23 files changed: 1714 ins; 140 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/7196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7196/head:pull/7196 PR: https://git.openjdk.java.net/jdk/pull/7196 From michaelm at openjdk.java.net Mon Jan 24 14:41:11 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 14:41:11 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2] In-Reply-To: <72bs-I25CVCeElNeMNQQUQEI-ST5zYjtOaCbRiBeLRY=.c2a1ef8c-ccd0-4976-97f3-f045dc2d31cf@github.com> References: <72bs-I25CVCeElNeMNQQUQEI-ST5zYjtOaCbRiBeLRY=.c2a1ef8c-ccd0-4976-97f3-f045dc2d31cf@github.com> Message-ID: On Fri, 21 Jan 2022 19:53:55 GMT, Daniel Jeli?ski wrote: >> Fix RFC compliance. >> Tier1 and tier2 passed. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 293: > 291: static final String acceptString = > 292: "text/html, image/gif, image/jpeg, */*; q=0.2"; > 293: It looks syntactically correct now, but I wonder about the actual semantics, and whether it makes any sense to be asking for 80% reduction in quality of other media types. ------------- PR: https://git.openjdk.java.net/jdk/pull/7181 From michaelm at openjdk.java.net Mon Jan 24 15:25:15 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 15:25:15 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2] In-Reply-To: References: <72bs-I25CVCeElNeMNQQUQEI-ST5zYjtOaCbRiBeLRY=.c2a1ef8c-ccd0-4976-97f3-f045dc2d31cf@github.com> Message-ID: <7bBdEPy81-gtWRNR0VBJYt4tjniKNTfWt-3FDGcVxQQ=.bf4493b4-68b2-40d6-a2aa-985111b8e173@github.com> On Mon, 24 Jan 2022 14:38:02 GMT, Michael McMahon wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 293: > >> 291: static final String acceptString = >> 292: "text/html, image/gif, image/jpeg, */*; q=0.2"; >> 293: > > It looks syntactically correct now, but I wonder about the actual semantics, and whether it makes any sense to be asking for 80% reduction in quality of other media types. Should we just have `static final String acceptString = "*/*";` ------------- PR: https://git.openjdk.java.net/jdk/pull/7181 From weijun at openjdk.java.net Mon Jan 24 15:32:22 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 15:32:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon 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 eight additional commits since the last revision: > > - fixed failing test issue and update for latest comments > - Merge branch 'master' into spnego > - added root cause to NamingException > - more tidy-up > - removed sasl module dependency and added SaslException cause > - changes after first review round > - cleanup but still no test. Will be added in closed repo > - First version of fix. No test and feature enabled always. src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100: > (failed to retrieve contents of file, check the PR for context) I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Mon Jan 24 15:32:22 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 15:32:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 15:40:16 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> more tidy-up > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144: > >> 142: } catch (ChannelBindingException e) { >> 143: throw new NamingException(e.getMessage()); >> 144: } > > Should we call initCause here and above? I see that we do call initCause in NegotiatorImpl.java. > On the one hand it's better for diagnostic. On the other hand it exposes a module-internal exception class which is not great. Or maybe we should set the cause of the CBE as the cause of NamingException. As long as the spec has not dictated what the cause should be, I don't care if the exception type is internal or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Mon Jan 24 15:32:23 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 15:32:23 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <3iOOsm_palWB0x2iybPZZ4rtiUY6ObLy33Cpd1nPgxs=.3e5ac581-d1c3-433f-82a8-0144e0867547@github.com> On Mon, 24 Jan 2022 13:54:12 GMT, Daniel Fuchs wrote: >> Michael McMahon 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 eight additional commits since the last revision: >> >> - fixed failing test issue and update for latest comments >> - Merge branch 'master' into spnego >> - added root cause to NamingException >> - more tidy-up >> - removed sasl module dependency and added SaslException cause >> - changes after first review round >> - cleanup but still no test. Will be added in closed repo >> - First version of fix. No test and feature enabled always. > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 260: > >> 258: * @throws ChannelBindingException >> 259: */ >> 260: private static TlsChannelBindingType parseType(String cbType) throws ChannelBindingException { > > Maybe this method could throw NamingException directly now? That would avoid wrapping CBE into NamingException? My opinion is this method should be put back. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Mon Jan 24 15:57:15 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 15:57:15 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 15:23:44 GMT, Weijun Wang wrote: >> Michael McMahon 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 eight additional commits since the last revision: >> >> - fixed failing test issue and update for latest comments >> - Merge branch 'master' into spnego >> - added root cause to NamingException >> - more tidy-up >> - removed sasl module dependency and added SaslException cause >> - changes after first review round >> - cleanup but still no test. Will be added in closed repo >> - First version of fix. No test and feature enabled always. > > src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100: > >> (failed to retrieve contents of file, check the PR for context) > I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP. So, where should the two constant Strings go? It doesn't feel like they belong in java.base since they are JNDI/SASL related, and we can't have a method in `java.base` depending on code in other modules? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From djelinski at openjdk.java.net Mon Jan 24 17:33:12 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 24 Jan 2022 17:33:12 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2] In-Reply-To: <7bBdEPy81-gtWRNR0VBJYt4tjniKNTfWt-3FDGcVxQQ=.bf4493b4-68b2-40d6-a2aa-985111b8e173@github.com> References: <72bs-I25CVCeElNeMNQQUQEI-ST5zYjtOaCbRiBeLRY=.c2a1ef8c-ccd0-4976-97f3-f045dc2d31cf@github.com> <7bBdEPy81-gtWRNR0VBJYt4tjniKNTfWt-3FDGcVxQQ=.bf4493b4-68b2-40d6-a2aa-985111b8e173@github.com> Message-ID: On Mon, 24 Jan 2022 15:21:44 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 293: >> >>> 291: static final String acceptString = >>> 292: "text/html, image/gif, image/jpeg, */*; q=0.2"; >>> 293: >> >> It looks syntactically correct now, but I wonder about the actual semantics, and whether it makes any sense to be asking for 80% reduction in quality of other media types. > > Should we just have `static final String acceptString = "*/*";` yeah, that's a sensible default. `curl` is using that today. I'll adjust. ------------- PR: https://git.openjdk.java.net/jdk/pull/7181 From djelinski at openjdk.java.net Mon Jan 24 18:07:36 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 24 Jan 2022 18:07:36 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v3] In-Reply-To: References: Message-ID: > Fix RFC compliance. > Tier1 and tier2 passed. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Update accept header to */* ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7181/files - new: https://git.openjdk.java.net/jdk/pull/7181/files/86d6d6d1..b9683b31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7181&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7181&range=01-02 Stats: 8 lines in 2 files changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7181/head:pull/7181 PR: https://git.openjdk.java.net/jdk/pull/7181 From darcy at openjdk.java.net Mon Jan 24 18:25:08 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 18:25:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 11:33:18 GMT, Pavel Rappo wrote: > > Use presumed syntax that will be introduced by JDK-8280488. > > Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags. Ah; thanks Pavel for the additional context. Bug JDK-8280488 will allow (i.e. ignore) cross-module @see/@link references during javac compilation. So while the syntax in this PR is already valid per JDK-8164408, I cannot (yet) enable the "reference" doctlint check in the javac build due to the cross-module situation. I'll double-check the syntax in this PR generates the expected links in the result of the docs builds, give the bug a more descriptive title, and get these changes pushed. Enabling the reference warning can be done under another bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From aivanov at openjdk.java.net Mon Jan 24 18:57:10 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 24 Jan 2022 18:57:10 GMT Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From weijun at openjdk.java.net Mon Jan 24 19:13:11 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 19:13:11 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 15:54:01 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100: >> >>> (failed to retrieve contents of file, check the PR for context) >> I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP. > > So, where should the two constant Strings go? It doesn't feel like they belong in java.base since they are JNDI/SASL related, and we can't have a method in `java.base` depending on code in other modules? The 2 strings should be on the LDAP side. This method does not really depend on the strings except for mentioning one in the exception message. We can just rewrite it into `"Illegal channel binding type: " + cbType`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From jwilhelm at openjdk.java.net Mon Jan 24 20:00:50 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 24 Jan 2022 20:00:50 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18 - 8280441: Missing "classpath exception" in several files from jdk.httpserver - 8279179: Update nroff pages in JDK 18 before RC The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7203&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7203&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7203/files Stats: 62 lines in 10 files changed: 46 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/7203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7203/head:pull/7203 PR: https://git.openjdk.java.net/jdk/pull/7203 From darcy at openjdk.java.net Mon Jan 24 20:10:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 20:10:40 GMT Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links [v2] In-Reply-To: References: Message-ID: <8CLBwHk3ls8ijDaN-6poNrhGMxCulNGrjFvImPGQ-sY=.e8629cdc-b51d-4614-a5af-923f848d0703@github.com> > Use presumed syntax that will be introduced by JDK-8280488. 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: - Update copyrigths. - Merge branch 'master' into JDK-8280492 - JDK-8280492: Address remaining doclint issues in JDK build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7189/files - new: https://git.openjdk.java.net/jdk/pull/7189/files/b74e7d85..6f3bd429 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=00-01 Stats: 664 lines in 55 files changed: 433 ins; 128 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/7189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7189/head:pull/7189 PR: https://git.openjdk.java.net/jdk/pull/7189 From darcy at openjdk.java.net Mon Jan 24 20:20:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 20:20:12 GMT Subject: Integrated: JDK-8280492: Use cross-module syntax for cross-module links In-Reply-To: References: Message-ID: <2oUpK1s5mNt-fWdUF5YZP3MlqzjXypdqMMz8QG-3Q5U=.f971fd74-655b-400d-9718-11299edcb7c8@github.com> On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. This pull request has now been integrated. Changeset: 8e82d002 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/8e82d0021c119b7793870811fad37d7659c1174d Stats: 72 lines in 17 files changed: 0 ins; 0 del; 72 mod 8280492: Use cross-module syntax for cross-module links Reviewed-by: iris, serb, lancea, dfuchs, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From michaelm at openjdk.java.net Mon Jan 24 20:44:08 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 20:44:08 GMT Subject: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v3] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 18:07:36 GMT, Daniel Jeli?ski wrote: >> Fix RFC compliance. >> Tier1 and tier2 passed. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update accept header to */* LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7181 From jwilhelm at openjdk.java.net Mon Jan 24 21:57:13 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 24 Jan 2022 21:57:13 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 19:51:08 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 52ddbe2d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/52ddbe2dcdb2fa52d85c987443ffa14522ace729 Stats: 62 lines in 10 files changed: 46 ins; 0 del; 16 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7203 From michaelm at openjdk.java.net Mon Jan 24 22:11:51 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 22:11:51 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: more updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/ad80dfa2..0d529f9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=05-06 Stats: 38 lines in 2 files changed: 18 ins; 19 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Tue Jan 25 00:44:44 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 25 Jan 2022 00:44:44 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7] In-Reply-To: <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com> Message-ID: On Mon, 24 Jan 2022 22:11:51 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > more updates Looks good to me. Only several wording and style suggestions. I know you are asking SQE to create a security infra test, but I'll see if I can contribute a regression test. Don't wait for me. src/java.base/share/classes/java/net/doc-files/net-properties.html line 223: > 221:
    > 222:

  1. "never". This is also the default value if the property is not set. In this case, > 223: CBT's are never sent.

    Typo, "CBTs"? src/java.base/share/classes/java/net/doc-files/net-properties.html line 224: > 222:

  2. "never". This is also the default value if the property is not set. In this case, > 223: CBT's are never sent.

    > 224:

  3. "always". CBTs are sent for all Kerberos authentication attempts over HTTPS.

    Shall we remove "Kerberos"? Or we can use "Kerberos or Negotiate". src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java line 1: > 1: /** This is not a doc comment. src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java line 124: > 122: try { > 123: init(hci); > 124: } catch (GSSException | ChannelBindingException e) { Two spaces before "e". ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Tue Jan 25 10:30:20 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 25 Jan 2022 10:30:20 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: final review update (pre CSR) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/0d529f9d..004466ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=06-07 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Tue Jan 25 11:13:37 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 25 Jan 2022 11:13:37 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > final review update (pre CSR) The new version LGTM. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7065 From djelinski at openjdk.java.net Tue Jan 25 11:14:38 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 25 Jan 2022 11:14:38 GMT Subject: Integrated: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 16:51:20 GMT, Daniel Jeli?ski wrote: > Fix RFC compliance. > Tier1 and tier2 passed. This pull request has now been integrated. Changeset: 28796cbd Author: Daniel Jeli?ski Committer: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/28796cbd1d15de678b80295418f5d1f9f59176a6 Stats: 11 lines in 2 files changed: 0 ins; 1 del; 10 mod 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC Reviewed-by: dfuchs, michaelm ------------- PR: https://git.openjdk.java.net/jdk/pull/7181 From duke at openjdk.java.net Tue Jan 25 11:38:35 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Tue, 25 Jan 2022 11:38:35 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > final review update (pre CSR) src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: > 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is > 149: * a comma separated list of arbitrary length with no white-space allowed. > 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include Previously `Negotiate` was used, now `SPNEGO`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Tue Jan 25 12:50:37 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 25 Jan 2022 12:50:37 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 11:34:57 GMT, Michael Osipov wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> final review update (pre CSR) > > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: > >> 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is >> 149: * a comma separated list of arbitrary length with no white-space allowed. >> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include > > Previously `Negotiate` was used, now `SPNEGO`? "Negotiate" is the name of the HTTP authentication scheme which uses the SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Tue Jan 25 13:03:33 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Tue, 25 Jan 2022 13:03:33 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 12:47:26 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: >> >>> 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is >>> 149: * a comma separated list of arbitrary length with no white-space allowed. >>> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include >> >> Previously `Negotiate` was used, now `SPNEGO`? > > "Negotiate" is the name of the HTTP authentication scheme which uses the SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here. Yes, I know. That's the point. Clearly differentiate between GSS-API mech and HTTP auth scheme. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From djelinski at openjdk.java.net Tue Jan 25 14:45:33 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 25 Jan 2022 14:45:33 GMT Subject: Integrated: 8280414: Memory leak in DefaultProxySelector In-Reply-To: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> References: <9J-mFHgyqhW8bw47oDbVlmO0bq2JmEHY8BCpZ0gx-AQ=.34c93eed-0430-4a42-b2d8-aeb6cccbf119@github.com> Message-ID: On Fri, 21 Jan 2022 08:25:30 GMT, Daniel Jeli?ski wrote: > We were leaking the list returned by `createProxyList`. Verified that the leak is no longer present with this patch. Also removed a few unused variables. > > Reported by clang-tidy. This pull request has now been integrated. Changeset: fe77250f Author: Daniel Jeli?ski Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/fe77250fa450ec803d2818dc90c5bf156521d537 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod 8280414: Memory leak in DefaultProxySelector Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7172 From dfuchs at openjdk.java.net Tue Jan 25 17:24:35 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 25 Jan 2022 17:24:35 GMT Subject: RFR: 8277983: Remove unused fields from s.n.w.p.j.JarURLConnection In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 18:36:30 GMT, ?????? ??????? wrote: > There are some fields that are unused in current implementation of `JarURLConnection`: > - debug > - jarFileURL > - permission > - jarFileURLConnection (inherited one can be used) > - entryName (can be taken from super-class) > > They can be safely removed reducing object footprint. Before: > > sun.net.www.protocol.jar.JarURLConnection object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header) N/A > 12 4 int URLConnection.connectTimeout N/A > 16 8 long URLConnection.ifModifiedSince N/A > 24 4 int URLConnection.readTimeout N/A > 28 1 boolean URLConnection.doInput N/A > 29 1 boolean URLConnection.doOutput N/A > 30 1 boolean URLConnection.allowUserInteraction N/A > 31 1 boolean URLConnection.useCaches N/A > 32 1 boolean URLConnection.connected N/A > 33 3 (alignment/padding gap) > 36 4 java.net.URL URLConnection.url N/A > 40 4 sun.net.www.MessageHeader URLConnection.requests N/A > 44 4 java.net.URL JarURLConnection.jarFileURL N/A > 48 4 java.lang.String JarURLConnection.entryName N/A > 52 4 java.net.URLConnection JarURLConnection.jarFileURLConnection N/A > 56 4 java.net.URL JarURLConnection.jarFileURL N/A > 60 4 java.security.Permission JarURLConnection.permission N/A > 64 4 java.net.URLConnection JarURLConnection.jarFileURLConnection N/A > 68 4 java.lang.String JarURLConnection.entryName N/A > 72 4 java.util.jar.JarEntry JarURLConnection.jarEntry N/A > 76 4 java.util.jar.JarFile JarURLConnection.jarFile N/A > 80 4 java.lang.String JarURLConnection.contentType N/A > 84 4 (loss due to the next object alignment) > Instance size: 88 bytes > Space losses: 3 bytes internal + 4 bytes external = 7 bytes total > > After: > > sun.net.www.protocol.jar.JarURLConnection object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header) N/A > 12 4 int URLConnection.connectTimeout N/A > 16 8 long URLConnection.ifModifiedSince N/A > 24 4 int URLConnection.readTimeout N/A > 28 1 boolean URLConnection.doInput N/A > 29 1 boolean URLConnection.doOutput N/A > 30 1 boolean URLConnection.allowUserInteraction N/A > 31 1 boolean URLConnection.useCaches N/A > 32 1 boolean URLConnection.connected N/A > 33 3 (alignment/padding gap) > 36 4 java.net.URL URLConnection.url N/A > 40 4 sun.net.www.MessageHeader URLConnection.requests N/A > 44 4 java.net.URL JarURLConnection.jarFileURL N/A > 48 4 java.lang.String JarURLConnection.entryName N/A > 52 4 java.net.URLConnection JarURLConnection.jarFileURLConnection N/A > 56 4 java.util.jar.JarEntry JarURLConnection.jarEntry N/A > 60 4 java.util.jar.JarFile JarURLConnection.jarFile N/A > 64 4 java.lang.String JarURLConnection.contentType N/A > 68 4 (loss due to the next object alignment) > Instance size: 72 bytes > Space losses: 3 bytes internal + 4 bytes external = 7 bytes total LGTM Drop me a note after integrating and I will sponsor. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6649 From dfuchs at openjdk.java.net Tue Jan 25 19:39:31 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 25 Jan 2022 19:39:31 GMT Subject: RFR: 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:35:10 GMT, Andrey Turbanov wrote: > All this Handler's are stateless and there is nothing to protect via synchronization. LGTM. Please integrate and drop me a note and I will sponsor it. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6373 From duke at openjdk.java.net Tue Jan 25 21:04:30 2022 From: duke at openjdk.java.net (Florent Guillaume) Date: Tue, 25 Jan 2022 21:04:30 GMT Subject: RFR: 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods In-Reply-To: References: Message-ID: <5muwIJBThsK0K4cji-e9YsAOV44M59s_yEfrGV_-gps=.5f9c2d65-d7a3-4009-9ff9-f93972aeeffa@github.com> On Fri, 12 Nov 2021 19:35:10 GMT, Andrey Turbanov wrote: > All this Handler's are stateless and there is nothing to protect via synchronization. In theory a subclass overloading using a non-synchronized `openConnection(URL u, Proxy p)` could have relied on `openConnection(URL u)` delegating to it and having been synchronized. So maybe this requires a small CSR? ------------- PR: https://git.openjdk.java.net/jdk/pull/6373 From jpai at openjdk.java.net Wed Jan 26 03:26:15 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 26 Jan 2022 03:26:15 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v7] In-Reply-To: References: Message-ID: > This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137. > > The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections. Jaikiran Pai 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 21 additional commits since the last revision: - Merge latest from master branch - Merge latest from master branch - copyright year - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient - Merge latest master branch - Merge latest from master branch - add a security manager test to verify proper permission checks happen when local address is configured on HTTPClient - Merge latest from master branch - add a note to the javadoc of the new API to explain that calling localAddress() is only for advanced usages - move the security checks to the HttpClient itself instead of the builder - ... and 11 more: https://git.openjdk.java.net/jdk/compare/7773986d...5ecb4db4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/0217e1c1..5ecb4db4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=05-06 Stats: 19391 lines in 831 files changed: 12966 ins; 3096 del; 3329 mod Patch: https://git.openjdk.java.net/jdk/pull/6690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690 PR: https://git.openjdk.java.net/jdk/pull/6690 From alanb at openjdk.java.net Wed Jan 26 09:42:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 Jan 2022 09:42:34 GMT Subject: RFR: 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods In-Reply-To: <5muwIJBThsK0K4cji-e9YsAOV44M59s_yEfrGV_-gps=.5f9c2d65-d7a3-4009-9ff9-f93972aeeffa@github.com> References: <5muwIJBThsK0K4cji-e9YsAOV44M59s_yEfrGV_-gps=.5f9c2d65-d7a3-4009-9ff9-f93972aeeffa@github.com> Message-ID: On Tue, 25 Jan 2022 21:01:42 GMT, Florent Guillaume wrote: > In theory a subclass overloading using a non-synchronized `openConnection(URL u, Proxy p)` could have relied on `openConnection(URL u)` delegating to it and having been synchronized. So maybe this requires a small CSR? The changes are to the JDK internal classes that implement the file and mailto protocol handlers. Are you thinking about code that extends the sun.* classes or some other scenario? ------------- PR: https://git.openjdk.java.net/jdk/pull/6373 From duke at openjdk.java.net Wed Jan 26 11:13:30 2022 From: duke at openjdk.java.net (Florent Guillaume) Date: Wed, 26 Jan 2022 11:13:30 GMT Subject: RFR: 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods In-Reply-To: References: <5muwIJBThsK0K4cji-e9YsAOV44M59s_yEfrGV_-gps=.5f9c2d65-d7a3-4009-9ff9-f93972aeeffa@github.com> Message-ID: On Wed, 26 Jan 2022 09:38:58 GMT, Alan Bateman wrote: > Are you thinking about code that extends the sun.* classes? Yes that was my idea, but indeed if there's no way for them to be extended by user code it's probably not an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/6373 From duke at openjdk.java.net Wed Jan 26 14:16:36 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 26 Jan 2022 14:16:36 GMT Subject: Integrated: 8277983: Remove unused fields from sun.net.www.protocol.jar.JarURLConnection In-Reply-To: References: Message-ID: <-NColkCsmbC-LWwLj6myM3w2UO6iQp0TToVGL8e8BLM=.851ec8f5-bf46-44bb-9153-215c2ed88d86@github.com> On Wed, 1 Dec 2021 18:36:30 GMT, ?????? ??????? wrote: > There are some fields that are unused in current implementation of `JarURLConnection`: > - debug > - jarFileURL > - permission > - jarFileURLConnection (inherited one can be used) > - entryName (can be taken from super-class) > > They can be safely removed reducing object footprint. Before: > > sun.net.www.protocol.jar.JarURLConnection object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header) N/A > 12 4 int URLConnection.connectTimeout N/A > 16 8 long URLConnection.ifModifiedSince N/A > 24 4 int URLConnection.readTimeout N/A > 28 1 boolean URLConnection.doInput N/A > 29 1 boolean URLConnection.doOutput N/A > 30 1 boolean URLConnection.allowUserInteraction N/A > 31 1 boolean URLConnection.useCaches N/A > 32 1 boolean URLConnection.connected N/A > 33 3 (alignment/padding gap) > 36 4 java.net.URL URLConnection.url N/A > 40 4 sun.net.www.MessageHeader URLConnection.requests N/A > 44 4 java.net.URL JarURLConnection.jarFileURL N/A > 48 4 java.lang.String JarURLConnection.entryName N/A > 52 4 java.net.URLConnection JarURLConnection.jarFileURLConnection N/A > 56 4 java.net.URL JarURLConnection.jarFileURL N/A > 60 4 java.security.Permission JarURLConnection.permission N/A > 64 4 java.net.URLConnection JarURLConnection.jarFileURLConnection N/A > 68 4 java.lang.String JarURLConnection.entryName N/A > 72 4 java.util.jar.JarEntry JarURLConnection.jarEntry N/A > 76 4 java.util.jar.JarFile JarURLConnection.jarFile N/A > 80 4 java.lang.String JarURLConnection.contentType N/A > 84 4 (loss due to the next object alignment) > Instance size: 88 bytes > Space losses: 3 bytes internal + 4 bytes external = 7 bytes total > > After: > > sun.net.www.protocol.jar.JarURLConnection object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header) N/A > 12 4 int URLConnection.connectTimeout N/A > 16 8 long URLConnection.ifModifiedSince N/A > 24 4 int URLConnection.readTimeout N/A > 28 1 boolean URLConnection.doInput N/A > 29 1 boolean URLConnection.doOutput N/A > 30 1 boolean URLConnection.allowUserInteraction N/A > 31 1 boolean URLConnection.useCaches N/A > 32 1 boolean URLConnection.connected N/A > 33 3 (alignment/padding gap) > 36 4 java.net.URL URLConnection.url N/A > 40 4 sun.net.www.MessageHeader URLConnection.requests N/A > 44 4 java.net.URL JarURLConnection.jarFileURL N/A > 48 4 java.lang.String JarURLConnection.entryName N/A > 52 4 java.net.URLConnection JarURLConnection.jarFileURLConnection N/A > 56 4 java.util.jar.JarEntry JarURLConnection.jarEntry N/A > 60 4 java.util.jar.JarFile JarURLConnection.jarFile N/A > 64 4 java.lang.String JarURLConnection.contentType N/A > 68 4 (loss due to the next object alignment) > Instance size: 72 bytes > Space losses: 3 bytes internal + 4 bytes external = 7 bytes total This pull request has now been integrated. Changeset: f34f8d4d Author: stsypanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/f34f8d4d6a9b3e24a93a322b985c1413c27311cc Stats: 35 lines in 1 file changed: 4 ins; 24 del; 7 mod 8277983: Remove unused fields from sun.net.www.protocol.jar.JarURLConnection Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/6649 From dfuchs at openjdk.java.net Wed Jan 26 14:25:35 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 Jan 2022 14:25:35 GMT Subject: RFR: 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:11:36 GMT, Andrey Turbanov wrote: > All this manually written code actually can be replaced with single String.isBlank() call. > `file` variable is guaranteed to be non-null. I'm running tier1-3 and will approve if the results come green. ------------- PR: https://git.openjdk.java.net/jdk/pull/6372 From michaelm at openjdk.java.net Wed Jan 26 15:41:22 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 26 Jan 2022 15:41:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v9] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Added unit test and comment update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/004466ea..e5a5a79a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=07-08 Stats: 312 lines in 2 files changed: 311 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Wed Jan 26 16:02:09 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 26 Jan 2022 16:02:09 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: removed ^M from test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/e5a5a79a..b44184de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=08-09 Stats: 311 lines in 1 file changed: 0 ins; 0 del; 311 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Wed Jan 26 16:32:38 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 Jan 2022 16:32:38 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 16:02:09 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > removed ^M from test Looks mostly good. Some doubts about catching just any exception indiscriminately though. test/jdk/sun/security/krb5/auto/HttpsCB.java line 120: > 118: > 119: boolean expected1 = Boolean.parseBoolean(args[0]); > 120: boolean expected2 = Boolean.parseBoolean(args[1]); It might be better for future maintainers and readability if these two variables could have better names, and possibly a comment to explain their purpose. AFAIU it's the expected result of running with/without CBT - where `true` means that the operation should succeed and `false` that it's expected to fail with some exception... test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: > 199: return reader.readLine().equals(CONTENT); > 200: } catch (Exception e) { > 201: return false; Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Wed Jan 26 17:05:31 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 Jan 2022 17:05:31 GMT Subject: RFR: 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:11:36 GMT, Andrey Turbanov wrote: > All this manually written code actually can be replaced with single String.isBlank() call. > `file` variable is guaranteed to be non-null. LGTM. Testing didn't reveal any issue. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6372 From dfuchs at openjdk.java.net Wed Jan 26 18:52:48 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 Jan 2022 18:52:48 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v6] In-Reply-To: References: Message-ID: <1DA_-gzNB4ILcYgH4DwXDUKXyPwfxUU6w2t8tguua0I=.5bd75aa1-6c42-4747-b5bc-77734f4dfb97@github.com> On Wed, 19 Jan 2022 08:15:24 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 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 12 additional commits since the last revision: > > - Fix invalid free > - Merge remote-tracking branch 'origin' into interface-cleanup > - Remove redundant initialization > - Remove unused / incorrect exit code -2 from enumInterfaces > - Address problems reported by clang-tidy > - Restore support for IPv6-only operation > - Fix memory leak > - Fixup getAllInterfacesAndAddresses > - Fixup getAddrsFromAdapter > - Fixup enumAddresses_win > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/15024daa...98b40812 src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 253: > 251: > 252: ret = enumInterfaces(env, netifPP); > 253: if (ret < 0) { Why did we remove handling for -2 here when `enumInterfaces` might return -2 if it does not find any IPv4 network interface? Shouldn't we keep the code that reset the exception status and set *netifPP = null here if ret == -2? src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 271: > 269: ret = lookupIPAddrTable(env, &tableP); > 270: if (ret == -1) { > 271: free_netif(*netifPP); *netifPP might be null here. src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 280: > 278: tableP = NULL; > 279: } > 280: while (curr != NULL) { Maybe we should not enter here if tableP == null. Looks like it should be `while ( curr != NULL && tableP != null)` - either that or guard the block with an `if (tableP != NULL)` ? src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 297: > 295: flags = GAA_FLAG_SKIP_DNS_SERVER; > 296: flags |= GAA_FLAG_SKIP_MULTICAST; > 297: flags |= GAA_FLAG_INCLUDE_PREFIX; tableP could be null at lime 293 - `free(tableP)` should be guarded by a null check ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From weijun at openjdk.java.net Wed Jan 26 19:03:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 26 Jan 2022 19:03:40 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 16:27:29 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: > >> 199: return reader.readLine().equals(CONTENT); >> 200: } catch (Exception e) { >> 201: return false; > > Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting? It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Wed Jan 26 19:08:38 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 26 Jan 2022 19:08:38 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 16:25:24 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 120: > >> 118: >> 119: boolean expected1 = Boolean.parseBoolean(args[0]); >> 120: boolean expected2 = Boolean.parseBoolean(args[1]); > > It might be better for future maintainers and readability if these two variables could have better names, and possibly a comment to explain their purpose. AFAIU it's the expected result of running with/without CBT - where `true` means that the operation should succeed and `false` that it's expected to fail with some exception... Maybe `expectedCbtUrlResult` and `expectedNormalUrlResult`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From djelinski at openjdk.java.net Wed Jan 26 20:13:48 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 26 Jan 2022 20:13:48 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v6] In-Reply-To: <1DA_-gzNB4ILcYgH4DwXDUKXyPwfxUU6w2t8tguua0I=.5bd75aa1-6c42-4747-b5bc-77734f4dfb97@github.com> References: <1DA_-gzNB4ILcYgH4DwXDUKXyPwfxUU6w2t8tguua0I=.5bd75aa1-6c42-4747-b5bc-77734f4dfb97@github.com> Message-ID: On Wed, 26 Jan 2022 18:25:19 GMT, Daniel Fuchs wrote: >> Daniel Jeli?ski 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 12 additional commits since the last revision: >> >> - Fix invalid free >> - Merge remote-tracking branch 'origin' into interface-cleanup >> - Remove redundant initialization >> - Remove unused / incorrect exit code -2 from enumInterfaces >> - Address problems reported by clang-tidy >> - Restore support for IPv6-only operation >> - Fix memory leak >> - Fixup getAllInterfacesAndAddresses >> - Fixup getAddrsFromAdapter >> - Fixup enumAddresses_win >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/fec97562...98b40812 > > src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 253: > >> 251: >> 252: ret = enumInterfaces(env, netifPP); >> 253: if (ret < 0) { > > Why did we remove handling for -2 here when `enumInterfaces` might return -2 if it does not find any IPv4 network interface? Shouldn't we keep the code that reset the exception status and set *netifPP = null here if ret == -2? `enumInterfaces` no longer returns -2. It does not fail on IPv6 machines, and if it failed, our code wouldn't recover anyway. After a discussion with @msheppar I decided to remove -2 from the list of possible return values. > src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 271: > >> 269: ret = lookupIPAddrTable(env, &tableP); >> 270: if (ret == -1) { >> 271: free_netif(*netifPP); > > *netifPP might be null here. `free_netif` (and all other `free` functions) handle `null` input just fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From dfuchs at openjdk.java.net Thu Jan 27 10:32:33 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 Jan 2022 10:32:33 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v6] In-Reply-To: References: <1DA_-gzNB4ILcYgH4DwXDUKXyPwfxUU6w2t8tguua0I=.5bd75aa1-6c42-4747-b5bc-77734f4dfb97@github.com> Message-ID: On Wed, 26 Jan 2022 20:09:36 GMT, Daniel Jeli?ski wrote: >> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 253: >> >>> 251: >>> 252: ret = enumInterfaces(env, netifPP); >>> 253: if (ret < 0) { >> >> Why did we remove handling for -2 here when `enumInterfaces` might return -2 if it does not find any IPv4 network interface? Shouldn't we keep the code that reset the exception status and set *netifPP = null here if ret == -2? > > `enumInterfaces` no longer returns -2. It does not fail on IPv6 machines, and if it failed, our code wouldn't recover anyway. After a discussion with @msheppar I decided to remove -2 from the list of possible return values. Oh - I see I missed that in the diff. That's the change at line 216. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From dfuchs at openjdk.java.net Thu Jan 27 15:13:35 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 Jan 2022 15:13:35 GMT Subject: RFR: 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:35:10 GMT, Andrey Turbanov wrote: > All this Handler's are stateless and there is nothing to protect via synchronization. There should be no code outside of the JDK extending those classes, especially with strong encapsulation in place. I believe this is good to go! ------------- PR: https://git.openjdk.java.net/jdk/pull/6373 From michaelm at openjdk.java.net Thu Jan 27 15:54:15 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 27 Jan 2022 15:54:15 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v11] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: test update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/b44184de..d604ee7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=09-10 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Thu Jan 27 16:50:49 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 Jan 2022 16:50:49 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 19:00:14 GMT, Weijun Wang wrote: >> test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: >> >>> 199: return reader.readLine().equals(CONTENT); >>> 200: } catch (Exception e) { >>> 201: return false; >> >> Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting? > > It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing. Thanks. Then it would be better to catch only `SocketException` here rather than `Exception`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Thu Jan 27 18:05:25 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 27 Jan 2022 18:05:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v12] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon 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 15 additional commits since the last revision: - test update - Merge branch 'master' into spnego - test update - removed ^M from test - Added unit test and comment update - final review update (pre CSR) - more updates - fixed failing test issue and update for latest comments - Merge branch 'master' into spnego - added root cause to NamingException - ... and 5 more: https://git.openjdk.java.net/jdk/compare/35ce454c...59f703da ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/d604ee7f..59f703da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=10-11 Stats: 4735 lines in 368 files changed: 2835 ins; 809 del; 1091 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Thu Jan 27 18:05:27 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 27 Jan 2022 18:05:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <64ecMlTGcFJvgXe-Wo_R7F_3yrxSom_mb549yKt0MGo=.9b40e87d-59be-4a63-8b05-947afa00f475@github.com> On Thu, 27 Jan 2022 16:47:52 GMT, Daniel Fuchs wrote: >> It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing. > > Thanks. Then it would be better to catch only `SocketException` here rather than `Exception`. I'll make it catch `IOException` ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Thu Jan 27 18:12:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 Jan 2022 18:12:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v12] In-Reply-To: <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com> Message-ID: On Thu, 27 Jan 2022 18:05:25 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon 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 15 additional commits since the last revision: > > - test update > - Merge branch 'master' into spnego > - test update > - removed ^M from test > - Added unit test and comment update > - final review update (pre CSR) > - more updates > - fixed failing test issue and update for latest comments > - Merge branch 'master' into spnego > - added root cause to NamingException > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/ceb44101...59f703da LGTM! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7065 From xuelei at openjdk.java.net Thu Jan 27 22:13:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 27 Jan 2022 22:13:44 GMT Subject: RFR: 8280494: (D)TLS signature schemes 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 ------------- Commit messages: - 8280494: https://bugs.openjdk.java.net/browse/JDK-8280494 - 8280494: Implementation: (D)TLS signature schemes Changes: https://git.openjdk.java.net/jdk/pull/7252/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280494 Stats: 297 lines in 4 files changed: 253 ins; 12 del; 32 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 jiefu at openjdk.java.net Thu Jan 27 23:47:10 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 27 Jan 2022 23:47:10 GMT Subject: RFR: 8280494: (D)TLS signature schemes In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 22:06:21 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 src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 3: > 1: /* > 2: * Copyright (c) 2005, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved. No sure if we should add this new copyright line for Tencent. But for hotspot changes, we usually just update the copyright year from 2021 to 2022 if the original copyright is from Oracle. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From duke at openjdk.java.net Fri Jan 28 01:19:12 2022 From: duke at openjdk.java.net (Bernd) Date: Fri, 28 Jan 2022 01:19:12 GMT Subject: RFR: 8280494: (D)TLS signature schemes In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 22:06:21 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 I like the per-parameters configuration and we really should get it for more Systeme properties in the future. But I wonder if the additional allocations (some while doing handshakes?) can be avoided by doing more parsing/analysing in the parameter object already. It could even do the analysis of the system property at that time. Also the toggle semantic seems to be a bit different then you would expect, a extra flag to keep track of customized settings would probably fix that and avoid the array compares. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 92: > 90: private int maximumPacketSize = 0; > 91: private String[] applicationProtocols = new String[0]; > 92: private String[] signatureSchemes = new String[0]; There are some places in here which could use a local or global static EMPTY = new String[0]` value. That would be safe to share and reduces allocations (they surely escape). src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 745: > 743: * This method will make a copy of the {@code signatureSchemes} array. > 744: * > 745: * @param signatureSchemes an ordered array of signature scheme names, Should it mention that unknown schemes are ignored and not trigger a exception? src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763: > 761: > 762: String[] tempSchemes = signatureSchemes.clone(); > 763: for (String scheme : tempSchemes) { In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused) src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 66: > 64: // The configured signature schemes for "signature_algorithms" and > 65: // "signature_algorithms_cert" extensions > 66: String[] signatureSchemes; I would keep the typed list (get it from the parameters or system property cache). src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262: > 260: } // otherwise, use the default values > 261: > 262: String[] ss = params.getSignatureSchemes(); If we don?t use the cloning getter here (and use the pre-parsed list) it would be more efficient. src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 410: > 408: > 409: // Reset the signature schemes, if it was configured with SSLParameters. > 410: if (Arrays.equals(signatureSchemes, The duals here does not mean it was configure with parameters, it only means it is currently the same configuration as the parameters, but it still could be a different source? src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439: > 437: (config.signatureSchemes == null || > 438: config.signatureSchemes.length == 0 || > 439: Arrays.asList(config.signatureSchemes) Is that a allocation per handshake*availablesize? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Fri Jan 28 07:21:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 28 Jan 2022 07:21:56 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Copyright correction ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/c7537b16..822565d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=00-01 Stats: 24 lines in 4 files changed: 5 ins; 5 del; 14 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 Fri Jan 28 07:21:58 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 28 Jan 2022 07:21:58 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 23:43:51 GMT, Jie Fu wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright correction > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 3: > >> 1: /* >> 2: * Copyright (c) 2005, 2021, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved. > > No sure if we should add this new copyright line for Tencent. > > But for hotspot changes, we usually just update the copyright year from 2021 to 2022 if the original copyright is from Oracle. Thank you for catching this. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From dfuchs at openjdk.java.net Fri Jan 28 09:51:39 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 28 Jan 2022 09:51:39 GMT Subject: RFR: 8280868: LineBodyHandlerTest.java creates and discards too many clients Message-ID: Please find enclosed a simple test fix for: 8280868: LineBodyHandlerTest.java creates and discards too many clients The LineBodyHandlerTest.java creates and discards many clients (64). The test has been observed failing intermittently on some systems (Windows 10) while trying to open the client's selector, apparently due to some connection limit. It seems that using a single client reduces the occurrences in which the test fails. ------------- Commit messages: - 8280868: LineBodyHandlerTest.java creates and discards too many clients Changes: https://git.openjdk.java.net/jdk/pull/7263/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7263&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280868 Stats: 23 lines in 1 file changed: 19 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7263/head:pull/7263 PR: https://git.openjdk.java.net/jdk/pull/7263 From duke at openjdk.java.net Fri Jan 28 13:55:28 2022 From: duke at openjdk.java.net (Michael Felt) Date: Fri, 28 Jan 2022 13:55:28 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails Message-ID: with IP "0.0.0.0" - it either does nothing and ping fails, or, in some virtual environments is treated as the default route address. - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted as a vaild psuedo IPv6 address. '::1' must be used instead. ping: bind: The socket name is not available on this system. ping: bind: The socket name is not available on this system. PING ::1: (::1): 56 data bytes 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms --- ::1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms PING ::1: (::1): 56 data bytes 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms --- ::1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss A long commit message. This came to light because some systems failed with IPv4 (those that passed replaced 0.0.0.0 with the default router. but most just fail - not substituting 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 which compares well with other platform's behavior. ------------- Commit messages: - AIX: InetAddress.getByName(addr) does not work as expected with IP "0.0.0.0" Changes: https://git.openjdk.java.net/jdk/pull/7013/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7013&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280498 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7013.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7013/head:pull/7013 PR: https://git.openjdk.java.net/jdk/pull/7013 From stuefe at openjdk.java.net Fri Jan 28 13:55:29 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 28 Jan 2022 13:55:29 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:56:07 GMT, Michael Felt wrote: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. Hi @aixtools, Welcome! Good job with aixtools.net, we used it quite a bit over the years :) About your patch, probably it will be ignored in this form. Some notes: - you need an official JBS issue for the toolchain to notify relevant mailing lists. I can open one for you if you can give me a short concise bug text explaining the issue. - we have a ppc/aix mailing list. It's a bit deserted, but still a good place to ask around or notify ppl of your intent to patch. https://mail.openjdk.java.net/mailman/listinfo/ppc-aix-port-dev - and of course, we need you to sign the OCA. Officially, I think IBM is now maintainer of the AIX port (they took over from us, SAP). Are you affiliated with IBM? Cheers, Thomas I opened an issue for you to track this. [JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails ](https://bugs.openjdk.java.net/browse/JDK-8280498) Please change the title of this PR to "JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails" to allow our bots to make the connection. ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Fri Jan 28 13:55:30 2022 From: duke at openjdk.java.net (Michael Felt) Date: Fri, 28 Jan 2022 13:55:30 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> On Mon, 10 Jan 2022 15:56:07 GMT, Michael Felt wrote: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. I was affiliated with IBM. I am more affiliated with Adoptium (was OpenJDK) these days. However, as most of the work that IBM will be doing (that they took over from you) is hosted at the same location - I do assist IBM with the basic setup and config. The testing (and related PR's) comes from the testing done by Adoptium. On 18/01/2022 07:29, Thomas Stuefe wrote: > > Hi @aixtools , > > Welcome! Good job with aixtools.net, we used it quite a bit over the > years :) > a bit sad to see 'used' (past tense) - but very glad I could help. I hate, well, try VERY VERY hard to avoid, unneeded dependencies. I am told my work on github/cpython (helped) convinced IBM to use XLC as compiler for Python on AIX 7.3 - so that is a step forward (imho). > About your patch, probably it will be ignored in this form. Some notes: > > * you need an official JBS issue for the toolchain to notify > relevant mailing lists. I can open one for you if you can give me > a short concise bug text explaining the issue. > Would appreciate that: I'll get back on the consise text. Have to find my C program I used for testing the library call. From memory, an argument (""), i.e., null-length string behaves as expected for "0.0.0.0", whereas (NULL) does not (fails iirc), and "0.0.0.0" is taken as a valid address - that it fails to resolve. And, also, "::0" is simply refused (also by ping on CLI), so to get that to work as expected ping to "::1" - which has been available since 1997 (iirc, when AIX 4.3.0 was released with dual stack support (i.e., "::1" does not need `autoconf6` to be called to be available, it is always there). So, you conld consider it a bug that the AIX library does not properly handle NULL (as documented, iirc), and certainly an inconvience that "0.0.0.0" is not handled the same way by the library function - compared to the "ping" command (where some environments transform "0.0.0.0" to the IP of the default router. Not been able to figure out how that happens (or where) - but I think some routers might be responding to "0.0.0.0" as "here" as was stated in the ancient docs re: meaning of "0.0.0.0". If above is sufficient for the JBS issue - fantistic - otherwise I'll try and get something less chatty from code. > * we have a ppc/aix mailing list. It's a bit deserted, but still a > good place to ask around or notify ppl of your intent to patch. > https://mail.openjdk.java.net/mailman/listinfo/ppc-aix-port-dev > registering... > > * and of course, we need you to sign the OCA. > where is that? > > Officially, I think IBM is now maintainer of the AIX port (they took > over from us, SAP). Are you affiliated with IBM? > > Cheers, Thomas > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > Does the label being removed mean the site knows I now have an _oca_? ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From stuefe at openjdk.java.net Fri Jan 28 13:55:31 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 28 Jan 2022 13:55:31 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> References: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> Message-ID: On Thu, 20 Jan 2022 12:59:25 GMT, Michael Felt wrote: >If above is sufficient for the JBS issue - fantistic - otherwise I'll try and get something less chatty from code. That would be nice. >> * and of course, we need you to sign the OCA. > where is that? https://openjdk.java.net/contribute/ outlines the process. Point 0 is needed, signing the Oracle contributor agreement. Note that I am not affiliated with Oracle. It's what they require. ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From clanger at openjdk.java.net Fri Jan 28 13:55:32 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 28 Jan 2022 13:55:32 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> References: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> Message-ID: On Thu, 20 Jan 2022 12:59:25 GMT, Michael Felt wrote: >> with IP "0.0.0.0" >> >> - it either does nothing and ping fails, or, in some virtual environments >> is treated as the default route address. >> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted >> as a vaild psuedo IPv6 address. '::1' must be used instead. >> >> ping: bind: The socket name is not available on this system. >> ping: bind: The socket name is not available on this system. >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> round-trip min/avg/max = 0/0/0 ms >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> >> >> A long commit message. >> >> This came to light because some systems failed with IPv4 (those that passed >> replaced 0.0.0.0 with the default router. but most just fail - not substituting >> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 >> which compares well with other platform's behavior. > > I was affiliated with IBM. I am more affiliated with Adoptium (was > OpenJDK) these days. > > However, as most of the work that IBM will be doing (that they took over > from you) is hosted at the same location - I do assist IBM with the > basic setup and config. > > The testing (and related PR's) comes from the testing done by Adoptium. > > On 18/01/2022 07:29, Thomas Stuefe wrote: >> >> Hi @aixtools , >> >> Welcome! Good job with aixtools.net, we used it quite a bit over the >> years :) >> > a bit sad to see 'used' (past tense) - but very glad I could help. I > hate, well, try VERY VERY hard to avoid, unneeded dependencies. > > I am told my work on github/cpython (helped) convinced IBM to use XLC as > compiler for Python on AIX 7.3 - so that is a step forward (imho). > >> About your patch, probably it will be ignored in this form. Some notes: >> >> * you need an official JBS issue for the toolchain to notify >> relevant mailing lists. I can open one for you if you can give me >> a short concise bug text explaining the issue. >> > Would appreciate that: I'll get back on the consise text. Have to find > my C program I used for testing the library call. From memory, an > argument (""), i.e., null-length string behaves as expected for > "0.0.0.0", whereas (NULL) does not (fails iirc), and "0.0.0.0" is taken > as a valid address - that it fails to resolve. > > And, also, "::0" is simply refused (also by ping on CLI), so to get that > to work as expected ping to "::1" - which has been available since 1997 > (iirc, when AIX 4.3.0 was released with dual stack support (i.e., "::1" > does not need `autoconf6` to be called to be available, it is always there). > > So, you conld consider it a bug that the AIX library does not properly > handle NULL (as documented, iirc), and certainly an inconvience that > "0.0.0.0" is not handled the same way by the library function - compared > to the "ping" command (where some environments transform "0.0.0.0" to > the IP of the default router. Not been able to figure out how that > happens (or where) - but I think some routers might be responding to > "0.0.0.0" as "here" as was stated in the ancient docs re: meaning of > "0.0.0.0". > > If above is sufficient for the JBS issue - fantistic - otherwise I'll > try and get something less chatty from code. > >> * we have a ppc/aix mailing list. It's a bit deserted, but still a >> good place to ask around or notify ppl of your intent to patch. >> https://mail.openjdk.java.net/mailman/listinfo/ppc-aix-port-dev >> > registering... >> >> * and of course, we need you to sign the OCA. >> > where is that? >> >> Officially, I think IBM is now maintainer of the AIX port (they took >> over from us, SAP). Are you affiliated with IBM? >> >> Cheers, Thomas >> >> ? >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> . >> You are receiving this because you were mentioned.Message ID: >> ***@***.***> >> Hi, @aixtools, you will also first have to take care for the oca. Before that state isn't clear, none of the discussions on this PR will be forwarded to the mailing lists. ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From aixtools at felt.demon.nl Fri Jan 28 14:06:36 2022 From: aixtools at felt.demon.nl (Michael Felt) Date: Fri, 28 Jan 2022 15:06:36 +0100 Subject: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected In-Reply-To: References: <4cd329f0-766b-3f50-da29-c1908a0f1bd1@oracle.com> Message-ID: <054001d81450$43205040$c960f0c0$@felt.demon.nl> Hi, I went to the ticket you opened ? and it seems I need to do something additional ? as I cannot login to comment (should I need to). Thx again for opening the ticket. From: Thomas St?fe Sent: Saturday, 22 January 2022 11:23 To: Alan Bateman Cc: Michael Felt ; ppc-aix-port-dev ; net-dev Subject: Re: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected Redirecting to net-dev On Sat, Jan 22, 2022 at 11:00 AM Alan Bateman > wrote: On 22/01/2022 08:40, Thomas St?fe wrote: > Hi Micheal, > > welcome, and thank you for your contribution! > > I opened a bug id for you to track this: > https://bugs.openjdk.java.net/browse/JDK-8280498 . I can sponsor this patch > for you. > > You need one reviewer, I think. I don't have the cycles right now to think > this through. I cc core-libs dev since this is a networking issue and one > of their tests. > The networking tests are maintained on net-dev so if there is a PR then it should go to that list. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.java.net Fri Jan 28 14:33:12 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 28 Jan 2022 14:33:12 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> References: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> Message-ID: <4UxWytgdU0s7VJzhYCGfFmGcNbF6PSRMpzq_7XrkSFY=.57e7cdd1-3a80-4d27-ad01-ee9e3d07c4be@github.com> On Fri, 28 Jan 2022 13:52:12 GMT, Michael Felt wrote: > Does the label being removed mean the site knows I now have an _oca_? Yes. The oca label was removed by the bot. It also did sent the mail to the associated ML (https://mail.openjdk.java.net/pipermail/net-dev/2022-January/017386.html). You still have no write access to the JBS issue, because you need "authorship" for that. But the bar is pretty low (I believe three sponsored changes or so). Sorry for the complexity. It's all a tradeoff - attracting developers vs keeping noise down. As soon as someone reviews, I can sponsor the change. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From alanb at openjdk.java.net Fri Jan 28 14:33:12 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 28 Jan 2022 14:33:12 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:56:07 GMT, Michael Felt wrote: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. test/jdk/java/net/Inet4Address/PingThis.java line 62: > 60: else { > 61: addrs.add("0.0.0.0"); > 62: } This conflicts with the purpose of the test. Maybe this test needs to be skipped on AIX? ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From michaelm at openjdk.java.net Fri Jan 28 14:33:13 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 28 Jan 2022 14:33:13 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:28:43 GMT, Alan Bateman wrote: >> with IP "0.0.0.0" >> >> - it either does nothing and ping fails, or, in some virtual environments >> is treated as the default route address. >> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted >> as a vaild psuedo IPv6 address. '::1' must be used instead. >> >> ping: bind: The socket name is not available on this system. >> ping: bind: The socket name is not available on this system. >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> round-trip min/avg/max = 0/0/0 ms >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> >> >> A long commit message. >> >> This came to light because some systems failed with IPv4 (those that passed >> replaced 0.0.0.0 with the default router. but most just fail - not substituting >> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 >> which compares well with other platform's behavior. > > test/jdk/java/net/Inet4Address/PingThis.java line 62: > >> 60: else { >> 61: addrs.add("0.0.0.0"); >> 62: } > > This conflicts with the purpose of the test. Maybe this test needs to be skipped on AIX? Or is it possible to change the implementation on AIX so the test passes without change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Fri Jan 28 14:43:09 2022 From: duke at openjdk.java.net (Michael Felt) Date: Fri, 28 Jan 2022 14:43:09 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: <4UxWytgdU0s7VJzhYCGfFmGcNbF6PSRMpzq_7XrkSFY=.57e7cdd1-3a80-4d27-ad01-ee9e3d07c4be@github.com> References: <5SfqHOZdUC2evaCO5LGRcGfmyugfJWHVTJ1LjER86vI=.4e24890f-ce65-4c0e-8392-750fd4268c10@github.com> <4UxWytgdU0s7VJzhYCGfFmGcNbF6PSRMpzq_7XrkSFY=.57e7cdd1-3a80-4d27-ad01-ee9e3d07c4be@github.com> Message-ID: On Fri, 28 Jan 2022 14:26:51 GMT, Thomas Stuefe wrote: > > Does the label being removed mean the site knows I now have an _oca_? > > Yes. The oca label was removed by the bot. It also did sent the mail to the associated ML (https://mail.openjdk.java.net/pipermail/net-dev/2022-January/017386.html). > > You still have no write access to the JBS issue, because you need "authorship" for that. But the bar is pretty low (I believe three sponsored changes or so). > > Sorry for the complexity. It's all a tradeoff - attracting developers vs keeping noise down. Basically, it nearly kept from submitting anything at all. > > As soon as someone reviews, I can sponsor the change. Thx. > > Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Fri Jan 28 14:43:10 2022 From: duke at openjdk.java.net (Michael Felt) Date: Fri, 28 Jan 2022 14:43:10 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:30:01 GMT, Michael McMahon wrote: >> test/jdk/java/net/Inet4Address/PingThis.java line 62: >> >>> 60: else { >>> 61: addrs.add("0.0.0.0"); >>> 62: } >> >> This conflicts with the purpose of the test. Maybe this test needs to be skipped on AIX? > > Or is it possible to change the implementation on AIX so the test passes without change? If it defeats the purpose, then it needs to be skipped. * When I was trying to understand the test, it seemed to be that it _assumed_ that "0.0.0.0" was 'converted' to 127.0.0.1. * If there is an international standard (ISO, POSIX) that states 0.0.0.0 needs to be treated as 127.0.0.1 - AIX clearly has a bug. Same for `::)` mapping to `::1` - AIX doesn't do that IPv4 (now), and, afaik, never has for IPv6. * While testing I also saw that AIX reacts differently (error message iirc) when passed NULL, whereas it behaves "as expected" when given a null-string `""` * FYI: Adoptium has put this test on the excluded list, but if a fix using `""` rather than "0.0.0.0" and/or "::1" rather than "::0", the test should perhaps state the exclusion as a comment in the code, and return immediately, as it does for Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Fri Jan 28 14:50:11 2022 From: duke at openjdk.java.net (Michael Felt) Date: Fri, 28 Jan 2022 14:50:11 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:37:00 GMT, Michael Felt wrote: >> Or is it possible to change the implementation on AIX so the test passes without change? > > If it defeats the purpose, then it needs to be skipped. > > * When I was trying to understand the test, it seemed to be that it _assumed_ that "0.0.0.0" was 'converted' to 127.0.0.1. > * If there is an international standard (ISO, POSIX) that states 0.0.0.0 needs to be treated as 127.0.0.1 - AIX clearly has a bug. Same for `::)` mapping to `::1` - AIX doesn't do that IPv4 (now), and, afaik, never has for IPv6. > * While testing I also saw that AIX reacts differently (error message iirc) when passed NULL, whereas it behaves "as expected" when given a null-string `""` > * FYI: Adoptium has put this test on the excluded list, but if a fix using `""` rather than "0.0.0.0" and/or "::1" rather than "::0", the test should perhaps state the exclusion as a comment in the code, and return immediately, as it does for Windows. > Or is it possible to change the implementation on AIX so the test passes without change? * Digging into the java guts to map "0.0.0.0" to "127.0.0.1" seems too far to me - as I believe interfaces are not suppossed to be "translating" as well. * If the behavior "0.0.0.0" becomes "127.0.0.1" is an official standard - a bug needs to be filed with IBM (which I cannot do) - but we need to also be aware that any fix to AIX is not likely to ever be applied on AIX 7.1 TL4 (maybe TL5) which are systems used to build distributions. * Again - being a noob (or fresh face; fresh meat) the test title is merely "PingThis" - where is "This" defined as "0.0.0.0" (if it had been named _PingHERE_ I could understand as the alias, iirc, for 0.0.0.0 is "Here". ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From michaelm at openjdk.java.net Fri Jan 28 15:14:14 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 28 Jan 2022 15:14:14 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:46:32 GMT, Michael Felt wrote: >> If it defeats the purpose, then it needs to be skipped. >> >> * When I was trying to understand the test, it seemed to be that it _assumed_ that "0.0.0.0" was 'converted' to 127.0.0.1. >> * If there is an international standard (ISO, POSIX) that states 0.0.0.0 needs to be treated as 127.0.0.1 - AIX clearly has a bug. Same for `::)` mapping to `::1` - AIX doesn't do that IPv4 (now), and, afaik, never has for IPv6. >> * While testing I also saw that AIX reacts differently (error message iirc) when passed NULL, whereas it behaves "as expected" when given a null-string `""` >> * FYI: Adoptium has put this test on the excluded list, but if a fix using `""` rather than "0.0.0.0" and/or "::1" rather than "::0", the test should perhaps state the exclusion as a comment in the code, and return immediately, as it does for Windows. > >> Or is it possible to change the implementation on AIX so the test passes without change? > > * Digging into the java guts to map "0.0.0.0" to "127.0.0.1" seems too far to me - as I believe interfaces are not suppossed to be "translating" as well. > * If the behavior "0.0.0.0" becomes "127.0.0.1" is an official standard - a bug needs to be filed with IBM (which I cannot do) - but we need to also be aware that any fix to AIX is not likely to ever be applied on AIX 7.1 TL4 (maybe TL5) which are systems used to build distributions. > * Again - being a noob (or fresh face; fresh meat) the test title is merely "PingThis" - where is "This" defined as "0.0.0.0" (if it had been named _PingHERE_ I could understand as the alias, iirc, for 0.0.0.0 is "Here". Might be better to skip the test then by adding to the header: * * @requires os.family != "aix" * rather than the check in the test source ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From dfuchs at openjdk.java.net Fri Jan 28 15:18:13 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 28 Jan 2022 15:18:13 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: <5y5gwE0TSqocIcNHMJ5eAv1ide0nprgLWAujlQUqqfI=.bd904290-6d89-47d9-87c4-90c4d9983af1@github.com> On Fri, 28 Jan 2022 15:11:04 GMT, Michael McMahon wrote: >>> Or is it possible to change the implementation on AIX so the test passes without change? >> >> * Digging into the java guts to map "0.0.0.0" to "127.0.0.1" seems too far to me - as I believe interfaces are not suppossed to be "translating" as well. >> * If the behavior "0.0.0.0" becomes "127.0.0.1" is an official standard - a bug needs to be filed with IBM (which I cannot do) - but we need to also be aware that any fix to AIX is not likely to ever be applied on AIX 7.1 TL4 (maybe TL5) which are systems used to build distributions. >> * Again - being a noob (or fresh face; fresh meat) the test title is merely "PingThis" - where is "This" defined as "0.0.0.0" (if it had been named _PingHERE_ I could understand as the alias, iirc, for 0.0.0.0 is "Here". > > Might be better to skip the test then by adding to the header: > > * > * @requires os.family != "aix" > * > rather than the check in the test source >From the description and evaluation of [JDK-7163874](https://bugs.openjdk.java.net/browse/JDK-7163874) it seems that skipping this test on AIX would be reasonable. Some operating systems seem to accept 0.0.0.0 as input - and reply with 127.0.0.1. The changes made for JDK-7163874 simply makes sure that such a reply is not rejected as invalid on the ground that the received address is not the same as the input address. If 0.0.0.0 is not a valid input for the underlying operating system, then the test has no object and should probably be skipped. ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From aixtools at felt.demon.nl Fri Jan 28 15:20:10 2022 From: aixtools at felt.demon.nl (Michael Felt) Date: Fri, 28 Jan 2022 16:20:10 +0100 Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: <05a101d8145a$8a189a70$9e49cf50$@felt.demon.nl> -----Original Message----- From: net-dev On Behalf Of Michael McMahon Sent: Friday, 28 January 2022 16:14 To: net-dev at openjdk.java.net Subject: Re: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails On Fri, 28 Jan 2022 14:46:32 GMT, Michael Felt wrote: >> If it defeats the purpose, then it needs to be skipped. >> >> * When I was trying to understand the test, it seemed to be that it _assumed_ that "0.0.0.0" was 'converted' to 127.0.0.1. >> * If there is an international standard (ISO, POSIX) that states 0.0.0.0 needs to be treated as 127.0.0.1 - AIX clearly has a bug. Same for `::)` mapping to `::1` - AIX doesn't do that IPv4 (now), and, afaik, never has for IPv6. >> * While testing I also saw that AIX reacts differently (error message iirc) when passed NULL, whereas it behaves "as expected" when given a null-string `""` >> * FYI: Adoptium has put this test on the excluded list, but if a fix using `""` rather than "0.0.0.0" and/or "::1" rather than "::0", the test should perhaps state the exclusion as a comment in the code, and return immediately, as it does for Windows. > >> Or is it possible to change the implementation on AIX so the test passes without change? > > * Digging into the java guts to map "0.0.0.0" to "127.0.0.1" seems too far to me - as I believe interfaces are not suppossed to be "translating" as well. > * If the behavior "0.0.0.0" becomes "127.0.0.1" is an official standard - a bug needs to be filed with IBM (which I cannot do) - but we need to also be aware that any fix to AIX is not likely to ever be applied on AIX 7.1 TL4 (maybe TL5) which are systems used to build distributions. > * Again - being a noob (or fresh face; fresh meat) the test title is merely "PingThis" - where is "This" defined as "0.0.0.0" (if it had been named _PingHERE_ I could understand as the alias, iirc, for 0.0.0.0 is "Here". Might be better to skip the test then by adding to the header: * * @requires os.family != "aix" * rather than the check in the test source And maybe remove this: ``` if (System.getProperty("os.name").startsWith("Windows")) { return; } ``` And also state in header something similar for Windows. a) consistency b) a change is required to be pushed (and back-ported :please: either way ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From mullan at openjdk.java.net Fri Jan 28 15:34:15 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 28 Jan 2022 15:34:15 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 07:21:56 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 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Copyright correction src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 94: > 92: > 93: /** > 94: * Constructs SSLParameters. Would it be useful to add another ctor that takes a signature schemes array parameter? src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 709: > 707: * "{@docRoot}/../specs/security/standard-names.html#signature-schemes"> > 708: * Signature Schemes section of the Java Cryptography > 709: * Architecture Standard Algorithm Name Documentation, and may also The correct name is "Java Security Standard Algorithm Names Specification". Same comment below for `setSignatureSchemes`. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710: > 708: * Signature Schemes section of the Java Cryptography > 709: * Architecture Standard Algorithm Name Documentation, and may also > 710: * include other signature schemes that the provider supports. There doesn't seem to be anything preventing a user from setting a bogus signature scheme (ex: named "foo") - which is neither a standard name or a provider specific name. I think the method may be too tightly specified, and you should make this more general and not put any constraints on the names of the signature schemes. (Although we should still link to the specification for a list of standard names). It would be useful to explain when this method returns pre-populated scheme names as supported by the underlying provider and when it may return an empty list. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 746: > 744: * @param signatureSchemes an ordered array of signature scheme names, > 745: * with the first entry being the most preferred. If the array > 746: * is empty (zero-length), the prodiver-specific default signature typo: prodiver -> provider ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From duke at openjdk.java.net Fri Jan 28 15:46:14 2022 From: duke at openjdk.java.net (Michael Felt) Date: Fri, 28 Jan 2022 15:46:14 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:56:07 GMT, Michael Felt wrote: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. From: Daniel Fuchs ***@***.***> Sent: Friday, 28 January 2022 16:15 To: openjdk/jdk ***@***.***> Cc: Michael Felt ***@***.***>; Mention ***@***.***> Subject: Re: [openjdk/jdk] JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails (PR #7013) @dfuch commented on this pull request. _____ In test/jdk/java/net/Inet4Address/PingThis.java : > IPSupport.throwSkippedExceptionIfNonOperational(); List addrs = new ArrayList(); if (IPSupport.hasIPv4()) { - addrs.add("0.0.0.0"); + if (isAIX) { + addrs.add(""); + } + else { + addrs.add("0.0.0.0"); + } >From the description and evaluation of JDK-7163874 it seems that skipping this test on AIX would be reasonable. Some operating systems seem to accept 0.0.0.0 as input - and reply with 127.0.0.1. The changes made for JDK-7163874 simply makes sure that such a reply is not rejected as invalid on the ground that the received address is not the same as the input address. If 0.0.0.0 is not a valid input for the underlying operating system, then the test has no object and should probably be skipped. I had read these comments ? an important comment was: https://bugs.openjdk.java.net/browse/JDK-7163874?focusedCommentId=12164566 &page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12164566, Alan Bateman added a comment - 2012-04-24 08:31 BT2:EVALUATION This isn't really a bug and highly platform specific if the native ping command can ping this address. * So ? personally, I am fine with skipping the test ? if it is not doing what it was designed to do. However, I would also consider changing the name of the test. * Again, head spinning again: the ticket mentioned says InetAddress.isReachable should support ping 0.0.0.0. IMHO: if that is an architectural (design) issue ? that is true ? THEN ? the code for isReachable() needs to account for platform differences. * However, if the architecture (design) states that isReachable() (not the test) is platform specific then there is a argument for simply excluding the test (as a known issue for future queries) in, e.g., ci-pipelines such as: https://github.com/adoptium/ci-jenkins-pipelines * I am also happy with that ? I just did not want to take a ?flight? reaction and skip it because it was not convenient to include it. ? Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you were mentioned.Message ID: ***@***.***> ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From mullan at openjdk.java.net Fri Jan 28 15:48:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 28 Jan 2022 15:48:12 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:17:28 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright correction > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710: > >> 708: * Signature Schemes section of the Java Cryptography >> 709: * Architecture Standard Algorithm Name Documentation, and may also >> 710: * include other signature schemes that the provider supports. > > There doesn't seem to be anything preventing a user from setting a bogus signature scheme (ex: named "foo") - which is neither a standard name or a provider specific name. > I think the method may be too tightly specified, and you should make this more general and not put any constraints on the names of the signature schemes. (Although we should still link to the specification for a list of standard names). > > It would be useful to explain when this method returns pre-populated scheme names as supported by the underlying provider and when it may return an empty list. You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From jnimeh at openjdk.java.net Fri Jan 28 15:54:15 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Fri, 28 Jan 2022 15:54:15 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:44:16 GMT, Sean Mullan wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710: >> >>> 708: * Signature Schemes section of the Java Cryptography >>> 709: * Architecture Standard Algorithm Name Documentation, and may also >>> 710: * include other signature schemes that the provider supports. >> >> There doesn't seem to be anything preventing a user from setting a bogus signature scheme (ex: named "foo") - which is neither a standard name or a provider specific name. >> I think the method may be too tightly specified, and you should make this more general and not put any constraints on the names of the signature schemes. (Although we should still link to the specification for a list of standard names). >> >> It would be useful to explain when this method returns pre-populated scheme names as supported by the underlying provider and when it may return an empty list. > > You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider? I asked a similar question about the System property interaction in the CSR and he has some answers there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From duke at openjdk.java.net Fri Jan 28 15:55:11 2022 From: duke at openjdk.java.net (Michael Felt) Date: Fri, 28 Jan 2022 15:55:11 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:56:07 GMT, Michael Felt wrote: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. p.s. Just want to be clear: On AIX - ping 0.0.0.0 is permissible, but responds differently - ping ::0 is not supported aixtools at x064:[/home/aixtools]ping 0.0.0.0 PING 0.0.0.0: (0.0.0.0): 56 data bytes --- 0.0.0.0 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss aixtools at x064:[/home/aixtools]ping ::0 ping: bind: The socket name is not available on this system. aixtools at x064:[/home/aixtools]ping ::1 PING ::1: (::1): 56 data bytes 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.053 ms 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.095 ms --- ::1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss and aixtools at gcc119:[/home/aixtools]ping 0.0.0.0 PING 0.0.0.0: (0.0.0.0): 56 data bytes 64 bytes from XXX.211.9.1: icmp_seq=0 ttl=255 time=0 ms 64 bytes from XXX.211.9.1: icmp_seq=1 ttl=255 time=0 ms 64 bytes from XXX.211.9.1: icmp_seq=2 ttl=255 time=0 ms --- 0.0.0.0 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms aixtools at gcc119:[/home/aixtools]ping ::0 ping: bind: The socket name is not available on this system. aixtools at gcc119:[/home/aixtools]ping ::1 PING ::1: (::1): 56 data bytes 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.045 ms 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.080 ms --- ::1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms _(Modified the responding IP address in the ping above)_ ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From michaelm at openjdk.java.net Fri Jan 28 16:58:55 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 28 Jan 2022 16:58:55 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v13] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: spec update from CSR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/59f703da..468e5345 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=11-12 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 28 17:24:22 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 28 Jan 2022 17:24:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v13] In-Reply-To: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> Message-ID: On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > spec update from CSR Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From xuelei at openjdk.java.net Fri Jan 28 18:33:11 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 28 Jan 2022 18:33:11 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:17:25 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright correction > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 709: > >> 707: * "{@docRoot}/../specs/security/standard-names.html#signature-schemes"> >> 708: * Signature Schemes section of the Java Cryptography >> 709: * Architecture Standard Algorithm Name Documentation, and may also > > The correct name is "Java Security Standard Algorithm Names Specification". Same comment below for `setSignatureSchemes`. Good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Fri Jan 28 19:53:13 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 28 Jan 2022 19:53:13 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:50:49 GMT, Jamil Nimeh wrote: >> You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider? > > I asked a similar question about the System property interaction in the CSR and he has some answers there. All good catches, Sean and Jamil. I updated the CSR accordingly, and will update the PR after I complete other comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Sat Jan 29 05:30:11 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 29 Jan 2022 05:30:11 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 00:54:53 GMT, Bernd wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright correction > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 92: > >> 90: private int maximumPacketSize = 0; >> 91: private String[] applicationProtocols = new String[0]; >> 92: private String[] signatureSchemes = new String[0]; > > There are some places in here which could use a local or global static EMPTY = new String[0]` value. That would be safe to share and reduces allocations (they surely escape). Good point. I will make the update. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 745: > >> 743: * This method will make a copy of the {@code signatureSchemes} array. >> 744: * >> 745: * @param signatureSchemes an ordered array of signature scheme names, > > Should it mention that unknown schemes are ignored and not trigger a exception? Good catch! I missed that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Sat Jan 29 05:30:11 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 29 Jan 2022 05:30:11 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:26:56 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright correction > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 94: > >> 92: >> 93: /** >> 94: * Constructs SSLParameters. > > Would it be useful to add another ctor that takes a signature schemes array parameter? As there is increasing number of SSL parameters, applications may just use the constructor with no argument, and use the set methods individually. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Sat Jan 29 05:38:10 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 29 Jan 2022 05:38:10 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 00:58:37 GMT, Bernd wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright correction > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763: > >> 761: >> 762: String[] tempSchemes = signatureSchemes.clone(); >> 763: for (String scheme : tempSchemes) { > > In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused) If we want to reuse the result, we may have to cache something. It is not good to me. The parsing of the signature scheme names actually depends on the provider. So at this point, in the Java SE API specification, it is not easy to know how to parse the strings to me. > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 66: > >> 64: // The configured signature schemes for "signature_algorithms" and >> 65: // "signature_algorithms_cert" extensions >> 66: String[] signatureSchemes; > > I would keep the typed list (get it from the parameters or system property cache). I see your point. There is a tricky question that it would be nice to return (SSLParameters.getXXX()) to what it has been set (SSLParameters.setXXX()). If the typed list get kept, it means that unknown names would filtered out, and the get method cannot return the property values. > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262: > >> 260: } // otherwise, use the default values >> 261: >> 262: String[] ss = params.getSignatureSchemes(); > > If we don?t use the cloning getter here (and use the pre-parsed list) it would be more efficient. Yes. Array copy is a concern of mine, too. Hopefully, the frozen array feature could help address the array copy issues in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Sat Jan 29 05:51:04 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 29 Jan 2022 05:51:04 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v3] 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Enrich the APIs specification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/822565d5..53d4db9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=01-02 Stats: 44 lines in 1 file changed: 26 ins; 1 del; 17 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 Sat Jan 29 05:51:04 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 29 Jan 2022 05:51:04 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 01:05:22 GMT, Bernd wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Enrich the APIs specification > > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 410: > >> 408: >> 409: // Reset the signature schemes, if it was configured with SSLParameters. >> 410: if (Arrays.equals(signatureSchemes, > > The duals here does not mean it was configure with parameters, it only means it is currently the same configuration as the parameters, but it still could be a different source? You are right. Toggle client mode is a pretty hard to implement method to me, especially considering the impact of various SSL parameters. There are more than one method to set the parameters, as make it hard to know what an application really want to do. Here is a best effort I can think of, but not really an accurate implementation. Hopefully, the impact is minimal. > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439: > >> 437: (config.signatureSchemes == null || >> 438: config.signatureSchemes.length == 0 || >> 439: Arrays.asList(config.signatureSchemes) > > Is that a allocation per handshake*availablesize? Yes, it does. Do you like to use a for-loop, without new object allocation? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From aturbanov at openjdk.java.net Sat Jan 29 11:39:13 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sat, 29 Jan 2022 11:39:13 GMT Subject: Integrated: 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:11:36 GMT, Andrey Turbanov wrote: > All this manually written code actually can be replaced with single String.isBlank() call. > `file` variable is guaranteed to be non-null. This pull request has now been integrated. Changeset: 268880b4 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/268880b471eed54535927fba953347160f447fcd Stats: 26 lines in 1 file changed: 0 ins; 21 del; 5 mod 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/6372 From xuelei at openjdk.java.net Sat Jan 29 18:56:57 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 29 Jan 2022 18:56:57 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v4] 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Checke blank strings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/53d4db9e..0000922f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 duke at openjdk.java.net Sun Jan 30 03:11:12 2022 From: duke at openjdk.java.net (Bernd) Date: Sun, 30 Jan 2022 03:11:12 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v4] In-Reply-To: References: Message-ID: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com> On Sat, 29 Jan 2022 05:31:08 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763: >> >>> 761: >>> 762: String[] tempSchemes = signatureSchemes.clone(); >>> 763: for (String scheme : tempSchemes) { >> >> In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused) > > If we want to reuse the result, we may have to cache something. It is not good to me. The parsing of the signature scheme names actually depends on the provider. So at this point, in the Java SE API specification, it is not easy to know how to parse the strings to me. Yes you are right, it would require a setter where the provider can register the resolved array into the parameter instance (if we need to support multiple providers). But it would be a good optimization assuming clients keep the parameters around in a frequent Connection scenario. >> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262: >> >>> 260: } // otherwise, use the default values >>> 261: >>> 262: String[] ss = params.getSignatureSchemes(); >> >> If we don?t use the cloning getter here (and use the pre-parsed list) it would be more efficient. > > Yes. Array copy is a concern of mine, too. Hopefully, the frozen array feature could help address the array copy issues in the future. Hmm.. I guess the different packages make it really hard to have an internal optimized getter. What about a single concatenated string, it would be immutable ?sig1,sig2?.. >> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439: >> >>> 437: (config.signatureSchemes == null || >>> 438: config.signatureSchemes.length == 0 || >>> 439: Arrays.asList(config.signatureSchemes) >> >> Is that a allocation per handshake*availablesize? > > Yes, it does. Do you like to use a for-loop, without new object allocation? Yes, static helper ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Sun Jan 30 07:33:52 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 30 Jan 2022 07:33:52 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v5] 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Less objects construction ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/0000922f..b8ed2506 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=03-04 Stats: 13 lines in 2 files changed: 10 ins; 1 del; 2 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 Jan 30 07:39:10 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 30 Jan 2022 07:39:10 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v5] In-Reply-To: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com> References: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com> Message-ID: On Sun, 30 Jan 2022 03:03:37 GMT, Bernd wrote: >> If we want to reuse the result, we may have to cache something. It is not good to me. The parsing of the signature scheme names actually depends on the provider. So at this point, in the Java SE API specification, it is not easy to know how to parse the strings to me. > > Yes you are right, it would require a setter where the provider can register the resolved array into the parameter instance (if we need to support multiple providers). But it would be a good optimization assuming clients keep the parameters around in a frequent Connection scenario. I see your point. The API default implementation could be complicated, if considering loading and unloading providers at runtime. I agree with you about the potential performance impact (minimal, but we may want to optimizing), and let's see if we could have a solution later. Since it is a common issue, I will not address it in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Sun Jan 30 07:43:07 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 30 Jan 2022 07:43:07 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v5] In-Reply-To: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com> References: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com> Message-ID: <-FIxZLPhl80oVo0PC6X2XenAvYPxbWwUPMo4oNCVrp4=.756b3461-6258-4ca5-bad1-31d9f000ddf2@github.com> On Sun, 30 Jan 2022 03:06:35 GMT, Bernd wrote: >> Yes. Array copy is a concern of mine, too. Hopefully, the frozen array feature could help address the array copy issues in the future. > > Hmm.. I guess the different packages make it really hard to have an internal optimized getter. What about a single concatenated string, it would be immutable ?sig1,sig2?.. It's an interesting idea. I would like to choose simple API, in an affordable performance impact. I don't worry a lot if considering the frozen array enhancement. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From aturbanov at openjdk.java.net Mon Jan 31 12:16:16 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 31 Jan 2022 12:16:16 GMT Subject: Integrated: 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:35:10 GMT, Andrey Turbanov wrote: > All this Handler's are stateless and there is nothing to protect via synchronization. This pull request has now been integrated. Changeset: c6ed2046 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/c6ed2046b4ba8eafb6b7e934b134829760d56ecd Stats: 31 lines in 3 files changed: 0 ins; 22 del; 9 mod 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/6373 From xuelei at openjdk.java.net Mon Jan 31 15:19:02 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 15:19:02 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v6] In-Reply-To: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com> References: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com> Message-ID: On Sun, 30 Jan 2022 03:08:22 GMT, Bernd wrote: >> Yes, it does. Do you like to use a for-loop, without new object allocation? > > Yes, static helper Thanks for confirm. Updated to use a static helper method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Mon Jan 31 15:19:01 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 15:19:01 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v6] 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 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/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/b8ed2506..0d3c52dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Mon Jan 31 15:43:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 15:43:43 GMT Subject: RFR: 8280949: Correct the references for the Java Security Standard Algorithm Names specification Message-ID: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation". As should be corrected. ------------- Commit messages: - 8280949: Correct the references for the Java Security Standard Algorithm Names specification Changes: https://git.openjdk.java.net/jdk/pull/7290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7290&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280949 Stats: 55 lines in 6 files changed: 0 ins; 0 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/7290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7290/head:pull/7290 PR: https://git.openjdk.java.net/jdk/pull/7290 From xuelei at openjdk.java.net Mon Jan 31 16:01:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 16:01:56 GMT Subject: RFR: 8280949: Correct the references for the Java Security Standard Algorithm Names specification [v2] In-Reply-To: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> Message-ID: <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com> > In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation". As should be corrected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Update the copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7290/files - new: https://git.openjdk.java.net/jdk/pull/7290/files/96b3e528..9f75163b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7290&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7290&range=00-01 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7290/head:pull/7290 PR: https://git.openjdk.java.net/jdk/pull/7290 From mullan at openjdk.java.net Mon Jan 31 16:43:17 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 31 Jan 2022 16:43:17 GMT Subject: RFR: 8280949: Correct the references for the Java Security Standard Algorithm Names specification [v2] In-Reply-To: <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com> References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com> Message-ID: On Mon, 31 Jan 2022 16:01:56 GMT, Xue-Lei Andrew Fan wrote: >> In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation". As should be corrected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Update the copyright years Please capitalize "specification" (i.e. "Specification") to be consistent with other references in the javadoc. Looks good otherwise. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7290 From xuelei at openjdk.java.net Mon Jan 31 19:23:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 19:23:56 GMT Subject: RFR: 8280949: Correct the references for the Java Security Standard Algorithm Names specification [v3] In-Reply-To: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> Message-ID: <7KfgId9VMKq7zDfm96IDwGBWVpgTZe__qBXvvBx9Ffw=.731771c0-2ec4-4654-a931-4ca4f25724fd@github.com> > In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation". As should be corrected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Use capital S ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7290/files - new: https://git.openjdk.java.net/jdk/pull/7290/files/9f75163b..d5792cee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7290&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7290&range=01-02 Stats: 17 lines in 6 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7290/head:pull/7290 PR: https://git.openjdk.java.net/jdk/pull/7290 From xuelei at openjdk.java.net Mon Jan 31 19:23:57 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 19:23:57 GMT Subject: RFR: 8280949: Correct the references for the Java Security Standard Algorithm Names specification [v2] In-Reply-To: References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com> Message-ID: On Mon, 31 Jan 2022 16:39:34 GMT, Sean Mullan wrote: > Please capitalize "specification" (i.e. "Specification") to be consistent with other references in the javadoc. Looks good otherwise. OK. Just curious, why we want to use capitalized "specification"? This word "specification" is not a part of the document title. ------------- PR: https://git.openjdk.java.net/jdk/pull/7290 From mullan at openjdk.java.net Mon Jan 31 20:09:09 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 31 Jan 2022 20:09:09 GMT Subject: RFR: 8280949: Correct the references for the Java Security Standard Algorithm Names specification [v2] In-Reply-To: References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com> Message-ID: On Mon, 31 Jan 2022 19:19:28 GMT, Xue-Lei Andrew Fan wrote: > > Please capitalize "specification" (i.e. "Specification") to be consistent with other references in the javadoc. Looks good otherwise. > > OK. Just curious, why we want to use capitalized "specification"? This word "specification" is not a part of the document title. True (although in hindsight we could have added it to the title). However, I think capitalizing when referencing it signifies that it is an important and normative document, similar to when you refer to standard documents even if it is not in title (ex: "The AES Standard"). If we referred to it again in subsequent text, then it is not as necessary, i.e. you could say "This specification includes list of names that are defined as standard ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7290 From xuelei at openjdk.java.net Mon Jan 31 20:20:10 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 20:20:10 GMT Subject: RFR: 8280949: Correct the references for the Java Security Standard Algorithm Names specification [v2] In-Reply-To: References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com> Message-ID: On Mon, 31 Jan 2022 20:05:45 GMT, Sean Mullan wrote: > > > Please capitalize "specification" (i.e. "Specification") to be consistent with other references in the javadoc. Looks good otherwise. > > > > > > OK. Just curious, why we want to use capitalized "specification"? This word "specification" is not a part of the document title. > > True (although in hindsight we could have added it to the title). However, I think capitalizing when referencing it signifies that it is an important and normative document, similar to when you refer to standard documents even if it is not in title (ex: "The AES Standard"). If we referred to it again in subsequent text, then it is not as necessary, i.e. you could say "This specification includes list of names that are defined as standard ... Good point! Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/7290 From xuelei at openjdk.java.net Mon Jan 31 20:24:47 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 20:24:47 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v7] 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Rollback to use captialized S ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/0d3c52dd..dfcb7f7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Mon Jan 31 20:29:12 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 31 Jan 2022 20:29:12 GMT Subject: Integrated: 8280949: Correct the references for the Java Security Standard Algorithm Names specification In-Reply-To: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com> Message-ID: On Mon, 31 Jan 2022 15:37:38 GMT, Xue-Lei Andrew Fan wrote: > In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation". As should be corrected. This pull request has now been integrated. Changeset: f991891b Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/f991891b0ba7a3767d2abd85ab9b2d284dc3d013 Stats: 61 lines in 6 files changed: 0 ins; 0 del; 61 mod 8280949: Correct the references for the Java Security Standard Algorithm Names specification Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/7290 From mullan at openjdk.java.net Mon Jan 31 22:06:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 31 Jan 2022 22:06:12 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v7] In-Reply-To: References: Message-ID: On Mon, 31 Jan 2022 20:24:47 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 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Rollback to use captialized S A few more comments on the API. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 727: > 725: * Note that the underlying provider may define the default signature > 726: * schemes for each SSL/TLS/DTLS connection. Applications may also use > 727: * System Property, "jdk.tls.client.SignatureSchemes" and/or Use the javadoc annotation @systemProperty when referring to the system properties. Look at other code for examples. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 734: > 732: * pre-populated objects. > 733: * > 734: * @return a non-null, possibly zero-length array of signature scheme The other methods that return arrays like `getCipherSuites` and `getProtocols` return `null` if none have been set. While one could argue whether returning `null` or an empty array is better, there is already a precedent in this API of returning `null`, and with this API programmers will have to check for two different ways of checking for parameters that are not set. I'm not really sure if the inconsistency is worth it. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 765: > 763: * System Property, "jdk.tls.client.SignatureSchemes" and/or > 764: * "jdk.tls.server.SignatureSchemes", to customize the provider-specific > 765: * default signature schemes. If the {@code signatureSchemes} array is In this sentence does `signatureSchemes` mean the "*.SignatureSchemes" property or the `signatureSchemes` parameter? I don't think I understand this sentence. I think you should explain when the system property overrides the parameter in this API, and/or vice-versa. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 774: > 772: * is empty (zero-length), the provider-specific default signature > 773: * schemes will be used for the SSL/TLS/DTLS connection. > 774: * @throws IllegalArgumentException if signatureSchemes is null, or if The other methods that accept arrays like `setCipherSuites` and `setProtocols` accept `null` as a parameter. Like my previous comment, it seems more important to keep this behavior consistent in the API and allow `null` as an acceptable value, which is also useful for clearing the current value of the parameter. ------------- Changes requested by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7252 From mullan at openjdk.java.net Mon Jan 31 22:06:13 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 31 Jan 2022 22:06:13 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: On Sat, 29 Jan 2022 05:26:33 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 94: >> >>> 92: >>> 93: /** >>> 94: * Constructs SSLParameters. >> >> Would it be useful to add another ctor that takes a signature schemes array parameter? > > As there is increasing number of SSL parameters, applications may just use the constructor with no argument, and use the set methods individually. Ok. You should specify what the default value of the signature schemes parameter is for this constructor as it does for the other parameters. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252