[jdk18] Integrated: 8280441: Missing "classpath exception" in several files from jdk.httpserver
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
RE: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected
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 mailto:alan.bate...@oracle.com> > 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
Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build
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
Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build
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
Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build
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
Re: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2]
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]
> 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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5]
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]
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
RFR: 8277969: HttpClient SelectorManager shuts down when custom Executor rejects a task
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
Re: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2]
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
Re: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2]
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4]
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]
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
Re: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v2]
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
Re: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v3]
> 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
Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build
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
Re: RFR: JDK-8280492: Use cross-module syntax for cross-module links
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]
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
RFR: Merge jdk18
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
Re: RFR: JDK-8280492: Use cross-module syntax for cross-module links [v2]
> 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
Integrated: JDK-8280492: Use cross-module syntax for cross-module links
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
Re: RFR: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC [v3]
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
Integrated: Merge jdk18
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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7]
> 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
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7]
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: "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: "never". This is also the default value if the property
> is not set. In this case,
> 223: CBT's are never sent.
> 224: "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
