Re: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v6]
> 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
Re: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v4]
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
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
Re: RFR: 8276166: Remove dead code from MimeTable and MimeEntry
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
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
Re: RFR: 8276166: Remove dead code from MimeTable and MimeEntry
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
RFR: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
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
Re: RFR: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2]
> 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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2]
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
RFR: Merge jdk18
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
Integrated: Merge jdk18
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
RFR: 8280363: Minor correction of ALPN specification in SSLParameters
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
