From michaelm at openjdk.java.net  Mon Nov  1 11:18:20 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 1 Nov 2021 11:18:20 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v10]
In-Reply-To: <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>
Message-ID: <zFQdI_W3RlEIxdekYWc84lZvO0uTNWntN2YMT4oW9cI=.07cac66e-a302-4edc-815a-1af36b114730@github.com>

On Fri, 29 Oct 2021 16:17:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace 'system' with 'the system-wide', move comment section

Marked as reviewed by michaelm (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From mcimadamore at openjdk.java.net  Mon Nov  1 12:05:32 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 1 Nov 2021 12:05:32 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v10]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Add cache for memory address var handles
 - Merge branch 'master' into JEP-419
 - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm)
 - Merge branch 'master' into JEP-419
 - Fix copyright header in TestArrayCopy
 - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)
 - * use `invokeWithArguments` to simplify new test
 - Add test for liveness check with high-aririty downcalls
   (make sure that if an exception occurs in a downcall because of liveness,
   ref count of other resources are left intact).
 - * Fix javadoc issue in VaList
   * Fix bug in concurrent logic for shared scope acquire
 - Address review comments
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5907/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=09
  Stats: 14497 lines in 189 files changed: 6773 ins; 5149 del; 2575 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From duke at openjdk.java.net  Mon Nov  1 14:13:43 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Nov 2021 14:13:43 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v4]
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <kTfOIwOrqA17OL83gtmWuogdMirqEcLTwH5nFjUKQAw=.e3534a30-6c18-4bff-a270-98e9cfe294e7@github.com>

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Dispose write cipher after changing ciphers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6084/files
  - new: https://git.openjdk.java.net/jdk/pull/6084/files/dfc1a9ee..60c95ee3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6084&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6084&range=02-03

  Stats: 48 lines in 4 files changed: 48 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6084.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6084/head:pull/6084

PR: https://git.openjdk.java.net/jdk/pull/6084

From duke at openjdk.java.net  Mon Nov  1 14:25:10 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Nov 2021 14:25:10 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
In-Reply-To: <7PLZHlwJz9x2vSwKzSRqnqotW9KJOytFVbGRUgVwomA=.1ab389ec-728e-4451-bba4-779d97c685bd@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
 <7PLZHlwJz9x2vSwKzSRqnqotW9KJOytFVbGRUgVwomA=.1ab389ec-728e-4451-bba4-779d97c685bd@github.com>
Message-ID: <IO-ex8bpXI-5phpxWPfxCo0xgEIfkxwOa5D8MDNMNjw=.3d6c4048-0178-4184-a90c-54e6c5bfbb3d@github.com>

On Sun, 24 Oct 2021 04:58:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Did you want to cover the update for line 222 at OutputRecord.java as well?
>
>> After reviewing the scope of changes to fix writeCipher disposal I decided to remove it entirely. It would probably be a nice follow-up enhancement, but I'm not confident I'd implement it correctly on the first try, so I'd rather not introduce it in a bugfix PR. @XueleiFan is that acceptable to you?
>> 
> I'm not sure of the removal.  Please hold on the integration, and I will have a further look if I have cycles.

Hi @XueleiFan,
I updated the PR to dispose old write ciphers after encrypting the last record. Tests in jdk_security passed. Let me know what you think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From mcimadamore at openjdk.java.net  Mon Nov  1 17:15:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 1 Nov 2021 17:15:55 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v11]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <8DLqVOZo6ZXYqntQe91nI4wIKu0_gn0DY-l8MA2rznM=.fdab6f3c-119e-492d-b61c-6314d51cdd58@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix liveness issue with loader lookups

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/9b519343..17f45861

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=09-10

  Stats: 191 lines in 6 files changed: 187 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From valeriep at openjdk.java.net  Mon Nov  1 18:22:15 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 1 Nov 2021 18:22:15 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
Message-ID: <gaxIzyUDP3QVj-tUYNlxzYgaSl5NFqSfv9hD-tk1_J8=.c86a0e08-00c9-407a-97f4-b84379621015@github.com>

On Fri, 13 Aug 2021 17:11:45 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4.
>> 
>> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed.
>> 
>> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey.
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   P11Key static inner classes refactorings.

Hmm, ok, I was focus on something else and missed your update to this PR. it's been a while, I will take another look to refresh my memory and get back to you... Thanks~

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From jnimeh at openjdk.java.net  Mon Nov  1 19:15:40 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 1 Nov 2021 19:15:40 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes SSLSessions
 to be invalidated unnecessarily
Message-ID: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>

This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.

JBS: https://bugs.openjdk.java.net/browse/JDK-8274736

-------------

Commit messages:
 - Place server in background thread, minor cleanups
 - 8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily

Changes: https://git.openjdk.java.net/jdk/pull/6197/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274736
  Stats: 397 lines in 3 files changed: 393 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6197/head:pull/6197

PR: https://git.openjdk.java.net/jdk/pull/6197

From xuelei at openjdk.java.net  Mon Nov  1 19:47:13 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 1 Nov 2021 19:47:13 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily
In-Reply-To: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
Message-ID: <0HDW-b4nOravk0XnpnhIUvBAdg5mOv1W1bWSSkGVz6M=.703bc259-95ef-43d7-a37e-25b18ea4ebfa@github.com>

On Mon, 1 Nov 2021 18:28:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6197

From xuelei at openjdk.java.net  Mon Nov  1 20:05:22 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 1 Nov 2021 20:05:22 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v4]
In-Reply-To: <kTfOIwOrqA17OL83gtmWuogdMirqEcLTwH5nFjUKQAw=.e3534a30-6c18-4bff-a270-98e9cfe294e7@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <kTfOIwOrqA17OL83gtmWuogdMirqEcLTwH5nFjUKQAw=.e3534a30-6c18-4bff-a270-98e9cfe294e7@github.com>
Message-ID: <yeWHKWXb2uRkZPd2Td3AfXayJ4BAn3hC7_icZhIqMzM=.ed86c37e-c48f-44dc-8c93-28408c167c5f@github.com>

On Mon, 1 Nov 2021 14:13:43 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dispose write cipher after changing ciphers

Thank you for the update.  It looks good to me, except a minor comment.

src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 146:

> 144:     // SSLEngine and SSLSocket
> 145:     abstract void disposeWriteCipher();
> 146: 

Alternatively, this method could have a default implementation that throws UnsupportedOperationException.  Then, there is no need to update DTLSOutputRecord.java.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6084

From duke at openjdk.java.net  Mon Nov  1 20:38:32 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Nov 2021 20:38:32 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v5]
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  avoid modifying DTLSOutputRecord

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6084/files
  - new: https://git.openjdk.java.net/jdk/pull/6084/files/60c95ee3..8c9508c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6084&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6084&range=03-04

  Stats: 8 lines in 2 files changed: 2 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6084.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6084/head:pull/6084

PR: https://git.openjdk.java.net/jdk/pull/6084

From duke at openjdk.java.net  Mon Nov  1 20:38:33 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Nov 2021 20:38:33 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v4]
In-Reply-To: <yeWHKWXb2uRkZPd2Td3AfXayJ4BAn3hC7_icZhIqMzM=.ed86c37e-c48f-44dc-8c93-28408c167c5f@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <kTfOIwOrqA17OL83gtmWuogdMirqEcLTwH5nFjUKQAw=.e3534a30-6c18-4bff-a270-98e9cfe294e7@github.com>
 <yeWHKWXb2uRkZPd2Td3AfXayJ4BAn3hC7_icZhIqMzM=.ed86c37e-c48f-44dc-8c93-28408c167c5f@github.com>
Message-ID: <uEBhkmk_D-JsH0T67hub0XrLfcOmfKkLL_EQ3cJqg0E=.a5422be4-a6e8-4019-8bd9-a3bb96e6c97e@github.com>

On Mon, 1 Nov 2021 19:49:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dispose write cipher after changing ciphers
>
> src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 146:
> 
>> 144:     // SSLEngine and SSLSocket
>> 145:     abstract void disposeWriteCipher();
>> 146: 
> 
> Alternatively, this method could have a default implementation that throws UnsupportedOperationException.  Then, there is no need to update DTLSOutputRecord.java.

I like that idea. Updated the PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From mcimadamore at openjdk.java.net  Mon Nov  1 22:36:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 1 Nov 2021 22:36:40 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak javadoc of loaderLookup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/17f45861..7cf4fcd9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From jnimeh at openjdk.java.net  Mon Nov  1 22:57:46 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 1 Nov 2021 22:57:46 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v2]
In-Reply-To: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
Message-ID: <v3lxNj79FslcwBq7BW8kVBQFSimMHYMke1X0hnx_8xQ=.6cb0cdc4-d4d6-4e0f-b477-08fb8bef31b4@github.com>

> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Add separate tests that isolate TLS 1.3 an 1.2 handshakes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6197/files
  - new: https://git.openjdk.java.net/jdk/pull/6197/files/dc54c60e..8d7af4b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=00-01

  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6197/head:pull/6197

PR: https://git.openjdk.java.net/jdk/pull/6197

From psandoz at openjdk.java.net  Tue Nov  2 00:27:23 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 2 Nov 2021 00:27:23 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v10]
In-Reply-To: <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>
Message-ID: <qLFAt0lFdftR7B2zt_HX1F7hhhqR0_rc8xjJI5i45fY=.f501e843-ed35-400d-ba0e-0e8711505006@github.com>

On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Add cache for memory address var handles
>  - Merge branch 'master' into JEP-419
>  - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm)
>  - Merge branch 'master' into JEP-419
>  - Fix copyright header in TestArrayCopy
>  - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)
>  - * use `invokeWithArguments` to simplify new test
>  - Add test for liveness check with high-aririty downcalls
>    (make sure that if an exception occurs in a downcall because of liveness,
>    ref count of other resources are left intact).
>  - * Fix javadoc issue in VaList
>    * Fix bug in concurrent logic for shared scope acquire
>  - Address review comments
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 111:

> 109:         class VarHandleCache {
> 110:             private static final Map<ValueLayout, VarHandle> handleMap = new ConcurrentHashMap<>();
> 111:             private static final Map<ValueLayout, VarHandle> handleMapNoAlignCheck = new ConcurrentHashMap<>();

Something to consider later if this is an issue. Since the number of `ValueLayout` instances is fixed, carrier x order = 18, we can use stable arrays with ordinals on the instances.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From duke at openjdk.java.net  Tue Nov  2 06:33:14 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 2 Nov 2021 06:33:14 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
In-Reply-To: <7PLZHlwJz9x2vSwKzSRqnqotW9KJOytFVbGRUgVwomA=.1ab389ec-728e-4451-bba4-779d97c685bd@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
 <7PLZHlwJz9x2vSwKzSRqnqotW9KJOytFVbGRUgVwomA=.1ab389ec-728e-4451-bba4-779d97c685bd@github.com>
Message-ID: <9z-wFJkwi7Bjn5SlsviCws7bPXupmREzlnmBVbCrYbg=.1c561617-316c-4b26-910a-4f5d0fae1644@github.com>

On Sun, 24 Oct 2021 04:58:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Did you want to cover the update for line 222 at OutputRecord.java as well?
>
>> After reviewing the scope of changes to fix writeCipher disposal I decided to remove it entirely. It would probably be a nice follow-up enhancement, but I'm not confident I'd implement it correctly on the first try, so I'd rather not introduce it in a bugfix PR. @XueleiFan is that acceptable to you?
>> 
> I'm not sure of the removal.  Please hold on the integration, and I will have a further look if I have cycles.

jdk_security still passes, automated checks green. @XueleiFan could you sponsor?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From mcimadamore at openjdk.java.net  Tue Nov  2 10:34:18 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 2 Nov 2021 10:34:18 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v10]
In-Reply-To: <qLFAt0lFdftR7B2zt_HX1F7hhhqR0_rc8xjJI5i45fY=.f501e843-ed35-400d-ba0e-0e8711505006@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>
 <qLFAt0lFdftR7B2zt_HX1F7hhhqR0_rc8xjJI5i45fY=.f501e843-ed35-400d-ba0e-0e8711505006@github.com>
Message-ID: <ESPjgPDRHUCiWLeJiiePwBlXPrF-Qoxl5ytexABrJVE=.980a26b6-7690-4b0d-8beb-56fdd943ee1b@github.com>

On Tue, 2 Nov 2021 00:24:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Add cache for memory address var handles
>>  - Merge branch 'master' into JEP-419
>>  - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm)
>>  - Merge branch 'master' into JEP-419
>>  - Fix copyright header in TestArrayCopy
>>  - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)
>>  - * use `invokeWithArguments` to simplify new test
>>  - Add test for liveness check with high-aririty downcalls
>>    (make sure that if an exception occurs in a downcall because of liveness,
>>    ref count of other resources are left intact).
>>  - * Fix javadoc issue in VaList
>>    * Fix bug in concurrent logic for shared scope acquire
>>  - Address review comments
>>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 111:
> 
>> 109:         class VarHandleCache {
>> 110:             private static final Map<ValueLayout, VarHandle> handleMap = new ConcurrentHashMap<>();
>> 111:             private static final Map<ValueLayout, VarHandle> handleMapNoAlignCheck = new ConcurrentHashMap<>();
> 
> Something to consider later if this is an issue. Since the number of `ValueLayout` instances is fixed, carrier x order = 18, we can use stable arrays with ordinals on the instances.

What about alignment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From jnimeh at openjdk.java.net  Tue Nov  2 14:03:50 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Tue, 2 Nov 2021 14:03:50 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v3]
In-Reply-To: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
Message-ID: <6cJ7GBhSLT1YnptAt3lVtDbYp2n9zZ4QQYxz4eH--PY=.e10e0d32-de29-4f1a-a960-b94f1e3cccf6@github.com>

> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Add server socket configuration override method and a couple logging statements

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6197/files
  - new: https://git.openjdk.java.net/jdk/pull/6197/files/8d7af4b1..a68781f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=01-02

  Stats: 18 lines in 1 file changed: 16 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6197/head:pull/6197

PR: https://git.openjdk.java.net/jdk/pull/6197

From mullan at openjdk.java.net  Tue Nov  2 15:21:13 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 2 Nov 2021 15:21:13 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v2]
In-Reply-To: <HWQeiDEEIMa5A8ZeSmOVMYi2r7TQ7HhYgaPMUvJL-hY=.fd38bedf-93d9-4e53-a6a1-26e7dce46ed6@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <HWQeiDEEIMa5A8ZeSmOVMYi2r7TQ7HhYgaPMUvJL-hY=.fd38bedf-93d9-4e53-a6a1-26e7dce46ed6@github.com>
Message-ID: <kUkF6p-qMR42dYMf2FnTe4QOaMktIYZtE1aYbbM_cyI=.51b30c29-281c-448b-80b3-e085e1378f2c@github.com>

On Thu, 28 Oct 2021 16:58:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarification on protected attributes

src/java.base/share/classes/java/security/KeyStore.java line 1030:

> 1028:      *
> 1029:      * @param alias the alias name
> 1030:      * @return an unmodifiable {@code Set} of attributes, possibly empty

If the alias does not exist, then is it definitely always empty? I think the word "possibly" here may be a bit misleading. Maybe reword this as:
"an unmodifiable {@code Set} of attributes." This set is empty if the given alias does not exist or there are no attributes associated with the alias. This set may also be empty for PrivateKeyEntry or SecretKeyEntry entries that contain protected attributes and are only available through the ... "

src/java.base/share/classes/java/security/KeyStore.java line 1031:

> 1029:      * @param alias the alias name
> 1030:      * @return an unmodifiable {@code Set} of attributes, possibly empty
> 1031:      *      if the given alias does not exist, or there is no

s/is no/are no/

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From psandoz at openjdk.java.net  Tue Nov  2 15:44:12 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 2 Nov 2021 15:44:12 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
Message-ID: <UX8V13GkspdQyaQurhAql9BaZiAQH5klYW8GyZiRJ-g=.17702d38-a07e-4596-af99-2fcb5243862c@github.com>

On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc of loaderLookup

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From psandoz at openjdk.java.net  Tue Nov  2 15:44:13 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 2 Nov 2021 15:44:13 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v10]
In-Reply-To: <ESPjgPDRHUCiWLeJiiePwBlXPrF-Qoxl5ytexABrJVE=.980a26b6-7690-4b0d-8beb-56fdd943ee1b@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>
 <qLFAt0lFdftR7B2zt_HX1F7hhhqR0_rc8xjJI5i45fY=.f501e843-ed35-400d-ba0e-0e8711505006@github.com>
 <ESPjgPDRHUCiWLeJiiePwBlXPrF-Qoxl5ytexABrJVE=.980a26b6-7690-4b0d-8beb-56fdd943ee1b@github.com>
Message-ID: <5onID0SnzIoPH5_Le4f71eC5ll_zGn0DQecQVpL1jDM=.43d7b2af-185a-4251-828f-058da6a69115@github.com>

On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 111:
>> 
>>> 109:         class VarHandleCache {
>>> 110:             private static final Map<ValueLayout, VarHandle> handleMap = new ConcurrentHashMap<>();
>>> 111:             private static final Map<ValueLayout, VarHandle> handleMapNoAlignCheck = new ConcurrentHashMap<>();
>> 
>> Something to consider later if this is an issue. Since the number of `ValueLayout` instances is fixed, carrier x order = 18, we can use stable arrays with ordinals on the instances.
>
> What about alignment?

Drat, `skipAlignmentCheck` misled me but perhaps there is still benefit for common constants with 8 bit and size alignment and fallback otherwise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From prappo at openjdk.java.net  Tue Nov  2 16:54:28 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 16:54:28 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
Message-ID: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>

This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?

As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.

This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:

    $ sh ./bin/blessed-modifier-order.sh src/java.base

The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.

[^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
[^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6213/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6213&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276348
  Stats: 39 lines in 21 files changed: 0 ins; 0 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6213.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6213/head:pull/6213

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 16:58:11 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 16:58:11 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <zZMdJU4BXOR-4mcoyrKrmrTLXGiJi8hekZJ_KGvldrw=.362aaf50-0708-4016-8455-ffb817c5f12c@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

A colleague suggested that I should clarify that the `blessed-modifier-order.sh` script that I used is available in the JDK repo at https://github.com/openjdk/jdk/blob/01105d6985b39d4064b9066eab3612da5a401685/bin/blessed-modifier-order.sh. That script was contributed by Martin Buchholz in JDK-8136656 in 2015.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From dfuchs at openjdk.java.net  Tue Nov  2 17:13:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 2 Nov 2021 17:13:10 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <vAasuC86pLnqzqKTDT1xJlXxIDU57fCqyOJbKbpZgNQ=.22ec60dd-e1ee-44e5-ac4d-9d9e85e35839@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by dfuchs (Reviewer).

LGTM

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From rriggs at openjdk.java.net  Tue Nov  2 17:17:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 2 Nov 2021 17:17:18 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

src/java.base/share/classes/java/lang/Object.java line 282:

> 280:      * <li>For objects of type {@code Class,} by executing a
> 281:      *     static synchronized method of that class.
> 282:      * </ul>

In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From darcy at openjdk.java.net  Tue Nov  2 17:24:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 2 Nov 2021 17:24:14 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <jYgJWYaCicwG9drcOKmBwmNg622VJmuQOL1Eh-gVhY8=.17d6cecf-0b90-4592-82f6-7ece2c782b91@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From iris at openjdk.java.net  Tue Nov  2 17:24:14 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 2 Nov 2021 17:24:14 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <GJb7WJ0CqsRGsN-5zeOhiq82SGQMFT8N9AImRs_lzHU=.8f86ebc7-055a-4c69-b983-a2e7710f01df@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From jvernee at openjdk.java.net  Tue Nov  2 17:32:17 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 2 Nov 2021 17:32:17 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
Message-ID: <wCzCmT6ysO0EAQgn5C6ZbDTTZxGk8Bf0JnuKxjOfUQQ=.e6be3695-4027-4845-a2a2-d16b39290f75@github.com>

On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc of loaderLookup

Mostly some minor javadoc comments.

src/java.base/share/classes/java/lang/Module.java line 32:

> 30: import java.lang.annotation.Annotation;
> 31: import java.lang.invoke.MethodHandle;
> 32: import java.lang.invoke.VarHandle;

These imports seem spurious now.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java line 177:

> 175:         }
> 176:         if (carrier.isPrimitive() && Wrapper.forPrimitiveType(carrier).bitWidth() != size &&
> 177:                 carrier != boolean.class && size != 8) {

I find this condition hard to parse, I'd suggest re-writing it as:

if (carrier.isPrimitive()) {
    long expectedSize = carrier == boolean.class ? 8 : Wrapper.forPrimitiveType(carrier).bitWidth();
    if (size != expectedSize) {
        throw ...
    }
}

(Maybe even change the `if` to an `else` and combine it with the above if).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java line 484:

> 482:     public static final class OfAddress extends ValueLayout {
> 483:         OfAddress(ByteOrder order) {
> 484:             super(MemoryAddress.class, order, Unsafe.ADDRESS_SIZE * 8);

I see `Unsafe.ADDRESS_SIZE` used in several places, suggest to maybe add an `ADDRESS_SIZE_BITS` constants somewhere (it's a bit more readable).

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 42:

> 40:     final long blockSize;
> 41:     final long arenaSize;
> 42:     final ResourceScope scope;

Could these field be made private?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 88:

> 86:                     if (size > arenaSize) {
> 87:                         throw new OutOfMemoryError();
> 88:                     }

Isn't this already covered by the `finally` block? Also, this seems to be checking the unaltered `size`, which I think should have been already done at the end of the previous `allocate` call right?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 122:

> 120:         ResourceScopeImpl targetImpl = (ResourceScopeImpl)target;
> 121:         targetImpl.acquire0();
> 122:         addCloseAction(targetImpl::release0);

Maybe this should explicitly check if target is `null` (though the call to `acquire0` would also produce an NPE, the stack trace having Objects::requireNonNull in there would make the error more obvious I think).
Suggestion:

    public void keepAlive(ResourceScope target) {
        Objects.requireNonNull(target);
        if (target == this) {
            throw new IllegalArgumentException("Invalid target scope.");
        }
        ResourceScopeImpl targetImpl = (ResourceScopeImpl)target;
        targetImpl.acquire0();
        addCloseAction(targetImpl::release0);

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 101:

> 99:         int value;
> 100:         do {
> 101:             value = (int) STATE.getVolatile(jdk.internal.foreign.SharedScope.this);

Doesn't need to be fully qualified I think?
Suggestion:

            value = (int) STATE.getVolatile(this);

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 106:

> 104:                 throw new IllegalStateException("Already closed");
> 105:             }
> 106:         } while (!STATE.compareAndSet(jdk.internal.foreign.SharedScope.this, value, value - 1));

Same here
Suggestion:

        } while (!STATE.compareAndSet(this, value, value - 1));

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5907

From jvernee at openjdk.java.net  Tue Nov  2 17:32:24 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 2 Nov 2021 17:32:24 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v10]
In-Reply-To: <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>
Message-ID: <QcXpMpgQuuA-3772AYtOml3cWcnnR5vEBZ1WtfqBM4M=.eabbe80f-22df-4001-a7c9-d2ccb31c3186@github.com>

On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Add cache for memory address var handles
>  - Merge branch 'master' into JEP-419
>  - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm)
>  - Merge branch 'master' into JEP-419
>  - Fix copyright header in TestArrayCopy
>  - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)
>  - * use `invokeWithArguments` to simplify new test
>  - Add test for liveness check with high-aririty downcalls
>    (make sure that if an exception occurs in a downcall because of liveness,
>    ref count of other resources are left intact).
>  - * Fix javadoc issue in VaList
>    * Fix bug in concurrent logic for shared scope acquire
>  - Address review comments
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1586:

> 1584:             public void ensureCustomized(MethodHandle mh) {
> 1585:                 mh.customize();
> 1586:             }

This is no longer needed, but it probably got picked up in the merge.

src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java line 144:

> 142:      * @param mh the method handle
> 143:      */
> 144:     void ensureCustomized(MethodHandle mh);

Same here, no longer needed. (it was used by now removed upcall handler code. See https://github.com/openjdk/panama-foreign/pull/553)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 107:

> 105:      *
> 106:      * @param offset offset in bytes (relative to this address). The final address of this read operation can be expressed as {@code toRowLongValue() + offset}.
> 107:      * @return a Java UTF-8 string containing all the bytes read from the given starting address ({@code toRowLongValue() + offset})

(see also comment on MemorySegment.getUtf8String)
Suggestion:

     * @return a Java string constructed from the bytes read from the given starting address ({@code toRowLongValue() + offset})

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 387:

> 385: 
> 386:     /**
> 387:      * Performs an element-wise bulk copy from given source segment to this segment. More specifically, the bytes at

Suggestion:

     * Performs a byte-wise bulk copy from given source segment to this segment. More specifically, the bytes at

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 400:

> 398:      * a multiple of the source element layout size, if the source segment is incompatible with the alignment constraints
> 399:      * in the source element layout, or if this segment is incompatible with the alignment constraints
> 400:      * in the destination element layout.

This speaks about element layouts, but I don't see any element layouts in the method implementation.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 633:

> 631:      * java.nio.charset.CharsetDecoder} class should be used when more control
> 632:      * over the decoding process is required.
> 633:      * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,

Suggestion:

     * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment,

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 636:

> 634:      *               the final address of this read operation can be expressed as {@code address().toRowLongValue() + offset}.
> 635:      * @return a Java UTF-8 string containing all the bytes read from the given starting address up to (but not including)
> 636:      * the first {@code '\0'} terminator character (assuming one is found).

The phrase "a Java UTF-8 string" sounds strange to me, as Java Strings are not encoded in UTF-8. The string that is read is UTF-8 encoded, but then it is converted from UTF-8 to Java internal String encoding (UTF-16 or Latin1).

I'd suggest just dropping the 'UTF-8', and changing 'containing all' to 'constructed from'.
Suggestion:

     * @return a Java string constructed from the bytes read from the given starting address up to (but not including)
     * the first {@code '\0'} terminator character (assuming one is found).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 652:

> 650:      * java.nio.charset.CharsetDecoder} class should be used when more control
> 651:      * over the decoding process is required.
> 652:      * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,

Suggestion:

     * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment,

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 762:

> 760: 
> 761:     /**
> 762:      * Creates a new native memory segment with given size and resource scope, and whose base address is this address.

Suggestion:

     * Creates a new native memory segment with given size and resource scope, and whose base address is the given address.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 769:

> 767:      * provided resource scope.
> 768:      * <p>
> 769:      * Clients should ensure that the address and bounds refers to a valid region of memory that is accessible for reading and,

Suggestion:

     * Clients should ensure that the address and bounds refer to a valid region of memory that is accessible for reading and,

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1035:

> 1033:      *
> 1034:      * @param layout the layout of the memory region to be read.
> 1035:      * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,

Suggestion:

     * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment,

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1549:

> 1547:      * @param index index (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,
> 1548:      *               the final address of this write operation can be expressed as {@code address().toRowLongValue() + (index * layout.byteSize())}.
> 1549:      * @param value the byte value to be written.

Suggestion:

     * @param value the address value to be written.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1563:

> 1561:      * Copies a number of elements from a source segment to a destination array,
> 1562:      * starting at a given segment offset (expressed in bytes), and a given array index, using the given source element layout.
> 1563:      * Supported array types are {@code byte[]}, {@code char[]},{@code short[]},{@code int[]},{@code float[]},{@code long[]} and {@code double[]}.

Suggestion:

     * Supported array types are {@code byte[]}, {@code char[]}, {@code short[]}, {@code int[]}, {@code float[]}, {@code long[]} and {@code double[]}.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1604:

> 1602:      * Copies a number of elements from a source array to a destination segment,
> 1603:      * starting at a given array index, and a given segment offset (expressed in bytes), using the given destination element layout.
> 1604:      * Supported array types are {@code byte[]}, {@code char[]},{@code short[]},{@code int[]},{@code float[]},{@code long[]} and {@code double[]}.

Suggestion:

     * Supported array types are {@code byte[]}, {@code char[]}, {@code short[]}, {@code int[]}, {@code float[]}, {@code long[]} and {@code double[]}.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 208:

> 206:      */
> 207:     static ResourceScope newConfinedScope() {
> 208:         return ResourceScopeImpl.createConfined( Thread.currentThread(), null);

Suggestion:

        return ResourceScopeImpl.createConfined(Thread.currentThread(), null);

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/VaList.java line 132:

> 130:     /**
> 131:      * Copies this variable argument list at its current position into a new variable argument list associated
> 132:      * with the same scope as this variable argument list. using the segment provided allocator. Copying is useful to

I think ". using the segment provided allocator" can be removed. Seems like a leftover from when we had an overload that took an allocator.
Suggestion:

     * with the same scope as this variable argument list. Copying is useful to

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From jvernee at openjdk.java.net  Tue Nov  2 17:32:25 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 2 Nov 2021 17:32:25 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v10]
In-Reply-To: <QcXpMpgQuuA-3772AYtOml3cWcnnR5vEBZ1WtfqBM4M=.eabbe80f-22df-4001-a7c9-d2ccb31c3186@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <wUAuOEYgLOLXwm-WgtLLMj3GKVJ2nFIZazQSi16zaXc=.4637910d-a678-4d1a-89d9-82f439ade88a@github.com>
 <QcXpMpgQuuA-3772AYtOml3cWcnnR5vEBZ1WtfqBM4M=.eabbe80f-22df-4001-a7c9-d2ccb31c3186@github.com>
Message-ID: <aZeyuXAwjCwreT-4v7vdv2vAvBPwbQB-3HFuls7Wumc=.fe0fb911-9a1e-48bd-99e1-45b3c3f14c13@github.com>

On Mon, 1 Nov 2021 15:38:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Add cache for memory address var handles
>>  - Merge branch 'master' into JEP-419
>>  - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm)
>>  - Merge branch 'master' into JEP-419
>>  - Fix copyright header in TestArrayCopy
>>  - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)
>>  - * use `invokeWithArguments` to simplify new test
>>  - Add test for liveness check with high-aririty downcalls
>>    (make sure that if an exception occurs in a downcall because of liveness,
>>    ref count of other resources are left intact).
>>  - * Fix javadoc issue in VaList
>>    * Fix bug in concurrent logic for shared scope acquire
>>  - Address review comments
>>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1035:
> 
>> 1033:      *
>> 1034:      * @param layout the layout of the memory region to be read.
>> 1035:      * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,
> 
> Suggestion:
> 
>      * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment,

Same suggestion with all the other getters/setters below (I assume you wanted to add text to the link here?)

> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1549:
> 
>> 1547:      * @param index index (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,
>> 1548:      *               the final address of this write operation can be expressed as {@code address().toRowLongValue() + (index * layout.byteSize())}.
>> 1549:      * @param value the byte value to be written.
> 
> Suggestion:
> 
>      * @param value the address value to be written.

I think all the setters have this problem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From alanb at openjdk.java.net  Tue Nov  2 17:42:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 2 Nov 2021 17:42:14 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
Message-ID: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>

On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.

I think Roger is right and maybe the change to the javadoc could be dropped from this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 17:49:19 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 17:49:19 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
Message-ID: <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>

On Tue, 2 Nov 2021 17:39:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Object.java line 282:
>> 
>>> 280:      * <li>For objects of type {@code Class,} by executing a
>>> 281:      *     static synchronized method of that class.
>>> 282:      * </ul>
>> 
>> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.
>
>> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.
> 
> I think Roger is right and maybe the change to the javadoc could be dropped from this patch.

It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 18:22:12 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 18:22:12 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
Message-ID: <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>

On Tue, 2 Nov 2021 17:45:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.
>> 
>> I think Roger is right and maybe the change to the javadoc could be dropped from this patch.
>
> It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded.

Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev.  

Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prr at openjdk.java.net  Tue Nov  2 18:30:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 18:30:16 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <YGH-CpRv1zM9qRSQzYtt_Gv5I0GOlg7eqx2NgoVAKuI=.e87785f1-d09e-49b1-964b-d283b5aa738b@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

JFYI a couple of times I've wondered if we regressed on this. I just ran the script on the desktop module and we havea  few instances there too, so I've filed a clean up bug on it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From sean.mullan at oracle.com  Tue Nov  2 18:34:58 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 2 Nov 2021 14:34:58 -0400
Subject: previously prevented exploit now possible with JDK 18
In-Reply-To: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
References: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
Message-ID: <00bad2ca-b90c-ac41-854f-ba5d1222fe32@oracle.com>

Hello Rick,

It is behaving as expected. Let me explain in more detail.

First, loading a signed JAR off the classpath only verifies the
signature and digests of the JAR file. It does not validate the signer's
certificate chain or determine if the signer is trusted. The JarFile API
class description includes this warning [1]:

"Please note that the verification process does not include validating
the signer's certificate. A caller should inspect the return value of
JarEntry.getCodeSigners() to further determine if the signature can be
trusted."

Some frameworks such as Web Start have this additional checking
built-in. Or, if you run your code with a Security Manager, then
additional steps will be performed at run-time to check that the code is
signed and that the signer's public key is trusted before granting
permissions to that code.

If you don't perform these additional steps, then the JAR can be
modified without detection. For example, the signature related files
could be removed from the JAR (thus making it an unsigned JAR), or the
JAR could be modified and then re-signed with a different key. In either
of these cases, the JVM would load the JAR without any exception.

It is also possible that a JAR signed with a weak or broken algorithm 
(such as MD5 or SHA-1) could be modified without detection.

This is why the JDK implementation supports several security
properties which are used to disable cryptographic algorithms and
protocols that are weak or broken. This provides out-of-the-box security
and is important to safeguard against crypto algorithms that inevitably
become weaker over time. One of these properties is
"jdk.jar.disabledAlgorithms". The specification of this property defines
the behavior if a signed JAR file is signed with an algorithm that is
disabled [2]:

"JARs signed with any of the disabled algorithms or key sizes will be
treated as unsigned."

The JDK determined after step 1 of the JAR verification process [3] that
the JAR was signed with SHA-1, and therefore stopped further processing.

You may ask why we don't throw an Exception in this case. Although this
was considered, the compatibility risk was too high. These
restrictions are nearly always backported to earlier JDK update
releases. Throwing an Exception would be too high of a risk for
applications that happen to load signed JARs off the classpath but don't
otherwise behave any differently. Our primary focus is to protect
applications that verify that the code is signed by someone they trust.

Consider updating and re-signing your signed jar with a stronger, 
non-broken algorithm such as SHA-2. SHA-2 is the default digest 
algorithm used by jarsigner when the -digestalg option is not specified.

I hope this information is useful. I do think this is an area where our
javadocs and guides could be improved to provide more information about
how signed JARs are verified including more details on the behavior of
the JDK implementation with respect to disabled algorithms. We will be
working to try to improve the docs for JDK 18.

--Sean

[1]
https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/util/jar/JarFile.html
[2]
https://github.com/openjdk/jdk/blob/master/src/java.base/share/conf/security/java.security#L667
[3]
https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#signed-jar-file


On 10/28/21 3:14 PM, Rick Hillegas wrote:
> As a canary in the mineshaft, I built and tested Apache Derby with the
> recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
> following issue when running Derby's regression tests. The problem is
> explained in more detail at
> https://issues.apache.org/jira/browse/DERBY-7126, where a simple repro
> (DERBY_7126_A) can be found. The problem is almost surely the result of
> work done on https://bugs.openjdk.java.net/browse/JDK-8269039 (Disable
> SHA-1 Signed JARs).
> 
> Under previous versions of the JDK, the JVM would raise an error if you
> tried to load a class from a jar file which had been signed with SHA-1
> but later hacked by inserting malware via "jar -uf". This was the error:
> 
>   ? SHA1 digest error for $corruptedJarFileName
> 
> However, under JDK 18 the hacked class loads, no error is raised, and
> the malware can now be executed. I was surprised that a previously
> prevented exploit now works. I think it would be better if the JVM still
> refused to load the hacked class even though SHA-1 has been deprecated.
> 
> Thanks,
> -Rick
> 

From rriggs at openjdk.java.net  Tue Nov  2 18:52:20 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 2 Nov 2021 18:52:20 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
Message-ID: <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>

On Tue, 2 Nov 2021 18:48:06 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev.  
>> 
>> Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him.
>
> "to each his own". I think static synchronized reads best and more natural  than synchronzied static. Also from a semantic point of view as it conveys class level characteristic thus lends static to having a prominence in specified order.

Pragmatically, fix the script to ignore those keywords on comment lines.  
Learn Perl, its just a regular expression pattern match and replace expression.

All of the changes have to be manually reviewed by the author and then the reviewers.
Checking unneeded changes is part of every mechanical change.

The text being changed in the javadoc is the *spec*; that deserves special attention in review.

But having seen several reviewers be unmoved by the difference, the real pragmatic view
is to ignore the English.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From msheppar at openjdk.java.net  Tue Nov  2 18:52:20 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Tue, 2 Nov 2021 18:52:20 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
Message-ID: <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>

On Tue, 2 Nov 2021 18:17:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded.
>
> Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev.  
> 
> Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him.

"to each his own". I think static synchronized reads best and more natural  than synchronzied static. Also from a semantic point of view as it conveys class level characteristic thus lends static to having a prominence in specified order.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 19:18:15 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 19:18:15 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
 <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
Message-ID: <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>

On Tue, 2 Nov 2021 18:48:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.

I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
 
> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.

I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From duke at openjdk.java.net  Tue Nov  2 19:18:16 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 2 Nov 2021 19:18:16 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:

> 86:  */
> 87: public
> 88: abstract class CallSite {

I think it's better to move all modifiers to the single line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 19:25:14 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 19:25:14 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>
Message-ID: <vhdidv2oL8fQ22csqEcQeFWHFPdjcq__t1IUzD6X4-E=.99ff41dd-0131-43c5-a66d-ba15309b429a@github.com>

On Tue, 2 Nov 2021 19:15:26 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
>> 
>> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
>> 
>> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
>> 
>>     $ sh ./bin/blessed-modifier-order.sh src/java.base
>> 
>> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
>> 
>> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
>> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
>
> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:
> 
>> 86:  */
>> 87: public
>> 88: abstract class CallSite {
> 
> I think it's better to move all modifiers to the single line.

This is a survivorship bias. This example jumps out at you, because it happens to use missorted modifiers. I'm pretty sure this is not an aberration, but a style. If you want to change that style, you should create a respective JBS issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From mcimadamore at openjdk.java.net  Tue Nov  2 18:52:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 2 Nov 2021 18:52:21 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <wCzCmT6ysO0EAQgn5C6ZbDTTZxGk8Bf0JnuKxjOfUQQ=.e6be3695-4027-4845-a2a2-d16b39290f75@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
 <wCzCmT6ysO0EAQgn5C6ZbDTTZxGk8Bf0JnuKxjOfUQQ=.e6be3695-4027-4845-a2a2-d16b39290f75@github.com>
Message-ID: <LmumNYBTtfpHdsaUSOYaYA65QtVIiewuGNF2Jxk7-kI=.e6199a44-78c7-492b-89ee-700a406aa642@github.com>

On Tue, 2 Nov 2021 16:51:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak javadoc of loaderLookup
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 88:
> 
>> 86:                     if (size > arenaSize) {
>> 87:                         throw new OutOfMemoryError();
>> 88:                     }
> 
> Isn't this already covered by the `finally` block? Also, this seems to be checking the unaltered `size`, which I think should have been already done at the end of the previous `allocate` call right?

I'll have to think some more about this. I don't think this is covered inside the block - that is, the block tries to allocate, and then in the finally we throw if we realized we've allocated too much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From alanb at openjdk.java.net  Tue Nov  2 19:49:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 2 Nov 2021 19:49:15 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v13]
In-Reply-To: <1DhHETKpULKzqGU-0EU7qcdSWDngTBO1UMQ39E8qzBw=.ad279b49-57fb-4026-9049-862b4aef2ada@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <1DhHETKpULKzqGU-0EU7qcdSWDngTBO1UMQ39E8qzBw=.ad279b49-57fb-4026-9049-862b4aef2ada@github.com>
Message-ID: <IcqL5_hBf_lFdJ_2ImJUzvk8G9vNTzfG6TtOqD4gJtY=.f557e13d-d56a-4d7e-9ff2-7ac79228b390@github.com>

On Tue, 2 Nov 2021 19:35:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address impl review comments
>  - Address API review comments

src/java.base/share/classes/java/lang/Module.java line 114:

> 112: 
> 113:     // true, if this module allows restricted native access; @Stable makes sure that modules that allow native
> 114:     // access capture this property as a constant.

Do you mind fixing this comment to avoid the really long line, it sticks out compare to everything else around it.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 478:

> 476:     private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();
> 477: 
> 478:     static Runnable acquireScope(ByteBuffer bb, boolean async) {

At some point (not this PR) we should move the "async" out of this file, IOUtil was for synchronous I/O.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Tue Nov  2 19:49:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 2 Nov 2021 19:49:14 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v13]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <1DhHETKpULKzqGU-0EU7qcdSWDngTBO1UMQ39E8qzBw=.ad279b49-57fb-4026-9049-862b4aef2ada@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Address impl review comments
 - Address API review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/7cf4fcd9..1126133a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=11-12

  Stats: 103 lines in 11 files changed: 8 ins; 23 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Tue Nov  2 19:49:16 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 2 Nov 2021 19:49:16 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <ekptcSWurL7TCI9UQg9oUm261suMGQedFTB-s86XC_w=.2eb23e6e-c51e-45d9-ac4f-305fc97c9be1@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
 <wCzCmT6ysO0EAQgn5C6ZbDTTZxGk8Bf0JnuKxjOfUQQ=.e6be3695-4027-4845-a2a2-d16b39290f75@github.com>
 <LmumNYBTtfpHdsaUSOYaYA65QtVIiewuGNF2Jxk7-kI=.e6199a44-78c7-492b-89ee-700a406aa642@github.com>
 <ekptcSWurL7TCI9UQg9oUm261suMGQedFTB-s86XC_w=.2eb23e6e-c51e-45d9-ac4f-305fc97c9be1@github.com>
Message-ID: <smw2ow_lpXCXpH6gI8RI_bgfEEWfOUL8l1Th75EkqDE=.7316e2f5-1434-486a-a492-d48c4352877f@github.com>

On Tue, 2 Nov 2021 18:55:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I'll have to think some more about this. I don't think this is covered inside the block - that is, the block tries to allocate, and then in the finally we throw if we realized we've allocated too much.
>
> What is missing, I think, is a check (size > arenaSize) at the beginning of the method (we only check this in one of the paths). But we need to check before and after, I think, as it is possible to allocate a segment and then realize that we ended up overflowing the arena size.

While what I said above correctly reflects what the implementation does, I think a broader issue is that the arena allocator implementation is allocating sometimes more native memory than what its contract specifies. While in some cases we can prevent that, I think in the general case (e.g. where we allocate a new block) we cannot, unless we add extra API guarantees - e.g. that the arena size should be a multiple of the block size (but then we'd have to special case `Long.MAX_VALUE`, or maybe pick a "big enough" power of two instead)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Tue Nov  2 19:49:16 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 2 Nov 2021 19:49:16 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <LmumNYBTtfpHdsaUSOYaYA65QtVIiewuGNF2Jxk7-kI=.e6199a44-78c7-492b-89ee-700a406aa642@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
 <wCzCmT6ysO0EAQgn5C6ZbDTTZxGk8Bf0JnuKxjOfUQQ=.e6be3695-4027-4845-a2a2-d16b39290f75@github.com>
 <LmumNYBTtfpHdsaUSOYaYA65QtVIiewuGNF2Jxk7-kI=.e6199a44-78c7-492b-89ee-700a406aa642@github.com>
Message-ID: <ekptcSWurL7TCI9UQg9oUm261suMGQedFTB-s86XC_w=.2eb23e6e-c51e-45d9-ac4f-305fc97c9be1@github.com>

On Tue, 2 Nov 2021 18:48:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 88:
>> 
>>> 86:                     if (size > arenaSize) {
>>> 87:                         throw new OutOfMemoryError();
>>> 88:                     }
>> 
>> Isn't this already covered by the `finally` block? Also, this seems to be checking the unaltered `size`, which I think should have been already done at the end of the previous `allocate` call right?
>
> I'll have to think some more about this. I don't think this is covered inside the block - that is, the block tries to allocate, and then in the finally we throw if we realized we've allocated too much.

What is missing, I think, is a check (size > arenaSize) at the beginning of the method (we only check this in one of the paths). But we need to check before and after, I think, as it is possible to allocate a segment and then realize that we ended up overflowing the arena size.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From jvernee at openjdk.java.net  Tue Nov  2 19:49:16 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 2 Nov 2021 19:49:16 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <smw2ow_lpXCXpH6gI8RI_bgfEEWfOUL8l1Th75EkqDE=.7316e2f5-1434-486a-a492-d48c4352877f@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
 <wCzCmT6ysO0EAQgn5C6ZbDTTZxGk8Bf0JnuKxjOfUQQ=.e6be3695-4027-4845-a2a2-d16b39290f75@github.com>
 <LmumNYBTtfpHdsaUSOYaYA65QtVIiewuGNF2Jxk7-kI=.e6199a44-78c7-492b-89ee-700a406aa642@github.com>
 <ekptcSWurL7TCI9UQg9oUm261suMGQedFTB-s86XC_w=.2eb23e6e-c51e-45d9-ac4f-305fc97c9be1@github.com>
 <smw2ow_lpXCXpH6gI8RI_bgfEEWfOUL8l1Th75EkqDE=.7316e2f5-1434-486a-a492-d48c4352877f@github.com>
Message-ID: <P_Y3_iIoH99Qj1lvgehRTP_ibi9QU-fENOzmkK6gDxU=.de280620-0f33-48a9-93e7-f861ff3eb0e8@github.com>

On Tue, 2 Nov 2021 19:02:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> What is missing, I think, is a check (size > arenaSize) at the beginning of the method (we only check this in one of the paths). But we need to check before and after, I think, as it is possible to allocate a segment and then realize that we ended up overflowing the arena size.
>
> While what I said above correctly reflects what the implementation does, I think a broader issue is that the arena allocator implementation is allocating sometimes more native memory than what its contract specifies. While in some cases we can prevent that, I think in the general case (e.g. where we allocate a new block) we cannot, unless we add extra API guarantees - e.g. that the arena size should be a multiple of the block size (but then we'd have to special case `Long.MAX_VALUE`, or maybe pick a "big enough" power of two instead)

Maybe we should not support block size in the case of a bounded arena. i.e. just allocate the whole thing upfront, and have 3 APIs:

1. arena with no bounds and default block size.
2. arena with no bounds and custom block size.
3. arena with bounds, that has no blocks size but allocates the whole thing in one go (could be modeled as block size = arena size).

Right now we have 1. and 2., but instead of 3. we have a variant that allows setting both the arena size and block size.

If we want to keep what we currently have, I'd suggest changing the arena size to a block count for the variant that takes both the arena size and the block size (I think in that case `Long.MAX_VALUE` should still work?).

Any ways, that seems like something that could be addressed in 19 as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From rriggs at openjdk.java.net  Tue Nov  2 19:54:10 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 2 Nov 2021 19:54:10 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <yoYcZRSo53PJgOWRV4VK75VVmcr8Aav4wIzHbn-4-94=.79d6c5a1-a6a8-4d0d-af46-0df5ecf5101a@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Keep it as is with the modifiers in the recommended order.  I don't think adding extra typography is warranted.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 19:59:14 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 19:59:14 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <vhdidv2oL8fQ22csqEcQeFWHFPdjcq__t1IUzD6X4-E=.99ff41dd-0131-43c5-a66d-ba15309b429a@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>
 <vhdidv2oL8fQ22csqEcQeFWHFPdjcq__t1IUzD6X4-E=.99ff41dd-0131-43c5-a66d-ba15309b429a@github.com>
Message-ID: <s2u76YJkLRi3hQZHdoGO52SPSRjCpUU9uiSQ-tTFVvk=.c35ba140-aaa2-408f-afb6-ee366f861cf7@github.com>

On Tue, 2 Nov 2021 19:22:15 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:
>> 
>>> 86:  */
>>> 87: public
>>> 88: abstract class CallSite {
>> 
>> I think it's better to move all modifiers to the single line.
>
> This is a survivorship bias. This example jumps out at you, because it happens to use missorted modifiers. I'm pretty sure this is not an aberration, but a style. If you want to change that style, you should create a respective JBS issue.

I've grepped the code and can now see that a list of modifiers broken by newlines which cannot be explained by line-width concerns is indeed an irregularity. Not only in java.base but also in other modules. Although there aren't many of such cases, I would prefer them to be addressed in a separate cleanup, which you are welcome to pursue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From martin at openjdk.java.net  Tue Nov  2 20:38:21 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 2 Nov 2021 20:38:21 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <CHZWzS1TClQhEeQBLovKK_BILKuVfkXQFXiJLnhyMAs=.e2c9e467-3670-42e3-9252-c78f02daace3@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by martin (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From martin at openjdk.java.net  Tue Nov  2 20:38:21 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 2 Nov 2021 20:38:21 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
 <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
 <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>
Message-ID: <RI-elaMIMqBwnoN3g_iKS9cVHlzfuWndB2t_F03wuiE=.fd1d8ac0-6c26-43da-92bb-9f6d65636f4e@github.com>

On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Pragmatically, fix the script to ignore those keywords on comment lines.  
>> Learn Perl, its just a regular expression pattern match and replace expression.
>> 
>> All of the changes have to be manually reviewed by the author and then the reviewers.
>> Checking unneeded changes is part of every mechanical change.
>> 
>> The text being changed in the javadoc is the *spec*; that deserves special attention in review.
>> 
>> But having seen several reviewers be unmoved by the difference, the real pragmatic view
>> is to ignore the English.
>
>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
> 
> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
>  
>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
> 
> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.

The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)

Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
I don't have a strong feeling either way on changing that file.

I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
I would also not update copyright years for such changes.

It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From duke at openjdk.java.net  Tue Nov  2 20:43:18 2021
From: duke at openjdk.java.net (Florent Guillaume)
Date: Tue, 2 Nov 2021 20:43:18 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v7]
In-Reply-To: <xwvnl__yeRiaUh6v1Kmwqzk2Ib-Qs1ySFsd77xuIMH8=.6520dbe1-cc62-4084-aaa1-bf686b6e6002@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <xwvnl__yeRiaUh6v1Kmwqzk2Ib-Qs1ySFsd77xuIMH8=.6520dbe1-cc62-4084-aaa1-bf686b6e6002@github.com>
Message-ID: <CaDPVCUQnIIKMm5BLJspL7FXw_G3F0bBr-YdFEteIUQ=.e83c4423-46c8-475e-9017-31f76f5fc75a@github.com>

On Thu, 28 Oct 2021 18:55:32 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review notes

Could the original JDK-8230297 be closed as a duplicate please?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From xuelei at openjdk.java.net  Tue Nov  2 20:51:08 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 2 Nov 2021 20:51:08 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v3]
In-Reply-To: <6cJ7GBhSLT1YnptAt3lVtDbYp2n9zZ4QQYxz4eH--PY=.e10e0d32-de29-4f1a-a960-b94f1e3cccf6@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
 <6cJ7GBhSLT1YnptAt3lVtDbYp2n9zZ4QQYxz4eH--PY=.e10e0d32-de29-4f1a-a960-b94f1e3cccf6@github.com>
Message-ID: <PHPbLcywfofZ5n7W0YNhDCUHI3-I3xbF4hdW46ZE3zA=.25962443-7d07-47b9-9212-57a935865b15@github.com>

On Tue, 2 Nov 2021 14:03:50 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add server socket configuration override method and a couple logging statements

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6197

From mcimadamore at openjdk.java.net  Tue Nov  2 21:33:46 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 2 Nov 2021 21:33:46 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v14]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <supho3PloghhSdg03onlnilrfi3lZ2JowsQ70DkJPd8=.d4fc30ce-243f-4d35-95c9-ba48cd6afc26@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix long comment line in Module.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/1126133a..c219ae12

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From valeriep at openjdk.java.net  Tue Nov  2 22:47:15 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 2 Nov 2021 22:47:15 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
Message-ID: <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>

On Fri, 13 Aug 2021 17:11:45 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4.
>> 
>> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed.
>> 
>> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey.
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   P11Key static inner classes refactorings.

Hi Martin,

Please find my comments in line below.

>     * Changing P11PrivateKey::getFormat to return 'PKCS#8' and not overriding this method on opaque/sensitive private key classes will be an observable change, and it does not match what's specified in Key::getFormat: 'Returns the name of the primary encoding format of this key, or null if this key does not support encoding.'. My thinking here is that an opaque key does not support encoding because its value is not even accessible.

Hmm, good point. I agree that returning null as default format and override it whenever an encoding is returned is the right thing to do.

>     * P11PrivateKeyRSA and P11RSAPrivateKey class names look confusing to me (where 'RSA' is located does not say anything about the class to me at least). The 'Opaque' suffix for the one that is package-private might be a better choice. I used the suffice 'Internal' before but now I like 'Opaque' more.

Sure, I didn't spend much time on this. Either Opaque or Internal suffix is fine. Generally I prefer shorter names.

>     * P11PrivateKeyRSA::of duplicates the attributes retrieval logic (session.token.p11::C_GetAttributeValue call), which is there and in P11Key::fetchAttributes. Sensitive RSA keys get the attributes from one place and non-sensitive from the other. This does not look to me an advantage when compared to the Fetcher, which does the same for RSA and uses P11Key::fetchAttributes for the others. However, having all the RSA-related logic in P11RSAAttributesFetcher::doFetchValues makes it a bit easier for me to reason about the 4 different scenarios to get the data: CRT + sensitive, non-CRT + sensitive, CRT + non-sensitive and non-CRT + non-sensitive.

This is where our view differs. We both have same class hierarchy but where the attributes are managed are different, you put all of them in the very bottom, i.e. fetcher, but I prefer them to be at top. Using RSA as an example, there are P11RSAPrivateKeyInternal - sensitive private key
P11RSAPrivateKey - non-sensitive CRT private key
P11RSAPrivateNonCRTKey - non-sensitive non-CRT private key
P11RSAPublicKey - public key
They all use the same P11RSAAttributesFetcher class but with different keySensitive, isPrivate flags to decide which attributes to query and which fields to populate. Whether the fields are null or not, the upper classes have no idea. The logic are all inside the fetcher. The keySensitive, isPrivate flags also have to be passed all around which seems strange as the classes themselves already implied these values and should not need to take arguments, i.e. P11RSAPrivateKey (keySensitive== false AND isPrivate == true). Overall, I find it hard to read. Comparing the fetcher model vs the non-fetcher model, the non-fetcher model has less code (at least 100 lines less) and it's very clear which attributes each class requires.

>     * By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.

There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.

>     * P11PrivateKeyRSA does not make the CRT/non-CRT distinction for sensitive keys, so the public exponent is not obtained when it could be. This is a bit less functionality than what the Fetcher provides, and would require a few changes to fit it into the design.

The proposed P11RSAPrivateKeyInternal class has no method for returning the public exponent either. If needed, it should be doable by adding extra attribute to the list of attributes in P11PrivateKeyRSA class. Should be trivial.

I updated the class naming in my prototype to align with yours and updated the prototype changes with your feedback. You can check/compare it at: http://cr.openjdk.java.net/~valeriep/8271566/webrev.01/

We have different views on this I guess. I prefer to let each class manage their list of attributes instead of a separate fetcher with their own logic. Former also has less code and follows the same model of existing code.
 
Thanks,
Valerie

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From weijun at openjdk.java.net  Tue Nov  2 23:19:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 2 Nov 2021 23:19:12 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v7]
In-Reply-To: <CaDPVCUQnIIKMm5BLJspL7FXw_G3F0bBr-YdFEteIUQ=.e83c4423-46c8-475e-9017-31f76f5fc75a@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <xwvnl__yeRiaUh6v1Kmwqzk2Ib-Qs1ySFsd77xuIMH8=.6520dbe1-cc62-4084-aaa1-bf686b6e6002@github.com>
 <CaDPVCUQnIIKMm5BLJspL7FXw_G3F0bBr-YdFEteIUQ=.e83c4423-46c8-475e-9017-31f76f5fc75a@github.com>
Message-ID: <5R4T_OJOXAw-P6GMZhL-Y3SF5Evh8jgX3lkHVCFBCjQ=.a604f01b-c379-4c80-b5d1-31ad5726ca68@github.com>

On Tue, 2 Nov 2021 20:39:47 GMT, Florent Guillaume <duke at openjdk.java.net> wrote:

>> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review notes
>
> Could the original JDK-8230297 be closed as a duplicate please?

@efge Closed. Thanks for reminding.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From xuelei at openjdk.java.net  Tue Nov  2 23:39:12 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 2 Nov 2021 23:39:12 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v5]
In-Reply-To: <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
Message-ID: <eVQYJvrNbkhlYSHSS-MUv5ZdvR0AsfQ_ipfKLc-UTIg=.199bb744-dcf5-4633-bed3-4f364c0ce1d4@github.com>

On Mon, 1 Nov 2021 20:38:32 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid modifying DTLSOutputRecord

Please hold on the integration, the regression testing failed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From xuelei at openjdk.java.net  Tue Nov  2 23:46:19 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 2 Nov 2021 23:46:19 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v5]
In-Reply-To: <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
Message-ID: <SmjJYLpJCzsxPyGeWhiUEyRA8ZfPZUGyzqRwqhFoTqo=.8704352a-74a2-41d4-871f-831c1d75782c@github.com>

On Mon, 1 Nov 2021 20:38:32 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid modifying DTLSOutputRecord

src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java line 436:

> 434: 
> 435:         void queueUpCipherDispose() {
> 436:             RecordMemo lastMemo = handshakeMemos.getLast();

Sorry, I missed that the getLast could throw exception if it is empty.  I may check it before the call to getLast.

+           if (handshakeMemos.isEmpty()) {
+              return;
+          }

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From duke at openjdk.java.net  Wed Nov  3 08:12:12 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Nov 2021 08:12:12 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v5]
In-Reply-To: <eVQYJvrNbkhlYSHSS-MUv5ZdvR0AsfQ_ipfKLc-UTIg=.199bb744-dcf5-4633-bed3-4f364c0ce1d4@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
 <eVQYJvrNbkhlYSHSS-MUv5ZdvR0AsfQ_ipfKLc-UTIg=.199bb744-dcf5-4633-bed3-4f364c0ce1d4@github.com>
Message-ID: <CNNMcJYXUGUZfwNZoXbmnu4Gxfv5tIWFQ0A595RvFJ8=.7681de30-1a13-4e0e-bd8f-52d29dbcef50@github.com>

On Tue, 2 Nov 2021 23:35:51 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please hold off on the integration, the regression testing failed.

could you point me to the failing test? I'm running the jdk_security suite; only sun/security/mscapi/ShortRSAKeyWithinTLS is failing, and it's failing because of environmental reasons (Windows is asking for some PIN)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From duke at openjdk.java.net  Wed Nov  3 09:16:47 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Nov 2021 09:16:47 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v6]
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <f0zhWobY52A8vwr7VJa3y4NXChXrpPTS1dNxovmypIY=.476da511-a2c2-42d1-bb0a-b8dc1119e928@github.com>

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  bugfix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6084/files
  - new: https://git.openjdk.java.net/jdk/pull/6084/files/8c9508c2..c18de4e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6084&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6084&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6084.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6084/head:pull/6084

PR: https://git.openjdk.java.net/jdk/pull/6084

From duke at openjdk.java.net  Wed Nov  3 09:16:50 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Nov 2021 09:16:50 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v5]
In-Reply-To: <SmjJYLpJCzsxPyGeWhiUEyRA8ZfPZUGyzqRwqhFoTqo=.8704352a-74a2-41d4-871f-831c1d75782c@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
 <SmjJYLpJCzsxPyGeWhiUEyRA8ZfPZUGyzqRwqhFoTqo=.8704352a-74a2-41d4-871f-831c1d75782c@github.com>
Message-ID: <Guiha3Bd3XbrxTCVl35qLDI0Gws8zrUbTwmV1LGeOhk=.b491d56a-b7cc-4ffd-bf71-33be32e81d59@github.com>

On Tue, 2 Nov 2021 23:43:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid modifying DTLSOutputRecord
>
> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java line 436:
> 
>> 434: 
>> 435:         void queueUpCipherDispose() {
>> 436:             RecordMemo lastMemo = handshakeMemos.getLast();
> 
> Sorry, I missed that the getLast could throw exception if it is empty.  I may check it before the call to getLast.
> 
> +           if (handshakeMemos.isEmpty()) {
> +              return;
> +          }

my mistake. Replaced with `peekLast`, should be better now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From prappo at openjdk.java.net  Wed Nov  3 10:10:20 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Nov 2021 10:10:20 GMT
Subject: Integrated: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <kYYsea9qLBMAcGUxzLj14jVEJHgc0PqjOSxnojS-YXQ=.1b075e29-e097-47fb-a3f6-e397e990ba53@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

This pull request has now been integrated.

Changeset: 61506336
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/615063364ab6bdd3fa83401745e05b45e13eacdb
Stats:     39 lines in 21 files changed: 0 ins; 0 del; 39 mod

8276348: Use blessed modifier order in java.base

Reviewed-by: dfuchs, darcy, iris, rriggs, martin

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From dfuchs at openjdk.java.net  Wed Nov  3 10:19:25 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 3 Nov 2021 10:19:25 GMT
Subject: RFR: 8276401: Use blessed modifier order in java.net.http
Message-ID: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>

Hi, 

Please find here a trivial cleanup change that updates classes in the `java.net.http` module to use the "blessed modifier order".

The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh src/java.net.http`.

best regards,

-- daniel

-------------

Commit messages:
 - 8276401: Use blessed modifier order in java.net.http

Changes: https://git.openjdk.java.net/jdk/pull/6228/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6228&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276401
  Stats: 31 lines in 13 files changed: 0 ins; 0 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6228/head:pull/6228

PR: https://git.openjdk.java.net/jdk/pull/6228

From prappo at openjdk.java.net  Wed Nov  3 11:26:15 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Nov 2021 11:26:15 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <RI-elaMIMqBwnoN3g_iKS9cVHlzfuWndB2t_F03wuiE=.fd1d8ac0-6c26-43da-92bb-9f6d65636f4e@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
 <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
 <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>
 <RI-elaMIMqBwnoN3g_iKS9cVHlzfuWndB2t_F03wuiE=.fd1d8ac0-6c26-43da-92bb-9f6d65636f4e@github.com>
Message-ID: <Fz41LrTr1xQWBzD_pay82SIc9MxdY4O5Rl7tOnV1eSw=.1717ed8f-3288-4355-ad02-9133dfdfa8cf@github.com>

On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
>> 
>> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
>>  
>>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
>> 
>> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.
>
> The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)
> 
> Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
> I don't have a strong feeling either way on changing that file.
> 
> I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
> I would also not update copyright years for such changes.
> 
> It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.

One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49

So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.**

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From mcimadamore at openjdk.java.net  Wed Nov  3 11:32:50 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 3 Nov 2021 11:32:50 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v15]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <3l5SgC7qqzs4wj1leQ3TKp4gqDMXozx6W6bUxO1wlTA=.5db656f9-98d2-474a-918a-f076e63be127@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Simplify ArenaAllocator impl.
  The arena should respect its boundaries and never allocate more memory than its size specifies.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/c219ae12..7f847271

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=13-14

  Stats: 40 lines in 1 file changed: 8 ins; 15 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From prappo at openjdk.java.net  Wed Nov  3 11:43:13 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Nov 2021 11:43:13 GMT
Subject: RFR: 8276401: Use blessed modifier order in java.net.http
In-Reply-To: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
References: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
Message-ID: <P-d0j7wqKt7idM_SlCRHjcuRL0joiQ3ElxUxS8B15hg=.71410d2a-37e0-4228-a83d-67d65ad4210a@github.com>

On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a trivial cleanup change that updates classes in the `java.net.http` module to use the "blessed modifier order".
> 
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh src/java.net.http`.
> 
> best regards,
> 
> -- daniel

Don't forget to update the copyright years, if you think that it's necessary.

-------------

Marked as reviewed by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6228

From aefimov at openjdk.java.net  Wed Nov  3 12:37:53 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 3 Nov 2021 12:37:53 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v11]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <eSZFVJlkT4A2e_NPxUNsGN8dEM68yQNRaHmuRBNuD5o=.614ebcae-afe4-4e23-bcbf-589f8e139130@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov 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 branch 'master' into JDK-8244202_JEP418_impl
 - Replace 'system' with 'the system-wide', move comment section
 - Add @ throws NPE to hosts file resolver javadoc
 - Changes to address review comments
 - Update tests to address SM deprecation
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - More javadoc updates to API classes
 - Review updates + move resolver docs to the provider class (CSR update to follow)
 - Change InetAddressResolver method names
 - Remove no longer used import from IPSupport
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/9152e3fb...b31d61d1

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/f660cc6e..b31d61d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=09-10

  Stats: 16073 lines in 487 files changed: 12211 ins; 1991 del; 1871 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From mcimadamore at openjdk.java.net  Wed Nov  3 13:08:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 3 Nov 2021 13:08:55 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v16]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <rOalCbBDAEN_vlQC0lNqzPsbsSDwbM_yfuVd5WPwrLU=.04da3f41-1fc9-4cfa-bc75-2483e37e2bdc@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Make ArenaAllocator impl more flexible in the face of OOME
  An ArenaAllocator should remain open for business, even if OOME is thrown in case other allocations can fit the arena size.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/7f847271..9fafb2a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=14-15

  Stats: 13 lines in 2 files changed: 3 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From aefimov at openjdk.java.net  Wed Nov  3 13:23:36 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 3 Nov 2021 13:23:36 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v12]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <Ktvq-2IpcMRsZqGJnzOXLQSgrflbVUiCvIMe6CWYiRI=.1e0644b8-a219-4317-9cdb-65a1a5c659c8@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Replace 'system' with 'the system-wide', move comment section
 - Add @ throws NPE to hosts file resolver javadoc
 - Changes to address review comments
 - Update tests to address SM deprecation
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - More javadoc updates to API classes
 - Review updates + move resolver docs to the provider class (CSR update to follow)
 - Change InetAddressResolver method names
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/a316c06e...0542df51

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5822/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=11
  Stats: 3141 lines in 56 files changed: 2848 ins; 155 del; 138 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From jvernee at openjdk.java.net  Wed Nov  3 13:40:16 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 3 Nov 2021 13:40:16 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v16]
In-Reply-To: <rOalCbBDAEN_vlQC0lNqzPsbsSDwbM_yfuVd5WPwrLU=.04da3f41-1fc9-4cfa-bc75-2483e37e2bdc@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <rOalCbBDAEN_vlQC0lNqzPsbsSDwbM_yfuVd5WPwrLU=.04da3f41-1fc9-4cfa-bc75-2483e37e2bdc@github.com>
Message-ID: <hJuLXwbM4GqJmdmYNuRXLnah0y4nowhk68uLdoKCFcw=.d90d275b-41f2-4708-b561-620bbc3f31d5@github.com>

On Wed, 3 Nov 2021 13:08:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make ArenaAllocator impl more flexible in the face of OOME
>   An ArenaAllocator should remain open for business, even if OOME is thrown in case other allocations can fit the arena size.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From rriggs at openjdk.java.net  Wed Nov  3 13:45:11 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 3 Nov 2021 13:45:11 GMT
Subject: RFR: 8276401: Use blessed modifier order in java.net.http
In-Reply-To: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
References: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
Message-ID: <2cAIsCyHuE6L_2zKvTYvxjGP7dKOtaeMyJIJN4t7bMk=.152686ff-8ec8-4b11-b147-f14c83299671@github.com>

On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a trivial cleanup change that updates classes in the `java.net.http` module to use the "blessed modifier order".
> 
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh src/java.net.http`.
> 
> best regards,
> 
> -- daniel

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6228

From prappo at openjdk.java.net  Wed Nov  3 14:14:22 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Nov 2021 14:14:22 GMT
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_
> 
> On 3/11/2021 9:26 pm, Pavel Rappo wrote:
> 
> > On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:
> > > > > Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
> > > > 
> > > > 
> > > > I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
> > > > > But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
> > > > 
> > > > 
> > > > I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.
> > > 
> > > 
> > > The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)
> > > Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
> > > I don't have a strong feeling either way on changing that file.
> > > I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
> > > I would also not update copyright years for such changes.
> > > It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.
> > 
> > 
> > One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49
> > So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.**
> 
> Line 281 is (was!) consistent with line 277 because it is distinguishing a synchronized "static method" from a synchronized "instance method". There was no need to make any change to line 281 because of the blessed-order of modifiers as defined for method declarations! This text is just prose. Now for consistency you should change line 277 to refer to a "non-static synchronized method" (as "instance synchronized method" would be truly awful).

Thanks, David. You've provided a clear and convincing argument, and I can see the inconsistency I introduced. I can revert that particular piece back if you think that it would be appropriate. 

That said, this line will have to be filtered out every time the script is run. I could probably provide a more involved script that harnesses the power of AST (com.sun.source.doctree) to try to filter out prose, but it would be impossible to beat the simplicity of the current script; and simplicity is also important.
 
> Line 49 places "static synchronized" in code font, implying that it is referring to the actual method modifiers and as such using the blessed order is appropriate. Line 49 does not need to be "consistent" with line 281. If line 49 used a normal font so the words "static" and "synchronized" were just prose then either order would be perfectly fine in terms of English language, but then you could make a case for having it be consistent with line 281.

I've been always having hard time with modifiers being not enclosed in `@code` in the first place; they are barely English words. Is there really a semantic difference between L49 and L281 such that it warrants the use of `@code` in the former but not in the latter case? Does `synchornized` or `static` in L281 refer to anything other than the like-named Java modifiers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From weijun at openjdk.java.net  Wed Nov  3 14:18:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 3 Nov 2021 14:18:38 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v3]
In-Reply-To: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
Message-ID: <mwNLsVYGKEpcBiUXla7JN9FqldGR6F1oI4yDV4piYXo=.fcbdd558-4feb-481c-bddf-bc3fe9a18c17@github.com>

> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more clear and precise spec

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6026/files
  - new: https://git.openjdk.java.net/jdk/pull/6026/files/7238e784..aaaa6145

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=01-02

  Stats: 16 lines in 2 files changed: 4 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6026/head:pull/6026

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Wed Nov  3 14:18:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 3 Nov 2021 14:18:44 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v2]
In-Reply-To: <kUkF6p-qMR42dYMf2FnTe4QOaMktIYZtE1aYbbM_cyI=.51b30c29-281c-448b-80b3-e085e1378f2c@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <HWQeiDEEIMa5A8ZeSmOVMYi2r7TQ7HhYgaPMUvJL-hY=.fd38bedf-93d9-4e53-a6a1-26e7dce46ed6@github.com>
 <kUkF6p-qMR42dYMf2FnTe4QOaMktIYZtE1aYbbM_cyI=.51b30c29-281c-448b-80b3-e085e1378f2c@github.com>
Message-ID: <7P4w_MoV_D6zPxN7eMPx4CqvPpybebInDfeHq9ibX7E=.d1665076-084b-4456-a091-7d342ff66395@github.com>

On Tue, 2 Nov 2021 15:18:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarification on protected attributes
>
> src/java.base/share/classes/java/security/KeyStore.java line 1030:
> 
>> 1028:      *
>> 1029:      * @param alias the alias name
>> 1030:      * @return an unmodifiable {@code Set} of attributes, possibly empty
> 
> If the alias does not exist, then is it definitely always empty? I think the word "possibly" here may be a bit misleading. Maybe reword this as:
> "an unmodifiable {@code Set} of attributes." This set is empty if the given alias does not exist or there are no attributes associated with the alias. This set may also be empty for PrivateKeyEntry or SecretKeyEntry entries that contain protected attributes and are only available through the ... "

Updated as suggested. CSR updated as well.

> src/java.base/share/classes/java/security/KeyStore.java line 1031:
> 
>> 1029:      * @param alias the alias name
>> 1030:      * @return an unmodifiable {@code Set} of attributes, possibly empty
>> 1031:      *      if the given alias does not exist, or there is no
> 
> s/is no/are no/

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From msheppar at openjdk.java.net  Wed Nov  3 14:30:10 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Wed, 3 Nov 2021 14:30:10 GMT
Subject: RFR: 8276401: Use blessed modifier order in java.net.http
In-Reply-To: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
References: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
Message-ID: <DjIBKTOOl1XfV_bt_9mcC1oj70JQDomF_Mx_euxYjsU=.01c8032f-d7fb-4967-94fa-1906f5e7d43d@github.com>

On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a trivial cleanup change that updates classes in the `java.net.http` module to use the "blessed modifier order".
> 
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh src/java.net.http`.
> 
> best regards,
> 
> -- daniel

a general comment on the static abstract class  changes to abstract static class. For me the former and current declarations seems more appropriate, that is, static abstract class,  as the static modifier immediately conveys a significant and strong structural relationship with outer or containing class. While abstract has a qualification on class i.e. the type of class and appearing directly before class is more natural (to me !!). As such, abstract qualifies the static relationship.
The placement and ordering of the modifier should be to assist in covering semantics when scanning code, and conveys a certain level of "importance" of the qualifier's semantics

-------------

PR: https://git.openjdk.java.net/jdk/pull/6228

From weijun at openjdk.java.net  Wed Nov  3 14:57:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 3 Nov 2021 14:57:40 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore [v4]
In-Reply-To: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
Message-ID: <c36jwwTb7lTgYX79s4QvWRAGJ3bedL7QT69urddRZY8=.3e5606f3-c49a-43e5-adbc-7aeef84dafce@github.com>

> You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.
> 
> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  same spec in SPI

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5950/files
  - new: https://git.openjdk.java.net/jdk/pull/5950/files/3670f992..266cf6de

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5950&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5950&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5950.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5950/head:pull/5950

PR: https://git.openjdk.java.net/jdk/pull/5950

From msheppar at openjdk.java.net  Wed Nov  3 15:09:11 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Wed, 3 Nov 2021 15:09:11 GMT
Subject: RFR: 8276401: Use blessed modifier order in java.net.http
In-Reply-To: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
References: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
Message-ID: <anz_YlQX9K81JMeZgMlZ1WmxsywM0JQ6QWHH5oKk7Ek=.99f830ff-2763-4bf5-a842-e6e88efaa7af@github.com>

On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a trivial cleanup change that updates classes in the `java.net.http` module to use the "blessed modifier order".
> 
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh src/java.net.http`.
> 
> best regards,
> 
> -- daniel

> _Mailing list message from [Daniel Fuchs](mailto:daniel.fuchs at oracle.com) on [net-dev](mailto:net-dev at mail.openjdk.java.net):_
> 
> Hi Mark,
> 
> On 03/11/2021 14:30, Mark Sheppard wrote:
> 
> > a general comment on the static abstract class  changes to abstract static class. For me the former and current declarations seems more appropriate, that is, static abstract class,  as the static modifier immediately conveys a significant and strong structural relationship with outer or containing class. While abstract has a qualification on class i.e. the type of class and appearing directly before class is more natural (to me !!). As such, abstract qualifies the static relationship.
> > The placement and ordering of the modifier should be to assist in covering semantics when scanning code, and conveys a certain level of "importance" of the qualifier's semantics
> 
> WRT `static abstract` vs `abstract static` I had exactly the same feeling - but since there is a blessed ordering and a script to fix classes to conform to the blessed ordering I'm not going to fight it.
> 
> best regards,
> 
> -- daniel

:-)  cula bula ... that's fair enough, no argument here, just thought it worth a comment.
as with a lot of "style guides", the blessed order can be a little idiosyncratic
a bit like the case of would you wear a stripped tie with a check shirt, or is a plain tie the only suitable option :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6228

From xuelei at openjdk.java.net  Wed Nov  3 16:06:19 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 3 Nov 2021 16:06:19 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v6]
In-Reply-To: <f0zhWobY52A8vwr7VJa3y4NXChXrpPTS1dNxovmypIY=.476da511-a2c2-42d1-bb0a-b8dc1119e928@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <f0zhWobY52A8vwr7VJa3y4NXChXrpPTS1dNxovmypIY=.476da511-a2c2-42d1-bb0a-b8dc1119e928@github.com>
Message-ID: <Mmsqk7rkMGXuxAH5PuTrfQBp1awba5IVBCpGPwyXmjk=.e6359d41-8e1a-4c2b-93db-e5f906c00702@github.com>

On Wed, 3 Nov 2021 09:16:47 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bugfix

> > Please hold off on the integration, the regression testing failed.
> 
> could you point me to the failing test? I'm running the jdk_security suite; only sun/security/mscapi/ShortRSAKeyWithinTLS is failing, and it's failing because of environmental reasons (Windows is asking for some PIN)
> 
> _EDIT_ found them; started testing jdk_core and the tests surfaced pretty quickly.
I normally run tier1 and tier2 test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From dfuchs at openjdk.java.net  Wed Nov  3 16:27:20 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 3 Nov 2021 16:27:20 GMT
Subject: Integrated: 8276401: Use blessed modifier order in java.net.http
In-Reply-To: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
References: <Q2WVruiX6POyGbR9MFWSacwIjbbKSOW8-N6JIgCrJv8=.ff461bb8-1c9c-4434-81bc-cfb70ff4db20@github.com>
Message-ID: <dtv4RSuej6PWF0oZNlv1_PnQ5Kf1qiNqsFRnN2qlYtg=.42781c77-3502-49b1-b707-b027fb495a9b@github.com>

On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a trivial cleanup change that updates classes in the `java.net.http` module to use the "blessed modifier order".
> 
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh src/java.net.http`.
> 
> best regards,
> 
> -- daniel

This pull request has now been integrated.

Changeset: 7115892f
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7115892f96a5a57ce9d37602038b787d19da5d81
Stats:     31 lines in 13 files changed: 0 ins; 0 del; 31 mod

8276401: Use blessed modifier order in java.net.http

Reviewed-by: prappo, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/6228

From abakhtin at openjdk.java.net  Wed Nov  3 16:46:49 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 3 Nov 2021 16:46:49 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v3]
In-Reply-To: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
Message-ID: <QqrNK7SOHHRkBIqoRbn9qFZ7hav2XBniLPxmC_HB-qY=.57e91a96-3661-47b0-99a3-5cce3f1ac7d8@github.com>

> Please review the patch for JDK-8274524
> 
> The fix just adds locks around InputStream read and skip operations to prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Add ClientSocketCloseHang jtreg test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5760/files
  - new: https://git.openjdk.java.net/jdk/pull/5760/files/065073d1..145149bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5760&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5760&range=01-02

  Stats: 134 lines in 1 file changed: 134 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5760/head:pull/5760

PR: https://git.openjdk.java.net/jdk/pull/5760

From abakhtin at openjdk.java.net  Wed Nov  3 17:02:40 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 3 Nov 2021 17:02:40 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v4]
In-Reply-To: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
Message-ID: <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>

> Please review the patch for JDK-8274524
> 
> The fix just adds locks around InputStream read and skip operations to prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Fix jcheck issues

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5760/files
  - new: https://git.openjdk.java.net/jdk/pull/5760/files/145149bc..02aa671f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5760&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5760&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5760/head:pull/5760

PR: https://git.openjdk.java.net/jdk/pull/5760

From abakhtin at openjdk.java.net  Wed Nov  3 17:02:43 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 3 Nov 2021 17:02:43 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v3]
In-Reply-To: <QqrNK7SOHHRkBIqoRbn9qFZ7hav2XBniLPxmC_HB-qY=.57e91a96-3661-47b0-99a3-5cce3f1ac7d8@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <QqrNK7SOHHRkBIqoRbn9qFZ7hav2XBniLPxmC_HB-qY=.57e91a96-3661-47b0-99a3-5cce3f1ac7d8@github.com>
Message-ID: <GEwuTmOAOrh9fE5SeRdJ275QrTW39yaVWlnziiZy9lg=.fb6da92e-c18c-4d34-86c5-d0d6ffd4250b@github.com>

On Wed, 3 Nov 2021 16:46:49 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the patch for JDK-8274524
>> 
>> The fix just adds locks around InputStream read and skip operations to prevent concurrent read from socket.
>> sun/security/ssl jtreg tests passed
>> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ClientSocketCloseHang jtreg test

New jtreg test is added to reproduce the issue and verify it.
sun/security/ssl tests passed

-------------

PR: https://git.openjdk.java.net/jdk/pull/5760

From rick.hillegas at gmail.com  Wed Nov  3 17:07:00 2021
From: rick.hillegas at gmail.com (Rick Hillegas)
Date: Wed, 3 Nov 2021 10:07:00 -0700
Subject: previously prevented exploit now possible with JDK 18
In-Reply-To: <00bad2ca-b90c-ac41-854f-ba5d1222fe32@oracle.com>
References: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
 <00bad2ca-b90c-ac41-854f-ba5d1222fe32@oracle.com>
Message-ID: <27683d47-c657-a111-2f08-f9d12009a422@gmail.com>

Thanks for your detailed comments, Sean. We agree wholeheartedly that 
being signed and being trusted/valid are two separate concepts. The JDK 
wisely punts the issue of trust to the application developer. As I 
understand it, we disagree about the following points:

1) Is the signedness of a jar an immutable fact or is it just an 
opinion? I think that it is an immutable fact, measured by whether the 
jar's manifest contains certain stereotypical files. You maintain that 
it is an opinion which can shift incompatibly between JDK releases.

2) Should the JDK continue to raise an exception when loading classes 
from clearly compromised jars?

3) Are javadoc and a release note adequate defenses against an exploit 
which will surface when a mission-critical application upgrades to a JDK 
containing the work on https://bugs.openjdk.java.net/browse/JDK-8269039 ?

Here's how I see it:

a) A jar doesn't cease to be signed when its signer goes to jail and 
authorities revoke the signing certificate.

b) A jar doesn't cease to be signed because someone pokes malware into 
it and breaks the hash.

c) A jar doesn't cease to be signed because serious people distrust its 
old, shoddy cryptography.

In all of these cases, trust has diminished. But the jar is still signed.

Note that the emphatic deprecation of the SecurityManager affects your 
comments below.

Thanks,
-Rick


On 11/2/21 11:34 AM, Sean Mullan wrote:
> Hello Rick,
>
> It is behaving as expected. Let me explain in more detail.
>
> First, loading a signed JAR off the classpath only verifies the
> signature and digests of the JAR file. It does not validate the signer's
> certificate chain or determine if the signer is trusted. The JarFile API
> class description includes this warning [1]:
>
> "Please note that the verification process does not include validating
> the signer's certificate. A caller should inspect the return value of
> JarEntry.getCodeSigners() to further determine if the signature can be
> trusted."
>
> Some frameworks such as Web Start have this additional checking
> built-in. Or, if you run your code with a Security Manager, then
> additional steps will be performed at run-time to check that the code is
> signed and that the signer's public key is trusted before granting
> permissions to that code.
>
> If you don't perform these additional steps, then the JAR can be
> modified without detection. For example, the signature related files
> could be removed from the JAR (thus making it an unsigned JAR), or the
> JAR could be modified and then re-signed with a different key. In either
> of these cases, the JVM would load the JAR without any exception.
>
> It is also possible that a JAR signed with a weak or broken algorithm 
> (such as MD5 or SHA-1) could be modified without detection.
>
> This is why the JDK implementation supports several security
> properties which are used to disable cryptographic algorithms and
> protocols that are weak or broken. This provides out-of-the-box security
> and is important to safeguard against crypto algorithms that inevitably
> become weaker over time. One of these properties is
> "jdk.jar.disabledAlgorithms". The specification of this property defines
> the behavior if a signed JAR file is signed with an algorithm that is
> disabled [2]:
>
> "JARs signed with any of the disabled algorithms or key sizes will be
> treated as unsigned."
>
> The JDK determined after step 1 of the JAR verification process [3] that
> the JAR was signed with SHA-1, and therefore stopped further processing.
>
> You may ask why we don't throw an Exception in this case. Although this
> was considered, the compatibility risk was too high. These
> restrictions are nearly always backported to earlier JDK update
> releases. Throwing an Exception would be too high of a risk for
> applications that happen to load signed JARs off the classpath but don't
> otherwise behave any differently. Our primary focus is to protect
> applications that verify that the code is signed by someone they trust.
>
> Consider updating and re-signing your signed jar with a stronger, 
> non-broken algorithm such as SHA-2. SHA-2 is the default digest 
> algorithm used by jarsigner when the -digestalg option is not specified.
>
> I hope this information is useful. I do think this is an area where our
> javadocs and guides could be improved to provide more information about
> how signed JARs are verified including more details on the behavior of
> the JDK implementation with respect to disabled algorithms. We will be
> working to try to improve the docs for JDK 18.
>
> --Sean
>
> [1]
> https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/util/jar/JarFile.html 
>
> [2]
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/conf/security/java.security#L667 
>
> [3]
> https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#signed-jar-file 
>
>
>
> On 10/28/21 3:14 PM, Rick Hillegas wrote:
>> As a canary in the mineshaft, I built and tested Apache Derby with the
>> recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
>> following issue when running Derby's regression tests. The problem is
>> explained in more detail at
>> https://issues.apache.org/jira/browse/DERBY-7126, where a simple repro
>> (DERBY_7126_A) can be found. The problem is almost surely the result of
>> work done on https://bugs.openjdk.java.net/browse/JDK-8269039 (Disable
>> SHA-1 Signed JARs).
>>
>> Under previous versions of the JDK, the JVM would raise an error if you
>> tried to load a class from a jar file which had been signed with SHA-1
>> but later hacked by inserting malware via "jar -uf". This was the error:
>>
>> ? ? SHA1 digest error for $corruptedJarFileName
>>
>> However, under JDK 18 the hacked class loads, no error is raised, and
>> the malware can now be executed. I was surprised that a previously
>> prevented exploit now works. I think it would be better if the JVM still
>> refused to load the hacked class even though SHA-1 has been deprecated.
>>
>> Thanks,
>> -Rick
>>


From mcimadamore at openjdk.java.net  Wed Nov  3 17:40:56 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 3 Nov 2021 17:40:56 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v17]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <QQd23tEy3_2A9iKOH825nfYiNU63aRp2gdPu2EyfwFM=.bfffd2de-bf56-4ce7-8aca-87be09f1058c@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix TestUpcall
  * reverse() has a bug, as it doesn't tweak parameter types
  * reverse() is applied to the wrong MH

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/9fafb2a6..b9432473

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=15-16

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From duke at openjdk.java.net  Wed Nov  3 19:03:23 2021
From: duke at openjdk.java.net (Lari Hotari)
Date: Wed, 3 Nov 2021 19:03:23 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in RSAPadding
Message-ID: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>

### Motivation

When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code in RSAPadding, one can see that BadPaddingException is created in all cases, also on the success path:
https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375

### Modifications

Inline the unnecessary local variable to prevent creating the exception on the success path.

-------------

Commit messages:
 - Reduce unnecessary BadPaddingExceptions that are created in success path

Changes: https://git.openjdk.java.net/jdk/pull/5581/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5581&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273977
  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5581/head:pull/5581

PR: https://git.openjdk.java.net/jdk/pull/5581

From shade at openjdk.java.net  Wed Nov  3 19:03:23 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 3 Nov 2021 19:03:23 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
Message-ID: <NfnkWviWr94NBHwDxmjsXFMzab6cleqU7EsWVGGdPlk=.0f06d3b7-689f-4792-8695-86f7790366b4@github.com>

On Mon, 20 Sep 2021 08:38:18 GMT, Lari Hotari <duke at openjdk.java.net> wrote:

> ### Motivation
> 
> When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code in RSAPadding, one can see that BadPaddingException is created in all cases, also on the success path:
> https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375
> 
> ### Modifications
> 
> Inline the unnecessary local variable to prevent creating the exception on the success path.

Submitted the bug for it, [JDK-8273977](https://bugs.openjdk.java.net/browse/JDK-8273977). Please change the PR title to "8273977: Reduce unnecessary BadPaddingExceptions in RSAPadding" to get bots hooked properly.

Regarding the changes themselves, I think the key thing here is the method comment: "Note that we want to make it a constant-time operation", which is probably why this exception is always unconditionally created. Security folks need to say for sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581

From duke at openjdk.java.net  Wed Nov  3 19:03:24 2021
From: duke at openjdk.java.net (Lari Hotari)
Date: Wed, 3 Nov 2021 19:03:24 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <NfnkWviWr94NBHwDxmjsXFMzab6cleqU7EsWVGGdPlk=.0f06d3b7-689f-4792-8695-86f7790366b4@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
 <NfnkWviWr94NBHwDxmjsXFMzab6cleqU7EsWVGGdPlk=.0f06d3b7-689f-4792-8695-86f7790366b4@github.com>
Message-ID: <uqqyZFe5RUaSC7AC8tCv3crNSorYp86By8azJG_iNGM=.3795fa5d-bf7a-4d3c-9aac-9a05397569ba@github.com>

On Mon, 20 Sep 2021 08:43:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Submitted the bug for it, [JDK-8273977](https://bugs.openjdk.java.net/browse/JDK-8273977). Please change the PR title to "8273977: Reduce unnecessary BadPaddingExceptions in RSAPadding" to get bots hooked properly.

Thanks for submitting the bug @shipilev . I renamed the title accordingly.
 
> Regarding the changes themselves, I think the key thing here is the method comment: "Note that we want to make it a constant-time operation", which is probably why this exception is always unconditionally created. Security folks need to say for sure.

+1

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581

From duke at openjdk.java.net  Wed Nov  3 19:03:24 2021
From: duke at openjdk.java.net (Lari Hotari)
Date: Wed, 3 Nov 2021 19:03:24 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
Message-ID: <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>

On Mon, 20 Sep 2021 08:38:18 GMT, Lari Hotari <duke at openjdk.java.net> wrote:

> ### Motivation
> 
> When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code in RSAPadding, one can see that BadPaddingException is created in all cases, also on the success path:
> https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375
> 
> ### Modifications
> 
> Inline the unnecessary local variable to prevent creating the exception on the success path.

In Twitter, it was brought up to attention that "PKCS v1.5 is vulnerable to Bleichenbacher if the check is not constant-time, but there's no reason to leave it in the OAEP (second) function." , https://twitter.com/typish_cast/status/1439875435953786881 .

For unpadV15 method one possible option to retain the "constant-time property of the code" would be to use a stackless exception (by overriding fillInStackTrace) that is an immutable / constant & singleton instance? That wouldn't cause a performance hit for the success path.

For anyone interested, there's an explanation of the [Bleichenbacher's CCA attack on PKCS#1 v1.5 on Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5). The original paper is ["Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" ](http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf).

The reason for constant time is to not leak information about a possible bad padding to the attacker based on the difference in response time between a valid and bad padding. The attacker can use this information to narrow the search to find the pre-master secret.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581

From robilad at openjdk.java.net  Wed Nov  3 19:03:24 2021
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Wed, 3 Nov 2021 19:03:24 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
 <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
Message-ID: <wN3u7fXzDt3CTjEQbFvE9zmmNz_fQPl7XUiHPBs0GU0=.f75fc9b1-11d6-4d3e-89af-e367c0f9b0cb@github.com>

On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari <duke at openjdk.java.net> wrote:

>> ### Motivation
>> 
>> When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code in RSAPadding, one can see that BadPaddingException is created in all cases, also on the success path:
>> https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375
>> 
>> ### Modifications
>> 
>> Inline the unnecessary local variable to prevent creating the exception on the success path.
>
> For anyone interested, there's an explanation of the [Bleichenbacher's CCA attack on PKCS#1 v1.5 on Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5). The original paper is ["Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" ](http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf).
> 
> The reason for constant time is to not leak information about a possible bad padding to the attacker based on the difference in response time between a valid and bad padding. The attacker can use this information to narrow the search to find the pre-master secret.

Hi @lhotari, please submit an OCA at https://oca.opensource.oracle.com/ if you are contributing on your own behalf. If you are contributing on your employers behalf, please send me an e-Mail at dalibor.topic at oracle.com so that I can verify your account.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581

From duke at openjdk.java.net  Wed Nov  3 19:03:25 2021
From: duke at openjdk.java.net (Lari Hotari)
Date: Wed, 3 Nov 2021 19:03:25 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
 <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
Message-ID: <7yURY4hNUZ2sEm88BfAwUqZabfaOIF1A6HZ7T_eHG54=.0303c17b-887c-44b9-928a-c8de4526b0c7@github.com>

On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari <duke at openjdk.java.net> wrote:

>> ### Motivation
>> 
>> When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code in RSAPadding, one can see that BadPaddingException is created in all cases, also on the success path:
>> https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375
>> 
>> ### Modifications
>> 
>> Inline the unnecessary local variable to prevent creating the exception on the success path.
>
> For anyone interested, there's an explanation of the [Bleichenbacher's CCA attack on PKCS#1 v1.5 on Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5). The original paper is ["Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" ](http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf).
> 
> The reason for constant time is to not leak information about a possible bad padding to the attacker based on the difference in response time between a valid and bad padding. The attacker can use this information to narrow the search to find the pre-master secret.

> Hi @lhotari, please submit an OCA at https://oca.opensource.oracle.com/ if you are contributing on your own behalf. If you are contributing on your employers behalf, please send me an e-Mail at [dalibor.topic at oracle.com](mailto:dalibor.topic at oracle.com) so that I can verify your account.

@robilad This is a contribution on my own behalf. I have signed [OCA in 2014 while contributing to Btrace](https://github.com/btraceio/btrace/pull/101#issuecomment-63333404). Is that sufficient? I cannot sign OCA again online, it gives me an error message "The provided GitHub username lhotari does already appear in an existing OCA, please use another one.".

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581

From duke at openjdk.java.net  Wed Nov  3 21:27:11 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Nov 2021 21:27:11 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v5]
In-Reply-To: <Guiha3Bd3XbrxTCVl35qLDI0Gws8zrUbTwmV1LGeOhk=.b491d56a-b7cc-4ffd-bf71-33be32e81d59@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
 <SmjJYLpJCzsxPyGeWhiUEyRA8ZfPZUGyzqRwqhFoTqo=.8704352a-74a2-41d4-871f-831c1d75782c@github.com>
 <Guiha3Bd3XbrxTCVl35qLDI0Gws8zrUbTwmV1LGeOhk=.b491d56a-b7cc-4ffd-bf71-33be32e81d59@github.com>
Message-ID: <KRu7U8Tr2em2ujMbKc4AGgmMYT6z0345bLOidLPzHPo=.f459eb44-84ec-4ff5-80ac-9930edcf9837@github.com>

On Wed, 3 Nov 2021 09:12:29 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java line 436:
>> 
>>> 434: 
>>> 435:         void queueUpCipherDispose() {
>>> 436:             RecordMemo lastMemo = handshakeMemos.getLast();
>> 
>> Sorry, I missed that the getLast could throw exception if it is empty.  I may check it before the call to getLast.
>> 
>> +           if (handshakeMemos.isEmpty()) {
>> +              return;
>> +          }
>
> my mistake. Replaced with `peekLast`, should be better now.

Well, looks like this uncovered another, unrelated bug. `handshakeMemos` is only empty here when we handle TLS1.3 server hello and session ID is empty, see stack trace:

Caused by: java.util.NoSuchElementException
	at java.base/java.util.LinkedList.getLast(LinkedList.java:261)
	at java.base/sun.security.ssl.SSLEngineOutputRecord$HandshakeFragment.queueUpCipherDispose(SSLEngineOutputRecord.java:436)
	at java.base/sun.security.ssl.SSLEngineOutputRecord.disposeWriteCipher(SSLEngineOutputRecord.java:159)
	at java.base/sun.security.ssl.OutputRecord.changeWriteCiphers(OutputRecord.java:198)
	at java.base/sun.security.ssl.ServerHello$T13ServerHelloConsumer.consume(ServerHello.java:1372)

This is only supposed to be empty when [jdk.tls.client.useCompatibilityMode](https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java#L101) is false, which it never is (also the comment above that line is copy/pasted, should be fixed). So I did some more digging and found that we do not set sessionId in clientHello when resuming TLS1.3 session:
- sessionId is set to empty [here](https://github.com/openjdk/jdk/blob/04a806ec86a388b8de31d42f904c4321beb69e14/src/java.base/share/classes/sun/security/ssl/ClientHello.java#L406)
- not updated [here](https://github.com/openjdk/jdk/blob/04a806ec86a388b8de31d42f904c4321beb69e14/src/java.base/share/classes/sun/security/ssl/ClientHello.java#L535) because it's TLS 1.3
- not updated [here](https://github.com/openjdk/jdk/blob/04a806ec86a388b8de31d42f904c4321beb69e14/src/java.base/share/classes/sun/security/ssl/ClientHello.java#L577) because session is not null

Apparently we have no tests for TLS1.3 session resumption in jdk_security and no tests for useCompatibilityMode=false (otherwise I would have noticed this sooner).

Let me know if I should fix these issues here or in a separate PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From xuelei.fan at oracle.com  Wed Nov  3 21:37:52 2021
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 3 Nov 2021 21:37:52 +0000
Subject: RFR: 8275811 Incorrect instance to dispose [v5]
In-Reply-To: <KRu7U8Tr2em2ujMbKc4AGgmMYT6z0345bLOidLPzHPo=.f459eb44-84ec-4ff5-80ac-9930edcf9837@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <TwbMfMnK2PYqS_paAhf8jyb-gEahd8UGdSryUzJt9ho=.84ff6634-6f36-42e1-a6c8-d5930a3d6b44@github.com>
 <SmjJYLpJCzsxPyGeWhiUEyRA8ZfPZUGyzqRwqhFoTqo=.8704352a-74a2-41d4-871f-831c1d75782c@github.com>
 <Guiha3Bd3XbrxTCVl35qLDI0Gws8zrUbTwmV1LGeOhk=.b491d56a-b7cc-4ffd-bf71-33be32e81d59@github.com>
 <KRu7U8Tr2em2ujMbKc4AGgmMYT6z0345bLOidLPzHPo=.f459eb44-84ec-4ff5-80ac-9930edcf9837@github.com>
Message-ID: <798AF353-3057-4A36-B2C5-36B0C5F18F79@oracle.com>

I would suggest to fix in a separate bug.

Thanks,
Xuelei

> On Nov 3, 2021, at 2:27 PM, Daniel Jeli?ski <duke at openjdk.java.net> wrote:
> 
> ?On Wed, 3 Nov 2021 09:12:29 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:
> 
>>> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java line 436:
>>> 
>>>> 434: 
>>>> 435:         void queueUpCipherDispose() {
>>>> 436:             RecordMemo lastMemo = handshakeMemos.getLast();
>>> 
>>> Sorry, I missed that the getLast could throw exception if it is empty.  I may check it before the call to getLast.
>>> 
>>> +           if (handshakeMemos.isEmpty()) {
>>> +              return;
>>> +          }
>> 
>> my mistake. Replaced with `peekLast`, should be better now.
> 
> Well, looks like this uncovered another, unrelated bug. `handshakeMemos` is only empty here when we handle TLS1.3 server hello and session ID is empty, see stack trace:
> 
> Caused by: java.util.NoSuchElementException
>    at java.base/java.util.LinkedList.getLast(LinkedList.java:261)
>    at java.base/sun.security.ssl.SSLEngineOutputRecord$HandshakeFragment.queueUpCipherDispose(SSLEngineOutputRecord.java:436)
>    at java.base/sun.security.ssl.SSLEngineOutputRecord.disposeWriteCipher(SSLEngineOutputRecord.java:159)
>    at java.base/sun.security.ssl.OutputRecord.changeWriteCiphers(OutputRecord.java:198)
>    at java.base/sun.security.ssl.ServerHello$T13ServerHelloConsumer.consume(ServerHello.java:1372)
> 
> This is only supposed to be empty when [jdk.tls.client.useCompatibilityMode](https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java#L101) is false, which it never is (also the comment above that line is copy/pasted, should be fixed). So I did some more digging and found that we do not set sessionId in clientHello when resuming TLS1.3 session:
> - sessionId is set to empty [here](https://github.com/openjdk/jdk/blob/04a806ec86a388b8de31d42f904c4321beb69e14/src/java.base/share/classes/sun/security/ssl/ClientHello.java#L406)
> - not updated [here](https://github.com/openjdk/jdk/blob/04a806ec86a388b8de31d42f904c4321beb69e14/src/java.base/share/classes/sun/security/ssl/ClientHello.java#L535) because it's TLS 1.3
> - not updated [here](https://github.com/openjdk/jdk/blob/04a806ec86a388b8de31d42f904c4321beb69e14/src/java.base/share/classes/sun/security/ssl/ClientHello.java#L577) because session is not null
> 
> Apparently we have no tests for TLS1.3 session resumption in jdk_security and no tests for useCompatibilityMode=false (otherwise I would have noticed this sooner).
> 
> Let me know if I should fix these issues here or in a separate PR.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6084

From xuelei at openjdk.java.net  Wed Nov  3 21:59:15 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 3 Nov 2021 21:59:15 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <7yURY4hNUZ2sEm88BfAwUqZabfaOIF1A6HZ7T_eHG54=.0303c17b-887c-44b9-928a-c8de4526b0c7@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
 <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
 <7yURY4hNUZ2sEm88BfAwUqZabfaOIF1A6HZ7T_eHG54=.0303c17b-887c-44b9-928a-c8de4526b0c7@github.com>
Message-ID: <EQJ6Kp85RV4RfrjQ-YoIEYXjA6l9JBTNK6tyhJjVzD0=.b0e7f0ec-22b5-4a08-909c-d337f83e1590@github.com>

On Fri, 29 Oct 2021 06:07:26 GMT, Lari Hotari <duke at openjdk.java.net> wrote:

>> For anyone interested, there's an explanation of the [Bleichenbacher's CCA attack on PKCS#1 v1.5 on Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5). The original paper is ["Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" ](http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf).
>> 
>> The reason for constant time is to not leak information about a possible bad padding to the attacker based on the difference in response time between a valid and bad padding. The attacker can use this information to narrow the search to find the pre-master secret.
>
>> Hi @lhotari, please submit an OCA at https://oca.opensource.oracle.com/ if you are contributing on your own behalf. If you are contributing on your employers behalf, please send me an e-Mail at [dalibor.topic at oracle.com](mailto:dalibor.topic at oracle.com) so that I can verify your account.
> 
> @robilad This is a contribution on my own behalf. I have signed [OCA in 2014 while contributing to Btrace](https://github.com/btraceio/btrace/pull/101#issuecomment-63333404). Is that sufficient? I cannot sign OCA again online, it gives me an error message "The provided GitHub username lhotari does already appear in an existing OCA, please use another one.".

@lhotari I think you have got the reason to create the BadPaddingExceptions.  Did you want to close this bug, or fix it alternativey without break the constant-time purpose?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581

From ecki at zusammenkunft.net  Thu Nov  4 00:16:09 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 4 Nov 2021 00:16:09 +0000
Subject: previously prevented exploit now possible with JDK 18
In-Reply-To: <27683d47-c657-a111-2f08-f9d12009a422@gmail.com>
References: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
 <00bad2ca-b90c-ac41-854f-ba5d1222fe32@oracle.com>
 <27683d47-c657-a111-2f08-f9d12009a422@gmail.com>
Message-ID: <AM9P193MB11424B8AC5C0AD1D0C45695FFF8D9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Rick if you fear an attacker can modify and install a JAR with a broken signature which you don?t trust anyway, what should stop the attacker to provide a valid but untrusted signature or no checksums at all? It might be a undesirable change for your case but I see no trustmodel where you would need default java classloader to do more than treating it unsigned.

But if you really want to re-enable SHA1 you can do so (or implement a classloader which rejects any SHA1 codebases). Of course much easier would be to only install verified jars.

BTW the fact that you actually get answers about a weakness report is amazing :)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Rick Hillegas <rick.hillegas at gmail.com>
Gesendet: Wednesday, November 3, 2021 6:07:00 PM
An: Sean Mullan <sean.mullan at oracle.com>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: previously prevented exploit now possible with JDK 18

Thanks for your detailed comments, Sean. We agree wholeheartedly that
being signed and being trusted/valid are two separate concepts. The JDK
wisely punts the issue of trust to the application developer. As I
understand it, we disagree about the following points:

1) Is the signedness of a jar an immutable fact or is it just an
opinion? I think that it is an immutable fact, measured by whether the
jar's manifest contains certain stereotypical files. You maintain that
it is an opinion which can shift incompatibly between JDK releases.

2) Should the JDK continue to raise an exception when loading classes
from clearly compromised jars?

3) Are javadoc and a release note adequate defenses against an exploit
which will surface when a mission-critical application upgrades to a JDK
containing the work on https://bugs.openjdk.java.net/browse/JDK-8269039 ?

Here's how I see it:

a) A jar doesn't cease to be signed when its signer goes to jail and
authorities revoke the signing certificate.

b) A jar doesn't cease to be signed because someone pokes malware into
it and breaks the hash.

c) A jar doesn't cease to be signed because serious people distrust its
old, shoddy cryptography.

In all of these cases, trust has diminished. But the jar is still signed.

Note that the emphatic deprecation of the SecurityManager affects your
comments below.

Thanks,
-Rick


On 11/2/21 11:34 AM, Sean Mullan wrote:
> Hello Rick,
>
> It is behaving as expected. Let me explain in more detail.
>
> First, loading a signed JAR off the classpath only verifies the
> signature and digests of the JAR file. It does not validate the signer's
> certificate chain or determine if the signer is trusted. The JarFile API
> class description includes this warning [1]:
>
> "Please note that the verification process does not include validating
> the signer's certificate. A caller should inspect the return value of
> JarEntry.getCodeSigners() to further determine if the signature can be
> trusted."
>
> Some frameworks such as Web Start have this additional checking
> built-in. Or, if you run your code with a Security Manager, then
> additional steps will be performed at run-time to check that the code is
> signed and that the signer's public key is trusted before granting
> permissions to that code.
>
> If you don't perform these additional steps, then the JAR can be
> modified without detection. For example, the signature related files
> could be removed from the JAR (thus making it an unsigned JAR), or the
> JAR could be modified and then re-signed with a different key. In either
> of these cases, the JVM would load the JAR without any exception.
>
> It is also possible that a JAR signed with a weak or broken algorithm
> (such as MD5 or SHA-1) could be modified without detection.
>
> This is why the JDK implementation supports several security
> properties which are used to disable cryptographic algorithms and
> protocols that are weak or broken. This provides out-of-the-box security
> and is important to safeguard against crypto algorithms that inevitably
> become weaker over time. One of these properties is
> "jdk.jar.disabledAlgorithms". The specification of this property defines
> the behavior if a signed JAR file is signed with an algorithm that is
> disabled [2]:
>
> "JARs signed with any of the disabled algorithms or key sizes will be
> treated as unsigned."
>
> The JDK determined after step 1 of the JAR verification process [3] that
> the JAR was signed with SHA-1, and therefore stopped further processing.
>
> You may ask why we don't throw an Exception in this case. Although this
> was considered, the compatibility risk was too high. These
> restrictions are nearly always backported to earlier JDK update
> releases. Throwing an Exception would be too high of a risk for
> applications that happen to load signed JARs off the classpath but don't
> otherwise behave any differently. Our primary focus is to protect
> applications that verify that the code is signed by someone they trust.
>
> Consider updating and re-signing your signed jar with a stronger,
> non-broken algorithm such as SHA-2. SHA-2 is the default digest
> algorithm used by jarsigner when the -digestalg option is not specified.
>
> I hope this information is useful. I do think this is an area where our
> javadocs and guides could be improved to provide more information about
> how signed JARs are verified including more details on the behavior of
> the JDK implementation with respect to disabled algorithms. We will be
> working to try to improve the docs for JDK 18.
>
> --Sean
>
> [1]
> https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/util/jar/JarFile.html
>
> [2]
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/conf/security/java.security#L667
>
> [3]
> https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#signed-jar-file
>
>
>
> On 10/28/21 3:14 PM, Rick Hillegas wrote:
>> As a canary in the mineshaft, I built and tested Apache Derby with the
>> recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
>> following issue when running Derby's regression tests. The problem is
>> explained in more detail at
>> https://issues.apache.org/jira/browse/DERBY-7126, where a simple repro
>> (DERBY_7126_A) can be found. The problem is almost surely the result of
>> work done on https://bugs.openjdk.java.net/browse/JDK-8269039 (Disable
>> SHA-1 Signed JARs).
>>
>> Under previous versions of the JDK, the JVM would raise an error if you
>> tried to load a class from a jar file which had been signed with SHA-1
>> but later hacked by inserting malware via "jar -uf". This was the error:
>>
>>     SHA1 digest error for $corruptedJarFileName
>>
>> However, under JDK 18 the hacked class loads, no error is raised, and
>> the malware can now be executed. I was surprised that a previously
>> prevented exploit now works. I think it would be better if the JVM still
>> refused to load the hacked class even though SHA-1 has been deprecated.
>>
>> Thanks,
>> -Rick
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211104/1835479a/attachment-0001.htm>

From david.holmes at oracle.com  Thu Nov  4 03:09:34 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Nov 2021 13:09:34 +1000
Subject: RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com>
Message-ID: <531451b4-b966-e2cb-91ca-52a825c84ad9@oracle.com>

On 4/11/2021 12:14 am, Pavel Rappo wrote:
> On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:
> 
>> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse?
>>
>> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
>>
>> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
>>
>>      $ sh ./bin/blessed-modifier-order.sh src/java.base
>>
>> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
>>
>> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
>> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
> 
>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_
>>
>> On 3/11/2021 9:26 pm, Pavel Rappo wrote:
>>
>>> On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:
>>>>>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
>>>>>
>>>>>
>>>>> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
>>>>>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
>>>>>
>>>>>
>>>>> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.
>>>>
>>>>
>>>> The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)
>>>> Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
>>>> I don't have a strong feeling either way on changing that file.
>>>> I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
>>>> I would also not update copyright years for such changes.
>>>> It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.
>>>
>>>
>>> One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49
>>> So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.**
>>
>> Line 281 is (was!) consistent with line 277 because it is distinguishing a synchronized "static method" from a synchronized "instance method". There was no need to make any change to line 281 because of the blessed-order of modifiers as defined for method declarations! This text is just prose. Now for consistency you should change line 277 to refer to a "non-static synchronized method" (as "instance synchronized method" would be truly awful).
> 
> Thanks, David. You've provided a clear and convincing argument, and I can see the inconsistency I introduced. I can revert that particular piece back if you think that it would be appropriate.
> 
> That said, this line will have to be filtered out every time the script is run. I could probably provide a more involved script that harnesses the power of AST (com.sun.source.doctree) to try to filter out prose, but it would be impossible to beat the simplicity of the current script; and simplicity is also important.

Given this is prose, the adjectives should be separated by commas: "a 
synchronized, static method", and "a synchronized, instance method". 
Does that avoid the problem with the script?

>> Line 49 places "static synchronized" in code font, implying that it is referring to the actual method modifiers and as such using the blessed order is appropriate. Line 49 does not need to be "consistent" with line 281. If line 49 used a normal font so the words "static" and "synchronized" were just prose then either order would be perfectly fine in terms of English language, but then you could make a case for having it be consistent with line 281.
> 
> I've been always having hard time with modifiers being not enclosed in `@code` in the first place; they are barely English words. Is there really a semantic difference between L49 and L281 such that it warrants the use of `@code` in the former but not in the latter case? Does `synchornized` or `static` in L281 refer to anything other than the like-named Java modifiers?

Consider this definition:

"A synchronized method is one which must acquire the monitor of the 
Object upon which the method is invoked, and is indicated by applying 
the {@code synchronized} modifier to the method declaration."

Here there is a distinction** between the general notion of a 
"synchronized method" and the "synchronized" modifier. Obviously they 
are strongly related, and often could be used interchangeably, but you 
can also find places where it is more appropriate to use one over the 
other. So yes it is hard, but context can influence the choice: is this 
text referring to the general concept of a synchronized/static method, 
or to the use of the modifier? Line 49 could have gone either way IMO.

** The distinction would be more obvious if Java had an implicit way to 
define synchronized methods. So think about the concept of "package 
private" access - there is no package-private modifier so you 
wouldn't/shouldn't ever write "package private" in code font.

Cheers,
David

P.S. For the book "The Java Programming Language" the authors made a 
very conscious decision to not put the word "synchronized" in code font 
every time it was used in the text, but reserved the code font for 
specific usages. The same applies to other modifiers: static, public, 
etc. Other authors have made similar decisions.

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6213
> 

From duke at openjdk.java.net  Thu Nov  4 10:43:10 2021
From: duke at openjdk.java.net (Lari Hotari)
Date: Thu, 4 Nov 2021 10:43:10 GMT
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <EQJ6Kp85RV4RfrjQ-YoIEYXjA6l9JBTNK6tyhJjVzD0=.b0e7f0ec-22b5-4a08-909c-d337f83e1590@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
 <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
 <7yURY4hNUZ2sEm88BfAwUqZabfaOIF1A6HZ7T_eHG54=.0303c17b-887c-44b9-928a-c8de4526b0c7@github.com>
 <EQJ6Kp85RV4RfrjQ-YoIEYXjA6l9JBTNK6tyhJjVzD0=.b0e7f0ec-22b5-4a08-909c-d337f83e1590@github.com>
Message-ID: <xGrjW__Ak7G7ZKZSb9AGyvZ3JSRm3ZIbcw-otsRZvdw=.358a6dda-027d-4504-9d12-42cc0a72685b@github.com>

On Wed, 3 Nov 2021 21:56:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> Hi @lhotari, please submit an OCA at https://oca.opensource.oracle.com/ if you are contributing on your own behalf. If you are contributing on your employers behalf, please send me an e-Mail at [dalibor.topic at oracle.com](mailto:dalibor.topic at oracle.com) so that I can verify your account.
>> 
>> @robilad This is a contribution on my own behalf. I have signed [OCA in 2014 while contributing to Btrace](https://github.com/btraceio/btrace/pull/101#issuecomment-63333404). Is that sufficient? I cannot sign OCA again online, it gives me an error message "The provided GitHub username lhotari does already appear in an existing OCA, please use another one.".
>
> @lhotari I think you have got the reason to create the BadPaddingExceptions.  Did you want to close this bug, or fix it alternativey without break the constant-time purpose?

@XueleiFan You are right. I'll follow up with a change which doesn't break the constant-time purpose.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581

From ihse at openjdk.java.net  Thu Nov  4 11:31:23 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 11:31:23 GMT
Subject: RFR: 8276632: Use blessed modifier order in security-libs code
Message-ID: <NJt0aIZXcfHOAiqzoLpLa_5TeUeGcc-Pzt9mL8ePdiY=.8c9d7f2f-98d9-4a71-a8f9-6e685a299193@github.com>

I ran bin/blessed-modifier-order.sh on source owned by security-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

-------------

Commit messages:
 - 8276632: Use blessed modifier order in security-libs code

Changes: https://git.openjdk.java.net/jdk/pull/6251/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6251&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276632
  Stats: 146 lines in 15 files changed: 0 ins; 0 del; 146 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6251.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6251/head:pull/6251

PR: https://git.openjdk.java.net/jdk/pull/6251

From mullan at openjdk.java.net  Thu Nov  4 13:24:16 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 4 Nov 2021 13:24:16 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v3]
In-Reply-To: <mwNLsVYGKEpcBiUXla7JN9FqldGR6F1oI4yDV4piYXo=.fcbdd558-4feb-481c-bddf-bc3fe9a18c17@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <mwNLsVYGKEpcBiUXla7JN9FqldGR6F1oI4yDV4piYXo=.fcbdd558-4feb-481c-bddf-bc3fe9a18c17@github.com>
Message-ID: <5QtoOPf7rvkJgu7pItFu_PXlKtnw7APts-tn0HU-7do=.72c27e0e-48ac-4831-b9f7-e59e793a2613@github.com>

On Wed, 3 Nov 2021 14:18:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more clear and precise spec

src/java.base/share/classes/java/security/KeyStore.java line 1027:

> 1025:      *
> 1026:      * @implSpec
> 1027:      * The default implementation returns an empty {@code Set}.

Would it make more sense for the default impl to throw `UnsupportedOperationException` or maybe call `getEntry(alias, null)`? Otherwise, an application cannot know the difference between an alias that has no attributes and an alias that has attributes but is from a `KeyStore` impl that has not overridden the corresponding Spi method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Thu Nov  4 13:48:21 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 4 Nov 2021 13:48:21 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v3]
In-Reply-To: <5QtoOPf7rvkJgu7pItFu_PXlKtnw7APts-tn0HU-7do=.72c27e0e-48ac-4831-b9f7-e59e793a2613@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <mwNLsVYGKEpcBiUXla7JN9FqldGR6F1oI4yDV4piYXo=.fcbdd558-4feb-481c-bddf-bc3fe9a18c17@github.com>
 <5QtoOPf7rvkJgu7pItFu_PXlKtnw7APts-tn0HU-7do=.72c27e0e-48ac-4831-b9f7-e59e793a2613@github.com>
Message-ID: <p0OYg0ICKQykGVMiocH_Z00Aa9kkTgVNGthXeXy3QfA=.ccd4bc5d-4d68-45c5-bcbd-f357e0f61d64@github.com>

On Thu, 4 Nov 2021 13:21:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more clear and precise spec
>
> src/java.base/share/classes/java/security/KeyStore.java line 1027:
> 
>> 1025:      *
>> 1026:      * @implSpec
>> 1027:      * The default implementation returns an empty {@code Set}.
> 
> Would it make more sense for the default impl to throw `UnsupportedOperationException` or maybe call `getEntry(alias, null)`? Otherwise, an application cannot know the difference between an alias that has no attributes and an alias that has attributes but is from a `KeyStore` impl that has not overridden the corresponding Spi method.

The one benefit I can think of to throw a UOE is that the caller can fallback to `getEntry(...).getAttributes()` when an exception is thrown. However, as far as I know, our PKCS12KeyStore is the only KeyStore implementation that has made use of attributes. Therefore it's still not late for another implementation to start supporting both at the same time. For most of the KeyStore implementations, both `ks.getAttributes()` and `ks.getEntry(...).getAttributes()` returning empty seems more consistent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From mullan at openjdk.java.net  Thu Nov  4 13:53:16 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 4 Nov 2021 13:53:16 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v3]
In-Reply-To: <p0OYg0ICKQykGVMiocH_Z00Aa9kkTgVNGthXeXy3QfA=.ccd4bc5d-4d68-45c5-bcbd-f357e0f61d64@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <mwNLsVYGKEpcBiUXla7JN9FqldGR6F1oI4yDV4piYXo=.fcbdd558-4feb-481c-bddf-bc3fe9a18c17@github.com>
 <5QtoOPf7rvkJgu7pItFu_PXlKtnw7APts-tn0HU-7do=.72c27e0e-48ac-4831-b9f7-e59e793a2613@github.com>
 <p0OYg0ICKQykGVMiocH_Z00Aa9kkTgVNGthXeXy3QfA=.ccd4bc5d-4d68-45c5-bcbd-f357e0f61d64@github.com>
Message-ID: <CmZ9znaP-4YuBWx4LoPnbYsGjQ1ssLyBwUETnA58KpQ=.8f34b7c4-1f0e-49c3-b6f4-21616d16bf98@github.com>

On Thu, 4 Nov 2021 13:44:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/KeyStore.java line 1027:
>> 
>>> 1025:      *
>>> 1026:      * @implSpec
>>> 1027:      * The default implementation returns an empty {@code Set}.
>> 
>> Would it make more sense for the default impl to throw `UnsupportedOperationException` or maybe call `getEntry(alias, null)`? Otherwise, an application cannot know the difference between an alias that has no attributes and an alias that has attributes but is from a `KeyStore` impl that has not overridden the corresponding Spi method.
>
> The one benefit I can think of to throw a UOE is that the caller can fallback to `getEntry(...).getAttributes()` when an exception is thrown. However, as far as I know, our PKCS12KeyStore is the only KeyStore implementation that has made use of attributes. Therefore it's still not late for another implementation to start supporting both at the same time. For most of the KeyStore implementations, both `ks.getAttributes()` and `ks.getEntry(...).getAttributes()` returning empty seems more consistent.

But we could just override those other implementations to always return an empty Set. I would prefer if an application could distinguish between these two cases w/o knowing whether the underlying implementation supports attributes or not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From rick.hillegas at gmail.com  Thu Nov  4 15:45:03 2021
From: rick.hillegas at gmail.com (Rick Hillegas)
Date: Thu, 4 Nov 2021 08:45:03 -0700
Subject: previously prevented exploit now possible with JDK 18
In-Reply-To: <AM9P193MB11424B8AC5C0AD1D0C45695FFF8D9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
 <00bad2ca-b90c-ac41-854f-ba5d1222fe32@oracle.com>
 <27683d47-c657-a111-2f08-f9d12009a422@gmail.com>
 <AM9P193MB11424B8AC5C0AD1D0C45695FFF8D9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <79324013-d605-a3ab-7144-b09a3f10b817@gmail.com>

Thanks for thinking about this issue, Bernd. The case I am thinking 
about is an application which verifies the identity of the signer but 
which lets the classloader verify the checksum.

On 11/3/21 5:16 PM, Bernd Eckenfels wrote:
> Rick if you fear an attacker can modify and install a JAR with a broken signature which you don?t trust anyway, what should stop the attacker to provide a valid but untrusted signature or no checksums at all? It might be a undesirable change for your case but I see no trustmodel where you would need default java classloader to do more than treating it unsigned.
>
> But if you really want to re-enable SHA1 you can do so (or implement a classloader which rejects any SHA1 codebases). Of course much easier would be to only install verified jars.
>
> BTW the fact that you actually get answers about a weakness report is amazing :)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Rick Hillegas <rick.hillegas at gmail.com>
> Gesendet: Wednesday, November 3, 2021 6:07:00 PM
> An: Sean Mullan <sean.mullan at oracle.com>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: previously prevented exploit now possible with JDK 18
>
> Thanks for your detailed comments, Sean. We agree wholeheartedly that
> being signed and being trusted/valid are two separate concepts. The JDK
> wisely punts the issue of trust to the application developer. As I
> understand it, we disagree about the following points:
>
> 1) Is the signedness of a jar an immutable fact or is it just an
> opinion? I think that it is an immutable fact, measured by whether the
> jar's manifest contains certain stereotypical files. You maintain that
> it is an opinion which can shift incompatibly between JDK releases.
>
> 2) Should the JDK continue to raise an exception when loading classes
> from clearly compromised jars?
>
> 3) Are javadoc and a release note adequate defenses against an exploit
> which will surface when a mission-critical application upgrades to a JDK
> containing the work on https://bugs.openjdk.java.net/browse/JDK-8269039 ?
>
> Here's how I see it:
>
> a) A jar doesn't cease to be signed when its signer goes to jail and
> authorities revoke the signing certificate.
>
> b) A jar doesn't cease to be signed because someone pokes malware into
> it and breaks the hash.
>
> c) A jar doesn't cease to be signed because serious people distrust its
> old, shoddy cryptography.
>
> In all of these cases, trust has diminished. But the jar is still signed.
>
> Note that the emphatic deprecation of the SecurityManager affects your
> comments below.
>
> Thanks,
> -Rick
>
>
> On 11/2/21 11:34 AM, Sean Mullan wrote:
>> Hello Rick,
>>
>> It is behaving as expected. Let me explain in more detail.
>>
>> First, loading a signed JAR off the classpath only verifies the
>> signature and digests of the JAR file. It does not validate the signer's
>> certificate chain or determine if the signer is trusted. The JarFile API
>> class description includes this warning [1]:
>>
>> "Please note that the verification process does not include validating
>> the signer's certificate. A caller should inspect the return value of
>> JarEntry.getCodeSigners() to further determine if the signature can be
>> trusted."
>>
>> Some frameworks such as Web Start have this additional checking
>> built-in. Or, if you run your code with a Security Manager, then
>> additional steps will be performed at run-time to check that the code is
>> signed and that the signer's public key is trusted before granting
>> permissions to that code.
>>
>> If you don't perform these additional steps, then the JAR can be
>> modified without detection. For example, the signature related files
>> could be removed from the JAR (thus making it an unsigned JAR), or the
>> JAR could be modified and then re-signed with a different key. In either
>> of these cases, the JVM would load the JAR without any exception.
>>
>> It is also possible that a JAR signed with a weak or broken algorithm
>> (such as MD5 or SHA-1) could be modified without detection.
>>
>> This is why the JDK implementation supports several security
>> properties which are used to disable cryptographic algorithms and
>> protocols that are weak or broken. This provides out-of-the-box security
>> and is important to safeguard against crypto algorithms that inevitably
>> become weaker over time. One of these properties is
>> "jdk.jar.disabledAlgorithms". The specification of this property defines
>> the behavior if a signed JAR file is signed with an algorithm that is
>> disabled [2]:
>>
>> "JARs signed with any of the disabled algorithms or key sizes will be
>> treated as unsigned."
>>
>> The JDK determined after step 1 of the JAR verification process [3] that
>> the JAR was signed with SHA-1, and therefore stopped further processing.
>>
>> You may ask why we don't throw an Exception in this case. Although this
>> was considered, the compatibility risk was too high. These
>> restrictions are nearly always backported to earlier JDK update
>> releases. Throwing an Exception would be too high of a risk for
>> applications that happen to load signed JARs off the classpath but don't
>> otherwise behave any differently. Our primary focus is to protect
>> applications that verify that the code is signed by someone they trust.
>>
>> Consider updating and re-signing your signed jar with a stronger,
>> non-broken algorithm such as SHA-2. SHA-2 is the default digest
>> algorithm used by jarsigner when the -digestalg option is not specified.
>>
>> I hope this information is useful. I do think this is an area where our
>> javadocs and guides could be improved to provide more information about
>> how signed JARs are verified including more details on the behavior of
>> the JDK implementation with respect to disabled algorithms. We will be
>> working to try to improve the docs for JDK 18.
>>
>> --Sean
>>
>> [1]
>> https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/util/jar/JarFile.html
>>
>> [2]
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/conf/security/java.security#L667
>>
>> [3]
>> https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#signed-jar-file
>>
>>
>>
>> On 10/28/21 3:14 PM, Rick Hillegas wrote:
>>> As a canary in the mineshaft, I built and tested Apache Derby with the
>>> recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
>>> following issue when running Derby's regression tests. The problem is
>>> explained in more detail at
>>> https://issues.apache.org/jira/browse/DERBY-7126, where a simple repro
>>> (DERBY_7126_A) can be found. The problem is almost surely the result of
>>> work done on https://bugs.openjdk.java.net/browse/JDK-8269039 (Disable
>>> SHA-1 Signed JARs).
>>>
>>> Under previous versions of the JDK, the JVM would raise an error if you
>>> tried to load a class from a jar file which had been signed with SHA-1
>>> but later hacked by inserting malware via "jar -uf". This was the error:
>>>
>>>      SHA1 digest error for $corruptedJarFileName
>>>
>>> However, under JDK 18 the hacked class loads, no error is raised, and
>>> the malware can now be executed. I was surprised that a previously
>>> prevented exploit now works. I think it would be better if the JVM still
>>> refused to load the hacked class even though SHA-1 has been deprecated.
>>>
>>> Thanks,
>>> -Rick
>>>
>


From ihse at openjdk.java.net  Thu Nov  4 17:21:40 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:21:40 GMT
Subject: RFR: 8276632: Use blessed modifier order in security-libs code
 [v2]
In-Reply-To: <NJt0aIZXcfHOAiqzoLpLa_5TeUeGcc-Pzt9mL8ePdiY=.8c9d7f2f-98d9-4a71-a8f9-6e685a299193@github.com>
References: <NJt0aIZXcfHOAiqzoLpLa_5TeUeGcc-Pzt9mL8ePdiY=.8c9d7f2f-98d9-4a71-a8f9-6e685a299193@github.com>
Message-ID: <aZK3lCxehLG64lZHGti89wibn0gB0V3Ie20hNT6qUc4=.e6e8417a-7443-4894-b218-417b4b332833@github.com>

> I ran bin/blessed-modifier-order.sh on source owned by security-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6251/files
  - new: https://git.openjdk.java.net/jdk/pull/6251/files/94f99ac7..6f336e9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6251&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6251&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6251.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6251/head:pull/6251

PR: https://git.openjdk.java.net/jdk/pull/6251

From weijun at openjdk.java.net  Thu Nov  4 19:34:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 4 Nov 2021 19:34:52 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v3]
In-Reply-To: <mwNLsVYGKEpcBiUXla7JN9FqldGR6F1oI4yDV4piYXo=.fcbdd558-4feb-481c-bddf-bc3fe9a18c17@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <mwNLsVYGKEpcBiUXla7JN9FqldGR6F1oI4yDV4piYXo=.fcbdd558-4feb-481c-bddf-bc3fe9a18c17@github.com>
Message-ID: <q00uYAACihQepFVcPU5jzNQIcBXZ9uQxtUpnxi5BWCg=.61e7a5ff-98be-4a0d-9da8-ad72054698e4@github.com>

On Wed, 3 Nov 2021 14:18:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more clear and precise spec

New commit pushed. Typo, I meant "refine".

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Thu Nov  4 19:34:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 4 Nov 2021 19:34:50 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v4]
In-Reply-To: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
Message-ID: <pxu-nUyqjSGl4cmO_uuq-8-z3rF8bqacbUOAAHu77JQ=.24e240f1-6390-45aa-ad79-afcbca8cfa08@github.com>

> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  redine spec

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6026/files
  - new: https://git.openjdk.java.net/jdk/pull/6026/files/aaaa6145..901bdf83

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=02-03

  Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6026/head:pull/6026

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Thu Nov  4 22:11:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 4 Nov 2021 22:11:41 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v5]
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  tiny spec change to be the same as CSR

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5024/files
  - new: https://git.openjdk.java.net/jdk/pull/5024/files/a9380c0b..8d547bbd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5024&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5024&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5024.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5024/head:pull/5024

PR: https://git.openjdk.java.net/jdk/pull/5024

From mstjohns at comcast.net  Fri Nov  5 01:13:14 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 4 Nov 2021 21:13:14 -0400
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <7yURY4hNUZ2sEm88BfAwUqZabfaOIF1A6HZ7T_eHG54=.0303c17b-887c-44b9-928a-c8de4526b0c7@github.com>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
 <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
 <7yURY4hNUZ2sEm88BfAwUqZabfaOIF1A6HZ7T_eHG54=.0303c17b-887c-44b9-928a-c8de4526b0c7@github.com>
Message-ID: <2169e509-9f0d-4704-1ae3-23986102dd18@comcast.net>

On 11/3/2021 3:03 PM, Lari Hotari wrote:
> On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari <duke at openjdk.java.net> wrote:
>
>>> ### Motivation
>>>
>>> When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code in RSAPadding, one can see that BadPaddingException is created in all cases, also on the success path:
>>> https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375
>>>
>>> ### Modifications
>>>
>>> Inline the unnecessary local variable to prevent creating the exception on the success path.
>> For anyone interested, there's an explanation of the [Bleichenbacher's CCA attack on PKCS#1 v1.5 on Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5). The original paper is ["Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" ](http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf).
>>
>> The reason for constant time is to not leak information about a possible bad padding to the attacker based on the difference in response time between a valid and bad padding. The attacker can use this information to narrow the search to find the pre-master secret.
>> Hi @lhotari, please submit an OCA at https://oca.opensource.oracle.com/ if you are contributing on your own behalf. If you are contributing on your employers behalf, please send me an e-Mail at [dalibor.topic at oracle.com](mailto:dalibor.topic at oracle.com) so that I can verify your account.
> @robilad This is a contribution on my own behalf. I have signed [OCA in 2014 while contributing to Btrace](https://github.com/btraceio/btrace/pull/101#issuecomment-63333404). Is that sufficient? I cannot sign OCA again online, it gives me an error message "The provided GitHub username lhotari does already appear in an existing OCA, please use another one.".
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/5581

Hi -

If you're trying for constant time, you might be defeated by the "if" at 
line 460 and the blank line ("// continue;") at 462.?? As well as the if 
clause at 450.

Maybe:

int zeroCount = 0;
 ?int msgZeroCount = 0;

 ?int mlenCount = 0;
 ?int msgOne = 0;

 ?int oneFlag = 0;

 ?int bpcount = -1;

 ?boolean logicNotBp = false;

 ?// substitute for 450-451
 ?if (lHash[i] != EM[dbStart + i]) {
 ?? bp = true;
 ?} else {
 ?? logicNotBp = true;
 ?}

// add at line 454

 ?if (logicNotBp) {
 ?? bpcount = 0;
 ?}

 ?if (bp) {
 ?? bpcount= 1;
 ?}

The above is a bit convoluted, but makes sure you have the same number 
and type of operations regardless of whether or not there is a match at 
any given position. bpcount will be set to 1 if any of the bytes don't 
match.? This shouldn't be optimized out


 ?// substitute for 458-469

 ?for (int i = padStart; i < EM.length; i++) {
 ?? int value = EM[i];
 ?? if (oneFlag != 0) {
 ???? switch (value) {
 ??????? case 0x00:
 ????????? zeroCount++;
 ????????? break;
 ??????? case 0x01:
 ????????? oneFlag++;
 ????????? break;
 ??????? default:
 ????????? bpcount++;
 ????? }

 ?? } else {
 ???? switch (value) {
 ?????? case 0x00:
 ???????? msgZeroCount++;
 ???????? break;
 ?????? case 0x01:
 ???????? msgOne++;
 ???????? break;
 ?????? default:
 ???????? mlenCount++;
 ???? }
 ?? }
 ?}



 ?bp = (bpcount >= 1);
 ?mlenCount = otherZeroCount + dupOne + mlenCount;

This allows you to add an additional check for consistency - mlenCount + 
zeroCount + 1 should equal EM.length - padStart. Checking those will 
prevent the optimizer from optimizing out the code above.

I used switch instead of if/else/else because its usually closer to 
constant time and each of the branches are increments.

FYI - I do have a signed contributor agreement from oracle days, but 
lack time to do this against a build environment.

Mike



From mstjohns at comcast.net  Fri Nov  5 02:19:40 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 4 Nov 2021 22:19:40 -0400
Subject: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in
 RSAPadding
In-Reply-To: <2169e509-9f0d-4704-1ae3-23986102dd18@comcast.net>
References: <9cF2-qWd03Rzdud6517knyJWGhxxSuv1VwZgvFY43L8=.02b4a0d2-59be-46ab-a857-13271679097e@github.com>
 <qjSCWGetcQL7utLIzFNYSv7itLV-3yMcVcam3NBI6Ns=.d75377ec-5825-495f-9649-8fe35febc4f0@github.com>
 <7yURY4hNUZ2sEm88BfAwUqZabfaOIF1A6HZ7T_eHG54=.0303c17b-887c-44b9-928a-c8de4526b0c7@github.com>
 <2169e509-9f0d-4704-1ae3-23986102dd18@comcast.net>
Message-ID: <9a504c76-1d42-e948-6c4b-e1ebc777912b@comcast.net>

On 11/4/2021 9:13 PM, Michael StJohns wrote:
> On 11/3/2021 3:03 PM, Lari Hotari wrote:
>> On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari <duke at openjdk.java.net> 
>> wrote:
>>
>>>> ### Motivation
>>>>
>>>> When profiling an application that uses JWT token authentication, 
>>>> it was noticed that a high number of 
>>>> `javax.crypto.BadPaddingException`s were created. When 
>>>> investigating the code in RSAPadding, one can see that 
>>>> BadPaddingException is created in all cases, also on the success path:
>>>> https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375 
>>>>
>>>>
>>>> ### Modifications
>>>>
>>>> Inline the unnecessary local variable to prevent creating the 
>>>> exception on the success path.
>>> For anyone interested, there's an explanation of the 
>>> [Bleichenbacher's CCA attack on PKCS#1 v1.5 on 
>>> Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5). 
>>> The original paper is ["Chosen Ciphertext Attacks Against Protocols 
>>> Based on the RSA Encryption Standard PKCS #1" 
>>> ](http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf).
>>>
>>> The reason for constant time is to not leak information about a 
>>> possible bad padding to the attacker based on the difference in 
>>> response time between a valid and bad padding. The attacker can use 
>>> this information to narrow the search to find the pre-master secret.
>>> Hi @lhotari, please submit an OCA at 
>>> https://oca.opensource.oracle.com/ if you are contributing on your 
>>> own behalf. If you are contributing on your employers behalf, please 
>>> send me an e-Mail at 
>>> [dalibor.topic at oracle.com](mailto:dalibor.topic at oracle.com) so that 
>>> I can verify your account.
>> @robilad This is a contribution on my own behalf. I have signed [OCA 
>> in 2014 while contributing to 
>> Btrace](https://github.com/btraceio/btrace/pull/101#issuecomment-63333404). 
>> Is that sufficient? I cannot sign OCA again online, it gives me an 
>> error message "The provided GitHub username lhotari does already 
>> appear in an existing OCA, please use another one.".
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/5581
>
> Hi -
>
> If you're trying for constant time, you might be defeated by the "if" 
> at line 460 and the blank line ("// continue;") at 462.?? As well as 
> the if clause at 450.
>
> Maybe:
>
> int zeroCount = 0;
> ?int msgZeroCount = 0;
>
> ?int mlenCount = 0;
> ?int msgOne = 0;
>
> ?int oneFlag = 0;
>
> ?int bpcount = -1;
>
> ?boolean logicNotBp = false;
>
> ?// substitute for 450-451
> ?if (lHash[i] != EM[dbStart + i]) {
> ?? bp = true;
> ?} else {
> ?? logicNotBp = true;
> ?}
>
> // add at line 454
>
> ?if (logicNotBp) {
> ?? bpcount = 0;
> ?}
>
> ?if (bp) {
> ?? bpcount= 1;
> ?}
>
> The above is a bit convoluted, but makes sure you have the same number 
> and type of operations regardless of whether or not there is a match 
> at any given position. bpcount will be set to 1 if any of the bytes 
> don't match.? This shouldn't be optimized out
>
>
> ?// substitute for 458-469
>
> ?for (int i = padStart; i < EM.length; i++) {
> ?? int value = EM[i];
> ?? if (oneFlag != 0) {
if (oneFlag == 0) {? // sorry about that.
> switch (value) {
> ??????? case 0x00:
> ????????? zeroCount++;
> ????????? break;
> ??????? case 0x01:
> ????????? oneFlag++;
> ????????? break;
> ??????? default:
> ????????? bpcount++;
> ????? }
>
> ?? } else {
> ???? switch (value) {
> ?????? case 0x00:
> ???????? msgZeroCount++;
> ???????? break;
> ?????? case 0x01:
> ???????? msgOne++;
> ???????? break;
> ?????? default:
> ???????? mlenCount++;
> ???? }
> ?? }
> ?}
>
>
>
> ?bp = (bpcount >= 1);
> ?mlenCount = otherZeroCount + dupOne + mlenCount;
>
> This allows you to add an additional check for consistency - mlenCount 
> + zeroCount + 1 should equal EM.length - padStart. Checking those will 
> prevent the optimizer from optimizing out the code above.
>
> I used switch instead of if/else/else because its usually closer to 
> constant time and each of the branches are increments.
>
> FYI - I do have a signed contributor agreement from oracle days, but 
> lack time to do this against a build environment.
>
> Mike
>
>


From mcimadamore at openjdk.java.net  Fri Nov  5 11:06:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 5 Nov 2021 11:06:53 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v18]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Add two new CLinker static methods to compute upcall/downcall method types
  * Clarify section on CLinker downcall type
  * Add section on CLinker safety guarantees

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/b9432473..ce561e1f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=16-17

  Stats: 79 lines in 3 files changed: 47 ins; 17 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Fri Nov  5 11:30:59 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 5 Nov 2021 11:30:59 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v19]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <wvROJ-xKOsnrsOl2uIL98pouvLignJGoNuiZ9RhnT-E=.b2800aa4-fd0c-4e32-a3d6-88c1247fcf8b@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Streamline javadoc for package-info

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/ce561e1f..350f1f07

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=17-18

  Stats: 37 lines in 1 file changed: 9 ins; 3 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Fri Nov  5 11:37:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 5 Nov 2021 11:37:57 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v20]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <1EDavlhSqnzIbpu1uQArxPknmjIMaeQEoPV8W1T3UjE=.9a5dcd88-0cc7-4965-b2b7-3cccaf70b50e@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress
  (which is consistent with other restricted factories in VaList and NativeSymbol)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/350f1f07..663e72a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=18-19

  Stats: 51 lines in 23 files changed: 0 ins; 3 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Fri Nov  5 11:54:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 5 Nov 2021 11:54:14 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v12]
In-Reply-To: <UX8V13GkspdQyaQurhAql9BaZiAQH5klYW8GyZiRJ-g=.17702d38-a07e-4596-af99-2fcb5243862c@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <LZdOj0F56w1jvphEqwIPKjBGVqK9bK18hoyBRS7LvH8=.28940500-42f1-4550-94ab-4dc090785924@github.com>
 <UX8V13GkspdQyaQurhAql9BaZiAQH5klYW8GyZiRJ-g=.17702d38-a07e-4596-af99-2fcb5243862c@github.com>
Message-ID: <QZeHdQOpqqH2mQBQ11F1wKLV6i68XxxXAfn02eqfvZA=.c882ffe7-bab2-4664-b6ea-81fef94054aa@github.com>

On Tue, 2 Nov 2021 15:40:45 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak javadoc of loaderLookup
>
> Marked as reviewed by psandoz (Reviewer).

I have made some minor API changes (added two methods to `CLinker` to return the upcall and downcall method types, as suggested offline by @PaulSandoz). I've also cleaned up the `CLinker` javadoc, and added a section on safety consideration, streamlined the links in the package-level javadoc and renamed `MemorySegment::ofAddressNative` to simply `MemorySegment::ofAddress` (which is consistent with restricted factories in `NativeSymbol` and `VaList`).

javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-419/v2/javadoc/jdk/incubator/foreign/package-summary.html
specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-419/v2/specdiff_out/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From ihse at openjdk.java.net  Fri Nov  5 12:08:12 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 12:08:12 GMT
Subject: RFR: 8276632: Use blessed modifier order in security-libs code
 [v2]
In-Reply-To: <aZK3lCxehLG64lZHGti89wibn0gB0V3Ie20hNT6qUc4=.e6e8417a-7443-4894-b218-417b4b332833@github.com>
References: <NJt0aIZXcfHOAiqzoLpLa_5TeUeGcc-Pzt9mL8ePdiY=.8c9d7f2f-98d9-4a71-a8f9-6e685a299193@github.com>
 <aZK3lCxehLG64lZHGti89wibn0gB0V3Ie20hNT6qUc4=.e6e8417a-7443-4894-b218-417b4b332833@github.com>
Message-ID: <Af5RSkejySaLniooHQzT5gUKyFCGTG0g48mYQS_KTG4=.d51ffb24-99ab-4d76-aab0-52a60d33450e@github.com>

On Thu, 4 Nov 2021 17:21:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by security-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Any reviewers? This is fairly trivial.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6251

From mullan at openjdk.java.net  Fri Nov  5 13:53:10 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 5 Nov 2021 13:53:10 GMT
Subject: RFR: 8276632: Use blessed modifier order in security-libs code
 [v2]
In-Reply-To: <aZK3lCxehLG64lZHGti89wibn0gB0V3Ie20hNT6qUc4=.e6e8417a-7443-4894-b218-417b4b332833@github.com>
References: <NJt0aIZXcfHOAiqzoLpLa_5TeUeGcc-Pzt9mL8ePdiY=.8c9d7f2f-98d9-4a71-a8f9-6e685a299193@github.com>
 <aZK3lCxehLG64lZHGti89wibn0gB0V3Ie20hNT6qUc4=.e6e8417a-7443-4894-b218-417b4b332833@github.com>
Message-ID: <iJRh9zYQXlsTh7oC2fa1jGuSK_RvH2aAHGStJrhrQ80=.dd30a9a4-cef7-4ff6-90d1-c56a5c64e39e@github.com>

On Thu, 4 Nov 2021 17:21:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by security-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6251

From ihse at openjdk.java.net  Fri Nov  5 14:13:21 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 14:13:21 GMT
Subject: Integrated: 8276632: Use blessed modifier order in security-libs code
In-Reply-To: <NJt0aIZXcfHOAiqzoLpLa_5TeUeGcc-Pzt9mL8ePdiY=.8c9d7f2f-98d9-4a71-a8f9-6e685a299193@github.com>
References: <NJt0aIZXcfHOAiqzoLpLa_5TeUeGcc-Pzt9mL8ePdiY=.8c9d7f2f-98d9-4a71-a8f9-6e685a299193@github.com>
Message-ID: <6-PrVneKkmibw73drE586StTGrediZXHqqq0SSuo1ME=.7bfb3e84-e9cf-443f-82dc-069bb3b5c4b4@github.com>

On Thu, 4 Nov 2021 11:19:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by security-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

This pull request has now been integrated.

Changeset: c393ee8f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c393ee8f598850379266bdba1f55af94744dbad1
Stats:     153 lines in 15 files changed: 0 ins; 0 del; 153 mod

8276632: Use blessed modifier order in security-libs code

Reviewed-by: mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/6251

From jvernee at openjdk.java.net  Fri Nov  5 14:29:19 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 5 Nov 2021 14:29:19 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v18]
In-Reply-To: <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com>
Message-ID: <VaFgr9j0KCMW5_zyWLdUizp_oVTQ2wQDw80reGsrncc=.cc8aeca8-f65d-4655-a8c3-da1198e7b602@github.com>

On Fri, 5 Nov 2021 11:06:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Add two new CLinker static methods to compute upcall/downcall method types
>   * Clarify section on CLinker downcall type
>   * Add section on CLinker safety guarantees

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 65:

> 63:  * <li>if {@code L} is a {@link ValueLayout} with carrier {@code E} then there are two cases:
> 64:  *     <ul>
> 65:  *         <li>if {@code L} occurs in a parameter position and {@code E} is {@code NativeAddress.class},

This looks spurious

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 134:

> 132:  * <p>
> 133:  * Upcall stubs are generally safer to work with, as the linker runtime can validate the type of the target method
> 134:  * handle against the provided function descriptor and report an error if any mismatch is detected. If the target method

But, in the case of upcalls, errors can still occur if the native code casts the pointer to the upcall stub to an incorrect type, e.g. `FunctionDescriptor.ofVoid(ADDRESS, ADDRESS)`, but on the native side cast it to `void (*)(void*)`, meaning the second argument would be garbage on the Java side. i.e. there is still room for a mismatch the same as with downcalls.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 267:

> 265:     static MethodType upcallType(FunctionDescriptor functionDescriptor) {
> 266:         return SharedUtils.inferMethodType(functionDescriptor, true);
> 267:     }

Nice! :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Fri Nov  5 14:37:23 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 5 Nov 2021 14:37:23 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v18]
In-Reply-To: <VaFgr9j0KCMW5_zyWLdUizp_oVTQ2wQDw80reGsrncc=.cc8aeca8-f65d-4655-a8c3-da1198e7b602@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com>
 <VaFgr9j0KCMW5_zyWLdUizp_oVTQ2wQDw80reGsrncc=.cc8aeca8-f65d-4655-a8c3-da1198e7b602@github.com>
Message-ID: <z_is0y7ChExhNkR5zBq_fkBFCcCrqKkQGJg94ANBdD4=.0a8212a2-2f54-4b56-83e2-67ab3c53c66d@github.com>

On Fri, 5 Nov 2021 14:25:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Add two new CLinker static methods to compute upcall/downcall method types
>>   * Clarify section on CLinker downcall type
>>   * Add section on CLinker safety guarantees
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 134:
> 
>> 132:  * <p>
>> 133:  * Upcall stubs are generally safer to work with, as the linker runtime can validate the type of the target method
>> 134:  * handle against the provided function descriptor and report an error if any mismatch is detected. If the target method
> 
> But, in the case of upcalls, errors can still occur if the native code casts the pointer to the upcall stub to an incorrect type, e.g. `FunctionDescriptor.ofVoid(ADDRESS, ADDRESS)`, but on the native side cast it to `void (*)(void*)`, meaning the second argument would be garbage on the Java side. i.e. there is still room for a mismatch the same as with downcalls.

Yes and no. In a downcall, you just don't know what signature the downcall will feature in the native lib. So you pass a function descriptor and you hope it's ok. In the upcall case you _do_ know the signature of the Java upcall code you want to call, so you can validate the descriptor against that. Of course the native code can still cast things around in ways that blow things up, but the two problems seem somewhat different, at least to me. But I can tweak the text a bit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Fri Nov  5 15:28:45 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 5 Nov 2021 15:28:45 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v21]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <_YLlQk23TfRkCzouXvgHH3Zxktw1sxo1uvae5KsjlFw=.3c4f3aeb-e24f-424b-94f4-04b19f0e834b@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Clarify safety considerations for upcalls

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/663e72a8..2aa126a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=19-20

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From jvernee at openjdk.java.net  Fri Nov  5 15:52:16 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 5 Nov 2021 15:52:16 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v18]
In-Reply-To: <z_is0y7ChExhNkR5zBq_fkBFCcCrqKkQGJg94ANBdD4=.0a8212a2-2f54-4b56-83e2-67ab3c53c66d@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com>
 <VaFgr9j0KCMW5_zyWLdUizp_oVTQ2wQDw80reGsrncc=.cc8aeca8-f65d-4655-a8c3-da1198e7b602@github.com>
 <z_is0y7ChExhNkR5zBq_fkBFCcCrqKkQGJg94ANBdD4=.0a8212a2-2f54-4b56-83e2-67ab3c53c66d@github.com>
Message-ID: <B_3QI_9_jBQ9_5pfkQksCrCAA3NM_-loFl7R9m4-FNY=.3eb09f05-f6eb-4b14-8a29-d3e050b42ac9@github.com>

On Fri, 5 Nov 2021 14:33:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 134:
>> 
>>> 132:  * <p>
>>> 133:  * Upcall stubs are generally safer to work with, as the linker runtime can validate the type of the target method
>>> 134:  * handle against the provided function descriptor and report an error if any mismatch is detected. If the target method
>> 
>> But, in the case of upcalls, errors can still occur if the native code casts the pointer to the upcall stub to an incorrect type, e.g. `FunctionDescriptor.ofVoid(ADDRESS, ADDRESS)`, but on the native side cast it to `void (*)(void*)`, meaning the second argument would be garbage on the Java side. i.e. there is still room for a mismatch the same as with downcalls.
>
> Yes and no. In a downcall, you just don't know what signature the downcall will feature in the native lib. So you pass a function descriptor and you hope it's ok. In the upcall case you _do_ know the signature of the Java upcall code you want to call, so you can validate the descriptor against that. Of course the native code can still cast things around in ways that blow things up, but the two problems seem somewhat different, at least to me. But I can tweak the text a bit.

Ok, thanks.

I think of it more like this: in both cases we specify a native type as well as a Java type, both in the form of a FunctionDescriptor, from which we then derive the Java type in the form of a MethodType. If there is a mismatch here with what the native code does we are in trouble, this seems the same for downcalls and upcalls. In both cases we know the Java side for sure, it's the native side we can't validate (they are just flipped around for upcalls).

But, for upcalls there is an additional thing that can go wrong: the type of the target MethodHandle we pass could have a mismatch with the type we inferred from the FunctionDescriptor, so there we need to do an extra check. i.e. in a way this seems _less_ safe (though a different kind of safety), than downcalls, since there is an additional way to mess up with the linkage request, although we can catch that case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Fri Nov  5 16:02:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 5 Nov 2021 16:02:43 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v22]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <C26kQ22eRpl5GkWQTPML0L7I5QeQDavEtZA3Y9wXz74=.5585b09d-d131-43d8-a1cf-04b089679fb4@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Further tweak upcall safety considerations

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/2aa126a9..4e3af9f1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=20-21

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From jnimeh at openjdk.java.net  Fri Nov  5 17:23:40 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Fri, 5 Nov 2021 17:23:40 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v4]
In-Reply-To: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
Message-ID: <QoatBBkSqqk_yyHkiYANpMiBNipHpP3WzE0i-N9XD1M=.09dca45a-c2b4-4723-bc03-daf96a3f7120@github.com>

> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Do not reinstantiate SSLContext, add more iterations, add test batch without using session tickets

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6197/files
  - new: https://git.openjdk.java.net/jdk/pull/6197/files/a68781f2..5ddd0535

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=02-03

  Stats: 20 lines in 1 file changed: 12 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6197/head:pull/6197

PR: https://git.openjdk.java.net/jdk/pull/6197

From mullan at openjdk.java.net  Fri Nov  5 17:41:21 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 5 Nov 2021 17:41:21 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v5]
In-Reply-To: <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
Message-ID: <D0ul31Hz-HhQijXDZCHD-gl2aAbF5lR3PuhTTpvPcf4=.66e84649-7c78-4dff-beba-9347bebfbbb3@github.com>

On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny spec change to be the same as CSR

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java line 69:

> 67:         ServiceCreds creds = null;
> 68:         try {
> 69:             creds = AccessController.doPrivilegedWithCombiner(

Suggest adding a comment here and other places briefly explaining why doPrivWithCombiner is now needed to preserve the SubjectDomainCombiner.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From cverghese at openjdk.java.net  Fri Nov  5 17:47:56 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Fri, 5 Nov 2021 17:47:56 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
 <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
Message-ID: <9_u8aT5JHfhC9ftYtZ3PPXUK5-nc_5xktND_bRJV798=.0dc65dd3-6a78-48b1-86d6-5ed43e245447@github.com>

On Sat, 30 Oct 2021 04:57:22 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
>> 
>>  - 8274308: Improve efficiency for HandshakeContext initialization
>>  - Add SSLEngineBenchmark
>>  - Benchmark
>
> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 74:
> 
>> 72:                     "sun.security.ssl.allowLegacyHelloMessages", true);
>> 73: 
>> 74:     static Cache<Double, HandshakeContextCacheItem> handshakeContextCache;
> 
> I think I understand the motivation, but a mutable cache in handshake context does not sound like the right direction.  A cache could impact the performance more and occupy additional memories , because we have to synchronizing the access to the cache.  Maybe, you could to benchmark the maximum operations allowed per seconds, and try to use more complex cases, and see what the result could be.
> 
> I did not yet try to find an improvement yet.  But at this moment, the idea to me is to thinking about the TLS user cases.  It is common that applications use one instance of SSLContext and default configurations.  From the SSLContext instance, with the default configuration, the connections get established.  Normally, we don't recommend to set protocols and cipher suites other than the default SSLContex configuration, because it is not algorithm aglity.  So, it may be a direction to have the default and final active protocols and cipher suites, parsed and cached in SSLContext.  Just for your reference if you want a further improvement.

Hi @XueleiFan,

Thank you for the feedback, though it?s not recommended to set the protocols and cipher suites, various frameworks often do set these values, [Some references below]. Would it still make sense to only optimize the default case?. With my first variation, I had tried to avoid using the cache. However, The particular implementations had it drawbacks.

I have run some benchmarks, by rerunning the SSLStartHandshake Benchmark by increasing the concurrency to Threads.MAX and increasing the number of iterations for warmup and measurement. This triggers the concurrency effects of the cache, and here are my findings.

Baseline measurement (The default at origin/master)

Benchmark                                   Mode  Cnt   Score   Error   Units
SSLStartHandshake.handshakeBenchmark       thrpt  150   1.056 ? 0.048  ops/ms
SSLStartHandshake.handshakeBenchmark        avgt  150  13.198 ? 3.688   ms/op

Result "org.openjdk.bench.java.security.SSLStartHandshake.handshakeBenchmark":
  1.056 ?(99.9%) 0.048 ops/ms [Average]
  (min, avg, max) = (0.254, 1.056, 1.194), stdev = 0.174
  CI (99.9%): [1.008, 1.103] (assumes normal distribution)

Result "org.openjdk.bench.java.security.SSLStartHandshake.handshakeBenchmark":
  13.198 ?(99.9%) 3.688 ms/op [Average]
  (min, avg, max) = (10.128, 13.198, 106.039), stdev = 13.454
  CI (99.9%): [9.510, 16.886] (assumes normal distribution)


Cache implementation according to this PR with synchronization.

Benchmark                                   Mode  Cnt   Score   Error   Units
SSLStartHandshake.handshakeBenchmark       thrpt  150   1.098 ? 0.079  ops/ms
SSLStartHandshake.handshakeBenchmark        avgt  150  16.640 ? 6.784   ms/op

Result "org.openjdk.bench.java.security.SSLStartHandshake.handshakeBenchmark":
  1.098 ?(99.9%) 0.079 ops/ms [Average]
  (min, avg, max) = (0.087, 1.098, 1.272), stdev = 0.288
  CI (99.9%): [1.019, 1.177] (assumes normal distribution)

Result "org.openjdk.bench.java.security.SSLStartHandshake.handshakeBenchmark":
  16.640 ?(99.9%) 6.784 ms/op [Average]
  (min, avg, max) = (9.608, 16.640, 166.450), stdev = 24.752
  CI (99.9%): [9.855, 23.424] (assumes normal distribution)


Concurrent HashMap as a Cache Implementation

Benchmark                                   Mode  Cnt   Score   Error   Units
SSLStartHandshake.handshakeBenchmark       thrpt  150   1.163 ? 0.052  ops/ms
SSLStartHandshake.handshakeBenchmark        avgt  150  12.570 ? 3.854   ms/op

Result "org.openjdk.bench.java.security.SSLStartHandshake.handshakeBenchmark":
  1.163 ?(99.9%) 0.052 ops/ms [Average]
  (min, avg, max) = (0.172, 1.163, 1.287), stdev = 0.191
  CI (99.9%): [1.110, 1.215] (assumes normal distribution)

Result "org.openjdk.bench.java.security.SSLStartHandshake.handshakeBenchmark":
  12.570 ?(99.9%) 3.854 ms/op [Average]
  (min, avg, max) = (9.261, 12.570, 116.059), stdev = 14.061
  CI (99.9%): [8.716, 16.424] (assumes normal distribution)


I was synchronizing based on the  `handshakeContextCache`.
ConcurrentHashMap does provide better results when compared to the baseline, However, I would need figure out the evicting the nodes based on the size.

Please do let me know what you think about the results and I can update the PR accordingly.

Examples of library code explicitly setting the enabledProtocols and enabledCipherSuites
1: https://github.com/apache/httpcomponents-client/blob/861c071ee4f74a287e7b94b0711045bb5a46d8cf/httpclient5/src/main/java/org/apache/hc/client5/http/ssl/SSLConnectionSocketFactory.java#L279
2: https://github.com/apache/hadoop/blob/86729e130fb563d87917850a41bff3b0a886246f/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/ssl/SSLFactory.java#L266

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From mullan at openjdk.java.net  Fri Nov  5 18:42:42 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 5 Nov 2021 18:42:42 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v5]
In-Reply-To: <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
Message-ID: <ThXZzYhmh_DN8FUuz121XAHHYR8X3oDbHKL31fADpbw=.0d8ac46d-299a-4c22-8916-83e3d9eb4e57@github.com>

On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny spec change to be the same as CSR

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From duke at openjdk.java.net  Fri Nov  5 20:01:43 2021
From: duke at openjdk.java.net (Chapman Flack)
Date: Fri, 5 Nov 2021 20:01:43 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v4]
In-Reply-To: <1Crl5KbvRl-JoKbc0ZhJ6-QPgHhLj3E9KQEVYVmWOMc=.d4899d9f-dbda-413d-91ea-c9819c824831@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <1Zw7noLccsCfoSTfZ_3rLgMhhLeuwPU0vSlaWVHsIuo=.7a2287ea-48c6-40fc-880d-84d529ca9aa6@github.com>
 <1Crl5KbvRl-JoKbc0ZhJ6-QPgHhLj3E9KQEVYVmWOMc=.d4899d9f-dbda-413d-91ea-c9819c824831@github.com>
Message-ID: <TjYCAtzkYApT9O3TViWFQ_c1A2zwb9CI5QMgMeo3e3Y=.cdd1dbe5-2960-4aef-8f5e-2163cb41cae5@github.com>

On Thu, 28 Oct 2021 19:34:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Hi, Chap. Thanks for the comment.
> 
> Is it possible you run `callAs` with a "higher level" subject that contains a link to another more dynamic subject? For example, just make your `Supplier<Subject>` a public credential inside. If the caller is not something you can modify, does it work if you call `callAs` inside `callAs`?

I am sorry to be so late in replying. I had initially commented via `security-dev` and I see that comment was added here, and your reply appears in the `security-dev` archives but for some reason never appeared in my inbox. So I will try GitHub's UI this time and see if that goes better.

If I remember right, I had looked years ago at making `Subject` itself more clever to handle this case, but was stymied there because `Subject` is final, which was what drove me to the clever-domain-combiner approach.

The topic arises in a situation where the JVM is embedded into a larger C application, and actions in the larger application, unknown to Java, can change the principals on whose behalf the work is being done. (The changes, at least in the cases that interest me, are not completely _asynchronous_ with respect to Java; they may happen between application downcalls to Java code, or during upcalls from Java back into the app; it is simply that Java doesn't knowingly initiate them.)

There can also be some cost in obtaining the current principal information from the C environment, and of mapping that information into Java `Principal` instances and constructing `Set` representations of those. To eagerly do so at every entry or upcall return is undesirable. To do so only when `current()` is called, as with a `Supplier<Subject>`, would be desirable. (The clever-combiner approach nearly achieves that, as it only spends cycles at the times the combiner is called.)

Naturally, the appeal of integrating with the `Subject` API is to support existing Java code that relies on that API to learn the principals it is acting for. If such code would have to be changed to use the `Subject` in a weird way (such as getting a `Supplier<Subject>` out of a custom public credential and calling `get` on that), that would squander the benefit of an existing API. As the new implementation simply uses a `ThreadLocal`, it would then be simpler to just use a different custom `ThreadLocal` and avoid the `Subject` API altogether. But in that case the entire benefit of an existing known API has been lost.

In your last question, about "`callAs` inside `callAs`", I am not quite sure what you had in mind.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From wetmore at openjdk.java.net  Fri Nov  5 22:33:46 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 5 Nov 2021 22:33:46 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v4]
In-Reply-To: <QoatBBkSqqk_yyHkiYANpMiBNipHpP3WzE0i-N9XD1M=.09dca45a-c2b4-4723-bc03-daf96a3f7120@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
 <QoatBBkSqqk_yyHkiYANpMiBNipHpP3WzE0i-N9XD1M=.09dca45a-c2b4-4723-bc03-daf96a3f7120@github.com>
Message-ID: <OmIUh02TV6yErELoF9FE_b9WZegjRkP4_wdwBNIsffM=.c35f8cae-0c18-481e-b79d-13d47eb714eb@github.com>

On Fri, 5 Nov 2021 17:23:40 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not reinstantiate SSLContext, add more iterations, add test batch without using session tickets

test/jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java line 34:

> 32:  * @test
> 33:  * @bug 8274736
> 34:  * @summary Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily

Minor nit.  Can you keep these under 80 chars?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6197

From jnimeh at openjdk.java.net  Fri Nov  5 22:55:16 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Fri, 5 Nov 2021 22:55:16 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v5]
In-Reply-To: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
Message-ID: <hzOJ9gxcN24wcpETdv0iZCHDJwr1QFU6VooZDqFkAB4=.bf7a0c33-b585-49b4-b55e-1862941005f1@github.com>

> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Fix 80+ char lines

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6197/files
  - new: https://git.openjdk.java.net/jdk/pull/6197/files/5ddd0535..b44e861f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6197&range=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6197/head:pull/6197

PR: https://git.openjdk.java.net/jdk/pull/6197

From jnimeh at openjdk.java.net  Fri Nov  5 22:55:19 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Fri, 5 Nov 2021 22:55:19 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v4]
In-Reply-To: <OmIUh02TV6yErELoF9FE_b9WZegjRkP4_wdwBNIsffM=.c35f8cae-0c18-481e-b79d-13d47eb714eb@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
 <QoatBBkSqqk_yyHkiYANpMiBNipHpP3WzE0i-N9XD1M=.09dca45a-c2b4-4723-bc03-daf96a3f7120@github.com>
 <OmIUh02TV6yErELoF9FE_b9WZegjRkP4_wdwBNIsffM=.c35f8cae-0c18-481e-b79d-13d47eb714eb@github.com>
Message-ID: <QU-iTHmPnYJUGCBsPMTIzzsUq1AwZemm6K93R0YQELE=.0daecb8b-790e-489f-97c9-9b0813d663d9@github.com>

On Fri, 5 Nov 2021 22:30:50 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not reinstantiate SSLContext, add more iterations, add test batch without using session tickets
>
> test/jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java line 34:
> 
>> 32:  * @test
>> 33:  * @bug 8274736
>> 34:  * @summary Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily
> 
> Minor nit.  Can you keep these under 80 chars?

No problem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6197

From xuelei at openjdk.java.net  Fri Nov  5 23:00:38 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 5 Nov 2021 23:00:38 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
 <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
Message-ID: <pTP97Qwk50BqW75trzTR57H_fOeyqnjNUEvrkvSUCl8=.34307917-89f4-4a54-9e95-87ac69ce5694@github.com>

On Sat, 30 Oct 2021 04:57:22 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 74:
> 
>> 72:                     "sun.security.ssl.allowLegacyHelloMessages", true);
>> 73: 
>> 74:     static Cache<Double, HandshakeContextCacheItem> handshakeContextCache;
> 
> I think I understand the motivation, but a mutable cache in handshake context does not sound like the right direction.  A cache could impact the performance more and occupy additional memories , because we have to synchronizing the access to the cache.  Maybe, you could to benchmark the maximum operations allowed per seconds, and try to use more complex cases, and see what the result could be.
> 
> I did not yet try to find an improvement yet.  But at this moment, the idea to me is to thinking about the TLS user cases.  It is common that applications use one instance of SSLContext and default configurations.  From the SSLContext instance, with the default configuration, the connections get established.  Normally, we don't recommend to set protocols and cipher suites other than the default SSLContex configuration, because it is not algorithm aglity.  So, it may be a direction to have the default and final active protocols and cipher suites, parsed and cached in SSLContext.  Just for your reference if you want a further improvement.

> Hi @XueleiFan,
> 
> Thank you for the feedback, though it?s not recommended to set the protocols and cipher suites, various frameworks often do set these values, [Some references below]. Would it still make sense to only optimize the default case?

I know, there are applications setting protocols and cipher suites for themselves.  But it should be common that the TLS connections created from the same SSLContext uses the same cipher suites and protocols.  There are still exceptions, but may be not that common.  Using an instance cache in SSLContext rather than static cache could be a further improvement.

I would not use static cache unless there is no other option.  The troublesome of static cache is more than the performance impact.  A series of problems like memory leaking and security issues could be followed even we design the cache very carefully.

About the benchmark, did you have a chance to check the result for full handshakes?  The code in the benchmark checks the initialization of the handshake, the handshake may not be full/completed.  A benchmark for full handshake may be able to provide more evidence about the overall impact of the improvement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From weijun at openjdk.java.net  Fri Nov  5 23:31:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 5 Nov 2021 23:31:43 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v5]
In-Reply-To: <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
Message-ID: <ndQd7MnondjlBoaxxnCOIl5D5OOiAUDf3vRc3v7iOzg=.06c443d7-3ac8-45c4-9996-d6b460cedf74@github.com>

On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny spec change to be the same as CSR

When we introduce a new API, we hope it always works as specified. In this case, it should work with both the `ThreadLocal` and `AccessContolContext` mechanisms.

In my understanding, to work with the `AccessContolContext` mechanism, this `Supplier<Subject>` must be wrapped into some kind of `Subject`. This could be weird.

Now, if we do this inside JDK, then `callAs(Supplier,Callable)` will create this weird subject and then call `callAs(Subject,Callable)`, and then `current()` will inspect if the subject is in this style and if so fetch the real inner subject and return it. This will be transparent to users.

Otherwise, users would need to apply this trick themselves. They need to create this weird subject and call the usual `callAs`. Inside the action, they do the same inspection and fetch the real subject. They can either use this subject directly, or, if the final consumer of the subject is something they can not control (For example, the JGSS-API `GSSContext::initSecContext` searches for Kerberos tickets in subject), they would have to call `callAs` again with this real subject. That's what I meant `callAs` in `callAs`.

That's all I can think of now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From duke at openjdk.java.net  Sat Nov  6 00:38:41 2021
From: duke at openjdk.java.net (Chapman Flack)
Date: Sat, 6 Nov 2021 00:38:41 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v5]
In-Reply-To: <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
Message-ID: <8KoW8XcgUnFH3azHO7jFnAfeXD5c7VOhRBdElZJuIxI=.58e037ee-d11c-4697-b5e3-915000086d00@github.com>

On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny spec change to be the same as CSR

Ah. Yes, making it work in the current `AccessControlContext` mechanism really probably requires teaching `SubjectDomainCombiner` about it, essentially the pre-JEP-411 approach I had come to. If the principals change, that should not only be reflected in what's returned by `getSubject`, but also in what's returned by `combine` (and potentially used in policy decisions).

Its documentation would then have to be written a bit carefully for the non-`ThreadLocal` case, to clarify that the supplier's `get` method is called not only at uses of `getSubject`, but also at times when the combiner is applied, such as `getContext` and prior to permission checks. (More or less intuitive,anyway: those are the times the `Subject` _matters_.) That would simply amount to exposing a straightforward method for doing what can already be done today, only without the tedious step of implementing a custom combiner.

As a modification to `SubjectDomainCombiner` it could be as simple as changing the instance field to `Supplier<Subject>` and having both `combine` and `getSubject` begin with a `final Subject subject = subjectSupplier.get();`. The constructor that takes a `Subject` would simply store `() -> s` as the supplier.

Adding code to the JEP 411 deprecated components seems a bit of a joyless task, but then it is very little code, and there would then be an API for this use case that would be undisrupted when the deprecated components go away. The extra documentation wording about when the supplier getter is called would, of course, become much shorter and simpler at that point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From duke at openjdk.java.net  Sat Nov  6 08:57:35 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 6 Nov 2021 08:57:35 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <pTP97Qwk50BqW75trzTR57H_fOeyqnjNUEvrkvSUCl8=.34307917-89f4-4a54-9e95-87ac69ce5694@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
 <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
 <pTP97Qwk50BqW75trzTR57H_fOeyqnjNUEvrkvSUCl8=.34307917-89f4-4a54-9e95-87ac69ce5694@github.com>
Message-ID: <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>

On Fri, 5 Nov 2021 22:57:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 74:
>> 
>>> 72:                     "sun.security.ssl.allowLegacyHelloMessages", true);
>>> 73: 
>>> 74:     static Cache<Double, HandshakeContextCacheItem> handshakeContextCache;
>> 
>> I think I understand the motivation, but a mutable cache in handshake context does not sound like the right direction.  A cache could impact the performance more and occupy additional memories , because we have to synchronizing the access to the cache.  Maybe, you could to benchmark the maximum operations allowed per seconds, and try to use more complex cases, and see what the result could be.
>> 
>> I did not yet try to find an improvement yet.  But at this moment, the idea to me is to thinking about the TLS user cases.  It is common that applications use one instance of SSLContext and default configurations.  From the SSLContext instance, with the default configuration, the connections get established.  Normally, we don't recommend to set protocols and cipher suites other than the default SSLContex configuration, because it is not algorithm aglity.  So, it may be a direction to have the default and final active protocols and cipher suites, parsed and cached in SSLContext.  Just for your reference if you want a further improvement.
>
>> Hi @XueleiFan,
>> 
>> Thank you for the feedback, though it?s not recommended to set the protocols and cipher suites, various frameworks often do set these values, [Some references below]. Would it still make sense to only optimize the default case?
> 
> I know, there are applications setting protocols and cipher suites for themselves.  But it should be common that the TLS connections created from the same SSLContext uses the same cipher suites and protocols.  There are still exceptions, but may be not that common.  Using an instance cache in SSLContext rather than static cache could be a further improvement.
> 
> I would not use static cache unless there is no other option.  The troublesome of static cache is more than the performance impact.  A series of problems like memory leaking and security issues could be followed even we design the cache very carefully.
> 
> About the benchmark, did you have a chance to check the result for full handshakes?  The code in the benchmark checks the initialization of the handshake, the handshake may not be full/completed.  A benchmark for full handshake may be able to provide more evidence about the overall impact of the improvement.

Can we extend the public API of `SSLContext` with methods for managing `activeProtocols`, `activeCipherSuites` and possibly `algorithmConstraints`? Without this API change we would need to check every time if the active protocols, ciphers and constraints match the cached ones.

Also, looking at the flame graphs provided, it appears that about 50% of the handshake time is spent in `SSLAlgorithmDecomposer#decompose`; given that there are only 3 instances of that class (and could be further reduced to 2), would it make sense to optimize the method by caching the results of algorithm decomposition? We could use a size-limited soft cache to avoid memory leaks, and I fail to see how the cached information could be exploitable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From xuelei at openjdk.java.net  Sun Nov  7 16:41:35 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 7 Nov 2021 16:41:35 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
 <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
 <pTP97Qwk50BqW75trzTR57H_fOeyqnjNUEvrkvSUCl8=.34307917-89f4-4a54-9e95-87ac69ce5694@github.com>
 <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
Message-ID: <lYHRKJiFYhN4ITmmzUBdNqzGx_6G4dbDaFsWoniZy0s=.4da8f39c-2c33-4659-b42f-1a8b8e296a28@github.com>

On Sat, 6 Nov 2021 08:54:33 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Can we extend the public API of `SSLContext` with methods for managing `activeProtocols`, `activeCipherSuites` and possibly `algorithmConstraints`? Without this API change we would need to check every time if the active protocols, ciphers and constraints match the cached ones.
> 

Yes, it is one direction that we could consider to have more configuration in SSLContext, rather than configure individually in each socket.  I think it may improve the performance a lot.

> Also, looking at the flame graphs provided, it appears that about 50% of the handshake time is spent in `SSLAlgorithmDecomposer#decompose`; given that there are only 3 instances of that class (and could be further reduced to 2), would it make sense to optimize the method by caching the results of algorithm decomposition?

If it is true, I think should optimize the decompose method, may be not limited to caching.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From serb at openjdk.java.net  Mon Nov  8 04:35:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 04:35:37 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the
 java.util.logging
In-Reply-To: <DHI5YMCid9Tv-5Fd4KuFDA6i8GXIn0t5FJRGciK3KIE=.76d5b585-ec04-4d7e-8364-e2f07d888df4@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <DHI5YMCid9Tv-5Fd4KuFDA6i8GXIn0t5FJRGciK3KIE=.76d5b585-ec04-4d7e-8364-e2f07d888df4@github.com>
Message-ID: <3Syn0sjGIcKaxYy3wFdgsXE4UCxDTvG2YoY3iiEx4QI=.37471059-6ffb-4577-8f54-7bd38a281503@github.com>

On Fri, 29 Oct 2021 16:32:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The change looks okay. My suggestion is to get 1-6 all ready to push around the same time. It's okay to have separate JBS issues and PRs.

ok, I'll continue to work using the plan from the description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5326

From weijun at openjdk.java.net  Mon Nov  8 14:04:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 8 Nov 2021 14:04:40 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v5]
In-Reply-To: <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <TmC1Qw9NkeUr8ep88duw__p0W0Unv1hsOJQZI_dcGNI=.648702c8-01ae-4abb-a5a4-7125c295a30f@github.com>
Message-ID: <-qtMel1fChQ1d4_YWXTiGNeXnoQpSharaDsGRPEuNmk=.3902f9d0-abc9-4651-a360-0cbd1af0512f@github.com>

On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny spec change to be the same as CSR

Your suggestion is more low-level. Anyway, I think this is an enhancement and not a blocker to the current PR. I?ve created a new JBS issue at https://bugs.openjdk.java.net/browse/JDK-8276807. I do think it?s debatable whether such an API is worth adding and how it fits into the structure of JAAS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From mullan at openjdk.java.net  Mon Nov  8 14:14:47 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 8 Nov 2021 14:14:47 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled
Message-ID: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>

When a signature/digest algorithm was being checked, the algorithm constraints checked both the signature/digest algorithm and the key to see if they were restricted. This caused duplicate checks and was also problematic for `jarsigner` (and `keytool`) which need to distinguish these two cases, so that the output can properly indicate when the key is disabled but the signature or digest alg is ok. 

To address this issue, a new `checkKey` parameter is added to the `DisabledAlgorithmConstraints.permits` methods. When `true` the key (alg and size) is also checked, otherwise it is not. This flag is always set to `false` by `jarsigner` when checking algs and by the JDK when checking digest algorithms. Other small changes include changes in `SignerInfo` to use a record to store info about the algorithms to be checked, and removing an unnecessary CRL checking method from `AlgorithmChecker`.

`keytool` will be enhanced in a subsequent CR to call the new methods.

-------------

Commit messages:
 - Change name of `checkKeySize` param to `checkKey`.
 - 8275887: jarsigner prints invalid digest/signature algorithm warnings if keysize is weak/disabled

Changes: https://git.openjdk.java.net/jdk/pull/6296/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6296&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275887
  Stats: 128 lines in 9 files changed: 40 ins; 31 del; 57 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6296.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6296/head:pull/6296

PR: https://git.openjdk.java.net/jdk/pull/6296

From wetmore at openjdk.java.net  Tue Nov  9 01:04:45 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 9 Nov 2021 01:04:45 GMT
Subject: RFR: 8276677: Malformed Javadoc inline tags in JDK source in
 javax/net/ssl
Message-ID: <O7ez4Y0wm3dOPdBYVKvdLe9PieR303ZviRLdbpNiHuA=.6afa9de9-5fbb-4481-88b2-be570a4b7e7e@github.com>

Minor typos.

-------------

Commit messages:
 - Forgot copyright date
 - 8276677: Malformed Javadoc inline tags in JDK source in javax/net/ssl

Changes: https://git.openjdk.java.net/jdk/pull/6301/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6301&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276677
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6301/head:pull/6301

PR: https://git.openjdk.java.net/jdk/pull/6301

From jnimeh at openjdk.java.net  Tue Nov  9 01:09:34 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Tue, 9 Nov 2021 01:09:34 GMT
Subject: RFR: 8276677: Malformed Javadoc inline tags in JDK source in
 javax/net/ssl
In-Reply-To: <O7ez4Y0wm3dOPdBYVKvdLe9PieR303ZviRLdbpNiHuA=.6afa9de9-5fbb-4481-88b2-be570a4b7e7e@github.com>
References: <O7ez4Y0wm3dOPdBYVKvdLe9PieR303ZviRLdbpNiHuA=.6afa9de9-5fbb-4481-88b2-be570a4b7e7e@github.com>
Message-ID: <8jkoIlk5fo4eaui23LLo2HaaeBxIQBZoaCfwZ6dYwNM=.a94a3bda-3ecf-4adb-a4a1-046dee616521@github.com>

On Mon, 8 Nov 2021 22:59:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Minor typos.

Looks good

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6301

From wetmore at openjdk.java.net  Tue Nov  9 01:14:39 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 9 Nov 2021 01:14:39 GMT
Subject: Integrated: 8276677: Malformed Javadoc inline tags in JDK source in
 javax/net/ssl
In-Reply-To: <O7ez4Y0wm3dOPdBYVKvdLe9PieR303ZviRLdbpNiHuA=.6afa9de9-5fbb-4481-88b2-be570a4b7e7e@github.com>
References: <O7ez4Y0wm3dOPdBYVKvdLe9PieR303ZviRLdbpNiHuA=.6afa9de9-5fbb-4481-88b2-be570a4b7e7e@github.com>
Message-ID: <_WCQAM0lKItZFGqfuePAjWmOQ_tEhUqBokRJsjBJ-vw=.f7646acf-0da4-4639-a14e-c3c190532895@github.com>

On Mon, 8 Nov 2021 22:59:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Minor typos.

This pull request has now been integrated.

Changeset: 38e6d5d6
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/38e6d5d6ed967f68e6ac1bfaa285efa16577c790
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8276677: Malformed Javadoc inline tags in JDK source in javax/net/ssl

Reviewed-by: jnimeh

-------------

PR: https://git.openjdk.java.net/jdk/pull/6301

From weijun at openjdk.java.net  Tue Nov  9 14:34:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 9 Nov 2021 14:34:51 GMT
Subject: RFR: 8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java
Message-ID: <cIqSq86dfFzbeIpfVF_OnVXuiXq9lp2QWV7tHd5GGxU=.c8b1bf37-e0bc-4419-af78-ff8bd7953a43@github.com>

The test was added in JDK-8237218 to confirm that Java impl is used when verifying a signature. It is useless now since the native implementation is completely removed.

-------------

Commit messages:
 - 8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java

Changes: https://git.openjdk.java.net/jdk/pull/6313/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6313&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276863
  Stats: 247 lines in 1 file changed: 0 ins; 247 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6313/head:pull/6313

PR: https://git.openjdk.java.net/jdk/pull/6313

From ascarpino at openjdk.java.net  Tue Nov  9 14:50:39 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 9 Nov 2021 14:50:39 GMT
Subject: RFR: 8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java
In-Reply-To: <cIqSq86dfFzbeIpfVF_OnVXuiXq9lp2QWV7tHd5GGxU=.c8b1bf37-e0bc-4419-af78-ff8bd7953a43@github.com>
References: <cIqSq86dfFzbeIpfVF_OnVXuiXq9lp2QWV7tHd5GGxU=.c8b1bf37-e0bc-4419-af78-ff8bd7953a43@github.com>
Message-ID: <JysbIYFQXRpEv2OegWD_Rs1vdZoBZKGYeign2PIbH7k=.b94d013c-d839-4f3e-a8c7-090270477ac9@github.com>

On Tue, 9 Nov 2021 14:23:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The test was added in JDK-8237218 to confirm that Java impl is used when verifying a signature. It is useless now since the native implementation is completely removed.

Look good

-------------

Marked as reviewed by ascarpino (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6313

From weijun at openjdk.java.net  Tue Nov  9 14:50:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 9 Nov 2021 14:50:39 GMT
Subject: Integrated: 8276863: Remove
 test/jdk/sun/security/ec/ECDSAJavaVerify.java
In-Reply-To: <cIqSq86dfFzbeIpfVF_OnVXuiXq9lp2QWV7tHd5GGxU=.c8b1bf37-e0bc-4419-af78-ff8bd7953a43@github.com>
References: <cIqSq86dfFzbeIpfVF_OnVXuiXq9lp2QWV7tHd5GGxU=.c8b1bf37-e0bc-4419-af78-ff8bd7953a43@github.com>
Message-ID: <7vEGKilgeXIOsu0mdQXADjfhZgzWFXhZSO_agTjlVp0=.ab05fa97-e80f-4470-88a8-dd91525a08fe@github.com>

On Tue, 9 Nov 2021 14:23:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The test was added in JDK-8237218 to confirm that Java impl is used when verifying a signature. It is useless now since the native implementation is completely removed.

This pull request has now been integrated.

Changeset: c27afb31
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c27afb313b77d19e7ace7101c6f21aa5b2c56505
Stats:     247 lines in 1 file changed: 0 ins; 247 del; 0 mod

8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java

Reviewed-by: ascarpino

-------------

PR: https://git.openjdk.java.net/jdk/pull/6313

From cverghese at openjdk.java.net  Tue Nov  9 21:47:33 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Tue, 9 Nov 2021 21:47:33 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
 <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
 <pTP97Qwk50BqW75trzTR57H_fOeyqnjNUEvrkvSUCl8=.34307917-89f4-4a54-9e95-87ac69ce5694@github.com>
 <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
Message-ID: <EzDb45qptPeIOyNUHl9OKt7mWCwhF5NNftEUJ_xTFIg=.61d490ef-286a-437b-8ee4-666c6a8f02aa@github.com>

On Sat, 6 Nov 2021 08:54:33 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>>> Hi @XueleiFan,
>>> 
>>> Thank you for the feedback, though it?s not recommended to set the protocols and cipher suites, various frameworks often do set these values, [Some references below]. Would it still make sense to only optimize the default case?
>> 
>> I know, there are applications setting protocols and cipher suites for themselves.  But it should be common that the TLS connections created from the same SSLContext uses the same cipher suites and protocols.  There are still exceptions, but may be not that common.  Using an instance cache in SSLContext rather than static cache could be a further improvement.
>> 
>> I would not use static cache unless there is no other option.  The troublesome of static cache is more than the performance impact.  A series of problems like memory leaking and security issues could be followed even we design the cache very carefully.
>> 
>> About the benchmark, did you have a chance to check the result for full handshakes?  The code in the benchmark checks the initialization of the handshake, the handshake may not be full/completed.  A benchmark for full handshake may be able to provide more evidence about the overall impact of the improvement.
>
> Can we extend the public API of `SSLContext` with methods for managing `activeProtocols`, `activeCipherSuites` and possibly `algorithmConstraints`? Without this API change we would need to check every time if the active protocols, ciphers and constraints match the cached ones.
> 
> Also, looking at the flame graphs provided, it appears that about 50% of the handshake time is spent in `SSLAlgorithmDecomposer#decompose`; given that there are only 3 instances of that class (and could be further reduced to 2), would it make sense to optimize the method by caching the results of algorithm decomposition? We could use a size-limited soft cache to avoid memory leaks, and I fail to see how the cached information could be exploitable.

Hi @djelinski @XueleiFan, 

Thank you for the feedback on this issue. 

`activeProtocols` and `activeCipherSuites` are currently derived from `enabledProtocols` and `enabledCipherSuites` and `algorithmConstraints`. And the [SSLContext is currently considered as immutable.](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L42). If we provide ways to configure in SSLContext, We would need to rewrite this assumption. That could have implications in other areas where this assumption is currently held(?). 

The other option of having an instance cache in SSLContext could be helpful as well, but then it would also affect the assumption above.  

I can look into optimizing the SSLAlgorithmDecomposer, by adding a size limited cache there to see if it would beneficial. This could be an instance variable as well, so @XueleiFan concerns of static cache can also be addressed. I'll check if the benchmarks look better with the new approach. 

Additionally, I looked into  the decompose method and found that there is scope for improvements there. We could eliminate the [repeated calls to decompose CipherSuite](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLAlgorithmDecomposer.java#L269). This would need us to store the results of decomposing the CipherSuite, Both in the case of when onlyX509 is true and false. 

Other optimization in the decompose path are in SSLCipher, but this won't be necessary if we optimize the CipherSuite decompose mentioned above. 

Other times spent in the function is within the HashMap and Collections (`add` and `addAll`). 

<img width="2986" alt="Screen Shot 2021-11-09 at 1 29 57 PM" src="https://user-images.githubusercontent.com/934461/141008035-a6549701-2233-4d3e-ba61-7859d25b339c.png">

I can follow up on this based on the results of the SSLAlgorithmDecomposer optimizations, and if this is still an issue, I can open a seperate JBS issue and create a PR for this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From xuelei at openjdk.java.net  Tue Nov  9 22:55:34 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 9 Nov 2021 22:55:34 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
 <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
 <pTP97Qwk50BqW75trzTR57H_fOeyqnjNUEvrkvSUCl8=.34307917-89f4-4a54-9e95-87ac69ce5694@github.com>
 <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
Message-ID: <aVn1lBn2QeKjOMLFgf78fA0TUSfG3h33mV9LqDkQdI8=.7f0eec6d-cb67-4fa0-87b2-b558d2bca52a@github.com>

On Sat, 6 Nov 2021 08:54:33 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>>> Hi @XueleiFan,
>>> 
>>> Thank you for the feedback, though it?s not recommended to set the protocols and cipher suites, various frameworks often do set these values, [Some references below]. Would it still make sense to only optimize the default case?
>> 
>> I know, there are applications setting protocols and cipher suites for themselves.  But it should be common that the TLS connections created from the same SSLContext uses the same cipher suites and protocols.  There are still exceptions, but may be not that common.  Using an instance cache in SSLContext rather than static cache could be a further improvement.
>> 
>> I would not use static cache unless there is no other option.  The troublesome of static cache is more than the performance impact.  A series of problems like memory leaking and security issues could be followed even we design the cache very carefully.
>> 
>> About the benchmark, did you have a chance to check the result for full handshakes?  The code in the benchmark checks the initialization of the handshake, the handshake may not be full/completed.  A benchmark for full handshake may be able to provide more evidence about the overall impact of the improvement.
>
> Can we extend the public API of `SSLContext` with methods for managing `activeProtocols`, `activeCipherSuites` and possibly `algorithmConstraints`? Without this API change we would need to check every time if the active protocols, ciphers and constraints match the cached ones.
> 
> Also, looking at the flame graphs provided, it appears that about 50% of the handshake time is spent in `SSLAlgorithmDecomposer#decompose`; given that there are only 3 instances of that class (and could be further reduced to 2), would it make sense to optimize the method by caching the results of algorithm decomposition? We could use a size-limited soft cache to avoid memory leaks, and I fail to see how the cached information could be exploitable.

> Hi @djelinski @XueleiFan,
> 
> Thank you for the feedback on this issue.
> 
> `activeProtocols` and `activeCipherSuites` are currently derived from `enabledProtocols` and `enabledCipherSuites` and `algorithmConstraints`. And the [SSLContext is currently considered as immutable.](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L42). If we provide ways to configure in SSLContext, We would need to rewrite this assumption. That could have implications in other areas where this assumption is currently held(?).

I don't think it is the direction to change the immunity of SSLContext.  There are two proposals right now.  One is to change the SSLContext public APIs,  @djelinski, by adding cipher suites and protocols configuration (immutable).  This proposal does not impact the current code, where enabled protocols and cipher suites are configured in each socket.  But it could be useful for future code to configure these parameters in the context level.  It may be easier to maintain and could have better performance.

I did not have time to think over the potentials yet, but I did have the proposal to move from static cache to instance cache.  SSLContext/impl is ideal because normally only one SSLContext instance is required, surely there are exceptions, for an application.  We may also missed another issue that the underlying crypto provider could change, for example unplugging a token from the slot.  Once the crypto provider is changed, the cached binding between protocol and cipher suites may not work any longer.  So we may need to take care of this kind of issue for static cache.  For an instance of SSLContext, the crypto provider changing issues are still there, but get mitigated as the context has already bound to specific trust manager and key manager.  Yes, it does change the SSLContext implementation from immutability to mutability. But it is in an acceptable level, just as what we did for session cache in the context instance.

Just for your consideration.  This is a tough problem, and it may take time to find a suitable solution.  Let's keep exchanging our thoughts about it.

> 
> The other option of having an instance cache in SSLContext could be helpful as well, but then it would also affect the assumption above.
> 
> I can look into optimizing the SSLAlgorithmDecomposer, by adding a size limited cache there to see if it would beneficial. This could be an instance variable as well, so @XueleiFan concerns of static cache can also be addressed. I'll check if the benchmarks look better with the new approach.
> 
> Additionally, I looked into the decompose method and found that there is scope for improvements there. We could eliminate the [repeated calls to decompose CipherSuite](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLAlgorithmDecomposer.java#L269). This would need us to store the results of decomposing the CipherSuite, Both in the case of when onlyX509 is true and false.
> 
> Other optimization in the decompose path are in SSLCipher, but this won't be necessary if we optimize the CipherSuite decompose mentioned above.
> 
> Other times spent in the function is within the HashMap and Collections (`add` and `addAll`).
> 
> <img alt="Screen Shot 2021-11-09 at 1 29 57 PM" width="2000" src="https://user-images.githubusercontent.com/934461/141008035-a6549701-2233-4d3e-ba61-7859d25b339c.png">
> 
> I can follow up on this based on the results of the SSLAlgorithmDecomposer optimizations, and if this is still an issue, I can open a seperate JBS issue and create a PR for this.

Yes, please.  Your found is impressive to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From cverghese at openjdk.java.net  Tue Nov  9 23:15:46 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Tue, 9 Nov 2021 23:15:46 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
 <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>
 <pTP97Qwk50BqW75trzTR57H_fOeyqnjNUEvrkvSUCl8=.34307917-89f4-4a54-9e95-87ac69ce5694@github.com>
 <m-1UAAoQym32Y7hmFUVVrvsOA4BoudP0zYeOuE_aRYU=.5fba8de3-7931-4799-ab4f-2e8ff0679e86@github.com>
Message-ID: <iTK28DWiuaWxCUJhRi6mG27sNs4ozpkZjl6NDkyraJs=.9c276a8c-89bd-40a2-97b4-0587422afef0@github.com>

On Sat, 6 Nov 2021 08:54:33 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>>> Hi @XueleiFan,
>>> 
>>> Thank you for the feedback, though it?s not recommended to set the protocols and cipher suites, various frameworks often do set these values, [Some references below]. Would it still make sense to only optimize the default case?
>> 
>> I know, there are applications setting protocols and cipher suites for themselves.  But it should be common that the TLS connections created from the same SSLContext uses the same cipher suites and protocols.  There are still exceptions, but may be not that common.  Using an instance cache in SSLContext rather than static cache could be a further improvement.
>> 
>> I would not use static cache unless there is no other option.  The troublesome of static cache is more than the performance impact.  A series of problems like memory leaking and security issues could be followed even we design the cache very carefully.
>> 
>> About the benchmark, did you have a chance to check the result for full handshakes?  The code in the benchmark checks the initialization of the handshake, the handshake may not be full/completed.  A benchmark for full handshake may be able to provide more evidence about the overall impact of the improvement.
>
> Can we extend the public API of `SSLContext` with methods for managing `activeProtocols`, `activeCipherSuites` and possibly `algorithmConstraints`? Without this API change we would need to check every time if the active protocols, ciphers and constraints match the cached ones.
> 
> Also, looking at the flame graphs provided, it appears that about 50% of the handshake time is spent in `SSLAlgorithmDecomposer#decompose`; given that there are only 3 instances of that class (and could be further reduced to 2), would it make sense to optimize the method by caching the results of algorithm decomposition? We could use a size-limited soft cache to avoid memory leaks, and I fail to see how the cached information could be exploitable.

>I don't think it is the direction to change the immunity of SSLContext. There are two proposals right now. One is to change the SSLContext public APIs, @djelinski, by adding cipher suites and protocols configuration (immutable). This proposal does not impact the current code, where enabled protocols and cipher suites are configured in each socket. But it could be useful for future code to configure these parameters in the context level. It may be easier to maintain and could have better performance.
>
> I did not have time to think over the potentials yet, but I did have the proposal to move from static cache to instance cache. SSLContext/impl is ideal because normally only one SSLContext instance is required, surely there are exceptions, for an application. We may also missed another issue that the underlying crypto provider could change, for example unplugging a token from the slot. Once the crypto provider is changed, the cached binding between protocol and cipher suites may not work any longer. So we may need to take care of this kind of issue for static cache. For an instance of SSLContext, the crypto provider changing issues are still there, but get mitigated as the context has already bound to specific trust manager and key manager. Yes, it does change the SSLContext implementation from immutability to mutability. But it is in an acceptable level, just as what we did for session cache in the context instance.
>
> Just for your consideration. This is a tough problem, and it may take time to find a suitable solution. Let's keep exchanging our thoughts about it.

Thank you @XueleiFan for the feedback, I'll take a look at it from that perspective as well and post my findings here. 

> Yes, please. Your found is impressive to me.

I'll create a new JBS issue and PR along with benchmarks for this. Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From wetmore at openjdk.java.net  Wed Nov 10 01:07:36 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 10 Nov 2021 01:07:36 GMT
Subject: RFR: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily [v5]
In-Reply-To: <hzOJ9gxcN24wcpETdv0iZCHDJwr1QFU6VooZDqFkAB4=.bf7a0c33-b585-49b4-b55e-1862941005f1@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
 <hzOJ9gxcN24wcpETdv0iZCHDJwr1QFU6VooZDqFkAB4=.bf7a0c33-b585-49b4-b55e-1862941005f1@github.com>
Message-ID: <1Py04eWi21bVBLS2hj54NftkiQ1lRW5qwpbUl-DNJEw=.e0e1c574-262a-4af2-ad68-baee5721b467@github.com>

On Fri, 5 Nov 2021 22:55:16 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 80+ char lines

Marked as reviewed by wetmore (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6197

From jnimeh at openjdk.java.net  Wed Nov 10 01:27:49 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 10 Nov 2021 01:27:49 GMT
Subject: Integrated: 8274736: Concurrent read/close of SSLSockets causes
 SSLSessions to be invalidated unnecessarily
In-Reply-To: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
References: <PDCgEzCd09QssmJwjSAY-_wB9vnt8IClPMOByRe4hyI=.7b2cab7a-9d58-4268-ae63-dbc470d0597c@github.com>
Message-ID: <HaD2QASAcITzBccKKtI9USveAuxIxyZPFmtvGYJL73w=.82e08cb8-3339-46ec-9062-9b24c1a09526@github.com>

On Mon, 1 Nov 2021 18:28:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix handles cases where two or more threads may be acting on a single SSLSocket instance.  In cases where one thread closes the socket while the other is in the middle of a read, a SocketException is appropriately thrown, but it results in SSLSession invalidation even though the session was legitimately negotiated at an earlier point in time and should remain in the cache.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274736

This pull request has now been integrated.

Changeset: 8822d41f
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8822d41fdcc2c2d568badd72635dc587d21dbd63
Stats:     429 lines in 3 files changed: 425 ins; 0 del; 4 mod

8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily

Reviewed-by: xuelei, wetmore

-------------

PR: https://git.openjdk.java.net/jdk/pull/6197

From abakhtin at openjdk.java.net  Wed Nov 10 08:39:35 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 10 Nov 2021 08:39:35 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v4]
In-Reply-To: <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
Message-ID: <mz3fTPhhfQ6Nc8xXosWa_4pnU7GMOvoxuOtNGci1ZvM=.feaa5339-9f44-4a8b-b999-f101f97f82bb@github.com>

On Wed, 3 Nov 2021 17:02:40 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the patch for JDK-8274524
>> 
>> The fix just adds locks around InputStream read and skip operations to prevent concurrent read from socket.
>> sun/security/ssl jtreg tests passed
>> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jcheck issues

Gentle ping.
JDK-8274736 was recently integrated to fix the concurrent read/close issue, but JDK-8274736 does not fix this particular issue with the hanged SSLSocket.close(). JTREG test was added to demonstrate the presence of the issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5760

From xuelei at openjdk.java.net  Wed Nov 10 17:31:34 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 10 Nov 2021 17:31:34 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v4]
In-Reply-To: <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
Message-ID: <Qwyixt1GHqf4G4wgQjAe_pB5ONqG9XJPq8x9-NjIm84=.8317da6a-d608-42ee-9379-8fc71ad05948@github.com>

On Wed, 3 Nov 2021 17:02:40 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the patch for JDK-8274524
>> 
>> The fix just adds locks around InputStream read and skip operations to prevent concurrent read from socket.
>> sun/security/ssl jtreg tests passed
>> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jcheck issues

Did you have a chance to analysis the potential deadlock issues between handshake lock, read lock, write lock and socket lock?  The locks used in SSLSocketImpl is complicated.  If I remember correctly, there are potential deadlock issues if the read/write locks are used during handshaking.  Did you have a dead lock stack for the bug?  Alternatively, it might be a direction to improve the close() code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5760

From abakhtin at openjdk.java.net  Wed Nov 10 18:54:33 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 10 Nov 2021 18:54:33 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v4]
In-Reply-To: <Qwyixt1GHqf4G4wgQjAe_pB5ONqG9XJPq8x9-NjIm84=.8317da6a-d608-42ee-9379-8fc71ad05948@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
 <Qwyixt1GHqf4G4wgQjAe_pB5ONqG9XJPq8x9-NjIm84=.8317da6a-d608-42ee-9379-8fc71ad05948@github.com>
Message-ID: <m9sjppPuwvWEQ5Pdzbzc0dX_YEiL5hcrfMGKDXQ6qxk=.0393ec5d-cf06-4e98-be58-f982afe202f8@github.com>

On Wed, 10 Nov 2021 17:28:18 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Did you have a chance to analysis the potential deadlock issues between handshake lock, read lock, write lock and socket lock? The locks used in SSLSocketImpl is complicated. If I remember correctly, there are potential deadlock issues if the read/write locks are used during handshaking. Did you have a dead lock stack for the bug? Alternatively, it might be a direction to improve the close() code.

Hi @XueleiFan,

Thank you for review.
There are two stack traces in the bug report. The one is for SSLSocket.close() and another for SSLSocketImpl.readHandshakeRecord()
SSLSocket.close() is hanged on the InputStream.skip() operation. SSLSocket.close() and  SSLSocketImpl.readHandshakeRecord() are called concurrently. SSLSocket.close() calls InputStream.skip() to clear input data from socket but concurrent SSLSocketImpl.readHandshakeRecord() reads some data from the socket. As result InputStream.skip() can not complete operation for previously calculated available bytes and hangs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5760

From weijun at openjdk.java.net  Wed Nov 10 19:38:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 10 Nov 2021 19:38:44 GMT
Subject: Integrated: 8267108: Alternate Subject.getSubject and doAs APIs that
 do not depend on Security Manager APIs
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <wKHEMeyLPB7JTEfXvymfIL67_iRMlSQlQBKMlTjXsOM=.45957ee0-e25f-4e86-a442-5766314d6394@github.com>

On Thu, 5 Aug 2021 20:10:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

This pull request has now been integrated.

Changeset: a5c160c7
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a5c160c711a3f66db18c75973f4efdea63332863
Stats:     665 lines in 20 files changed: 449 ins; 96 del; 120 mod

8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs

Reviewed-by: mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From chegar at openjdk.java.net  Thu Nov 11 09:04:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 11 Nov 2021 09:04:42 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v12]
In-Reply-To: <Ktvq-2IpcMRsZqGJnzOXLQSgrflbVUiCvIMe6CWYiRI=.1e0644b8-a219-4317-9cdb-65a1a5c659c8@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <Ktvq-2IpcMRsZqGJnzOXLQSgrflbVUiCvIMe6CWYiRI=.1e0644b8-a219-4317-9cdb-65a1a5c659c8@github.com>
Message-ID: <-xVGnzadh7YfpZ-LIosXbwI8GcE_DDgSEGHL-K9-yUU=.045334b6-753a-430a-8dfe-a5d3480d759f@github.com>

On Wed, 3 Nov 2021 13:23:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - Replace 'system' with 'the system-wide', move comment section
>  - Add @ throws NPE to hosts file resolver javadoc
>  - Changes to address review comments
>  - Update tests to address SM deprecation
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - More javadoc updates to API classes
>  - Review updates + move resolver docs to the provider class (CSR update to follow)
>  - Change InetAddressResolver method names
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/a316c06e...0542df51

LGTM.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Thu Nov 11 10:39:57 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 11 Nov 2021 10:39:57 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v13]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <__Jsy80LDemzzCSYEZZ-72didrp12knvsVYHRqXVlgw=.43e902b2-0f75-4452-abdd-2b8f8eaa1eed@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Replace 'system' with 'the system-wide', move comment section
 - Add @ throws NPE to hosts file resolver javadoc
 - Changes to address review comments
 - Update tests to address SM deprecation
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - More javadoc updates to API classes
 - Review updates + move resolver docs to the provider class (CSR update to follow)
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f561d3c1...a2498d2b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5822/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=12
  Stats: 3141 lines in 56 files changed: 2848 ins; 155 del; 138 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From mcimadamore at openjdk.java.net  Thu Nov 11 13:03:56 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 11 Nov 2021 13:03:56 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v23]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <wy9gnwC78B2cCE1F0kxHLn85x4uXOuSq_f3_X9BBaQE=.2780f332-6902-4373-8cf6-71149eefca32@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into JEP-419
 - Revert removal of upcall MH customization
   (This change caused spurious VM crashes, so reverting to baseline)
 - Further tweak upcall safety considerations
 - Clarify safety considerations for upcalls
 - Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress
   (which is consistent with other restricted factories in VaList and NativeSymbol)
 - Streamline javadoc for package-info
 - * Add two new CLinker static methods to compute upcall/downcall method types
   * Clarify section on CLinker downcall type
   * Add section on CLinker safety guarantees
 - Fix TestUpcall
   * reverse() has a bug, as it doesn't tweak parameter types
   * reverse() is applied to the wrong MH
 - Make ArenaAllocator impl more flexible in the face of OOME
   An ArenaAllocator should remain open for business, even if OOME is thrown in case other allocations can fit the arena size.
 - Simplify ArenaAllocator impl.
   The arena should respect its boundaries and never allocate more memory than its size specifies.
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/aea09677...8c3860f8

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5907/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=22
  Stats: 14686 lines in 193 files changed: 6956 ins; 5120 del; 2610 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From aefimov at openjdk.java.net  Thu Nov 11 14:36:45 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 11 Nov 2021 14:36:45 GMT
Subject: Integrated: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <0mAMXdSKRgY08YrrSsaQp5VMqARxvT3oMjK6fEXytLs=.bfab8386-b198-45f6-8018-ca0d9c79ff9f@github.com>

On Tue, 5 Oct 2021 12:00:15 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

This pull request has now been integrated.

Changeset: 2ca4ff87
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2ca4ff87b7c31d56542bbdcea70e828be33f4e97
Stats:     3141 lines in 56 files changed: 2848 ins; 155 del; 138 mod

8244202: Implementation of JEP 418: Internet-Address Resolution SPI

Co-authored-by: Chris Hegarty <chegar at openjdk.org>
Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: dfuchs, alanb, michaelm, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From mcimadamore at openjdk.java.net  Fri Nov 12 11:16:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 12 Nov 2021 11:16:17 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v24]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <eoGkgm-Zyrnr7AzNy9mm8y1sKSnc5QgxKwRbbQQlz3E=.de691597-aca7-419e-b58f-8402712add66@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Adopt blessed modofier order

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/8c3860f8..79d3d685

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=22-23

  Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From duke at openjdk.java.net  Fri Nov 12 11:54:06 2021
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 12 Nov 2021 11:54:06 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v3]
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: <G7iJx4TJr7V5hbht9HsLb8wLAO6-v-wabcAkYlhm5pU=.9ea11765-70e9-4ee6-86ca-2fd1b45f0dd6@github.com>

> 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

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5937/files
  - new: https://git.openjdk.java.net/jdk/pull/5937/files/6d9f17f4..b1b76be9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=01-02

  Stats: 30 lines in 1 file changed: 8 ins; 9 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

PR: https://git.openjdk.java.net/jdk/pull/5937

From ihse at openjdk.java.net  Fri Nov 12 15:15:51 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 12 Nov 2021 15:15:51 GMT
Subject: RFR: 8277059: Use blessed modifier order in java.xml
Message-ID: <pUZQXiIlxmWw46uzKTyyhsWaGCwM4LyWE4efZViZIQY=.b910b0c5-aa30-4e3f-8cc2-9aa38bc2e275@github.com>

I ran bin/blessed-modifier-order.sh on source code in java.xml and java.xml.crypto. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

-------------

Commit messages:
 - 8277059: Use blessed modifier order in java.xml

Changes: https://git.openjdk.java.net/jdk/pull/6369/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6369&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277059
  Stats: 505 lines in 140 files changed: 0 ins; 0 del; 505 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6369.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6369/head:pull/6369

PR: https://git.openjdk.java.net/jdk/pull/6369

From duke at openjdk.java.net  Fri Nov 12 16:33:36 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Nov 2021 16:33:36 GMT
Subject: Integrated: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <O0Owu_mCiF4GNzuc00dLjhWKMTSBbvJv6pRTUj4jntU=.29028df9-b4a1-47ab-be53-844b31dff671@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

This pull request has now been integrated.

Changeset: 5a2452c8
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a2452c80e64b8b7a1799caa1a8a6e9e6a7dab6d
Stats:     36 lines in 15 files changed: 1 ins; 4 del; 31 mod

8274835: Remove unnecessary castings in java.base

Reviewed-by: mullan, naoto, lancea, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5454

From joehw at openjdk.java.net  Fri Nov 12 18:08:32 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 12 Nov 2021 18:08:32 GMT
Subject: RFR: 8277059: Use blessed modifier order in java.xml
In-Reply-To: <pUZQXiIlxmWw46uzKTyyhsWaGCwM4LyWE4efZViZIQY=.b910b0c5-aa30-4e3f-8cc2-9aa38bc2e275@github.com>
References: <pUZQXiIlxmWw46uzKTyyhsWaGCwM4LyWE4efZViZIQY=.b910b0c5-aa30-4e3f-8cc2-9aa38bc2e275@github.com>
Message-ID: <Bjq5J9OLeaLC4bUJph72Y82_Vf7V1fj-lKyHK7P5xJg=.b4c3cd09-70c4-4ae4-a207-94ed358e018f@github.com>

On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source code in java.xml and java.xml.crypto. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Thanks, Magnus. However, we've discussed the issue for sources from the 3rd party, and we'd like it keep it that way to facilitate any future merges. Refer to JDK-8264019 /  https://github.com/openjdk/jdk/pull/3091.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6369

From ihse at openjdk.java.net  Mon Nov 15 10:42:39 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 15 Nov 2021 10:42:39 GMT
Subject: RFR: 8277059: Use blessed modifier order in java.xml
In-Reply-To: <pUZQXiIlxmWw46uzKTyyhsWaGCwM4LyWE4efZViZIQY=.b910b0c5-aa30-4e3f-8cc2-9aa38bc2e275@github.com>
References: <pUZQXiIlxmWw46uzKTyyhsWaGCwM4LyWE4efZViZIQY=.b910b0c5-aa30-4e3f-8cc2-9aa38bc2e275@github.com>
Message-ID: <NE4Gf3PPe3lGStot3AN1sawwDaUyNV9GIeE2c2dtalI=.776c8fe7-ade4-4488-a278-cfb30d8b3d43@github.com>

On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source code in java.xml and java.xml.crypto. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

I understand. I just checked the git history and saw that there were other code hygiene changes. I'll close this issue then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6369

From ihse at openjdk.java.net  Mon Nov 15 10:42:39 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 15 Nov 2021 10:42:39 GMT
Subject: Withdrawn: 8277059: Use blessed modifier order in java.xml
In-Reply-To: <pUZQXiIlxmWw46uzKTyyhsWaGCwM4LyWE4efZViZIQY=.b910b0c5-aa30-4e3f-8cc2-9aa38bc2e275@github.com>
References: <pUZQXiIlxmWw46uzKTyyhsWaGCwM4LyWE4efZViZIQY=.b910b0c5-aa30-4e3f-8cc2-9aa38bc2e275@github.com>
Message-ID: <MgqNKzmfL92WzakZhEhzsnHPSTb4_MpD7CgKx3cGYx8=.6dda9395-06ec-407d-adad-031a5642e8ba@github.com>

On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source code in java.xml and java.xml.crypto. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6369

From mullan at openjdk.java.net  Mon Nov 15 17:11:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 15 Nov 2021 17:11:48 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath
Message-ID: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>

Please review this 20+ year old bug (!), which marks the non-serializable fields of Certificate and CertPath with the transient modifier. These classes use an alternate serialization mechanism by overriding the writeReplace method. However, the fields of each class were never marked as transient and as a result were incorrectly documented in the Serialized Form section of the javadoc.

-------------

Commit messages:
 - 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath

Changes: https://git.openjdk.java.net/jdk/pull/6392/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6392&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-4337793
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6392.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6392/head:pull/6392

PR: https://git.openjdk.java.net/jdk/pull/6392

From valeriep at openjdk.java.net  Mon Nov 15 18:20:37 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 15 Nov 2021 18:20:37 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath
In-Reply-To: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
Message-ID: <5r1fwALDfPyjlXOXsTHoooOJO_xxnPY4xp4FA2YUuC4=.6c3ea5ca-2d94-40f8-9bed-b4d1c8681705@github.com>

On Mon, 15 Nov 2021 17:03:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this 20+ year old bug (!), which marks the non-serializable fields of Certificate and CertPath with the transient modifier. These classes use an alternate serialization mechanism by overriding the writeReplace method. However, the fields of each class were never marked as transient and as a result were incorrectly documented in the Serialized Form section of the javadoc.

Marked as reviewed by valeriep (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6392

From rriggs at openjdk.java.net  Mon Nov 15 19:02:40 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 15 Nov 2021 19:02:40 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath
In-Reply-To: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
Message-ID: <vxF-Q96Iwe87t_-3nCMfu7-6LdUkDSxVnXHyJ8yJgRc=.13079cc9-5fc4-4967-8c1f-a9e67f56078d@github.com>

On Mon, 15 Nov 2021 17:03:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this 20+ year old bug (!), which marks the non-serializable fields of Certificate and CertPath with the transient modifier. These classes use an alternate serialization mechanism by overriding the writeReplace method. However, the fields of each class were never marked as transient and as a result were incorrectly documented in the Serialized Form section of the javadoc.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8277128

The serialized form doc for both classes should say something about what is serialized.
Since it is using writeReplace, it can indicate that CertificateRep/CertPathRep is used instead (and the arguments).
likely you'll need to use the @serial javadoc tag and check the generated javadoc to verify.

-------------

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6392

From mullan at openjdk.java.net  Mon Nov 15 19:08:39 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 15 Nov 2021 19:08:39 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath
In-Reply-To: <vxF-Q96Iwe87t_-3nCMfu7-6LdUkDSxVnXHyJ8yJgRc=.13079cc9-5fc4-4967-8c1f-a9e67f56078d@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
 <vxF-Q96Iwe87t_-3nCMfu7-6LdUkDSxVnXHyJ8yJgRc=.13079cc9-5fc4-4967-8c1f-a9e67f56078d@github.com>
Message-ID: <XzcvevyY7XDalp07so9fBO60jyzB0McRqh8L8tkdHsU=.a226acb6-8d17-4223-9d64-e2e6b77eebbf@github.com>

On Mon, 15 Nov 2021 18:59:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The serialized form doc for both classes should say something about what is serialized. Since it is using writeReplace, it can indicate that CertificateRep/CertPathRep is used instead (and the arguments). likely you'll need to use the @serial javadoc tag and check the generated javadoc to verify.

The `writeReplace` methods do have `@serial` tags, and they do show up in the Serialized Form of the javadoc, ex: https://docs.oracle.com/en/java/javase/17/docs/api/serialized-form.html#java.security.cert.Certificate

Is your comment more that these methods could more clearly specify what is returned?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6392

From rriggs at openjdk.java.net  Mon Nov 15 19:18:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 15 Nov 2021 19:18:41 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath
In-Reply-To: <XzcvevyY7XDalp07so9fBO60jyzB0McRqh8L8tkdHsU=.a226acb6-8d17-4223-9d64-e2e6b77eebbf@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
 <vxF-Q96Iwe87t_-3nCMfu7-6LdUkDSxVnXHyJ8yJgRc=.13079cc9-5fc4-4967-8c1f-a9e67f56078d@github.com>
 <XzcvevyY7XDalp07so9fBO60jyzB0McRqh8L8tkdHsU=.a226acb6-8d17-4223-9d64-e2e6b77eebbf@github.com>
Message-ID: <-dTklbWRCBwyhAeIzbMLHaXmCtWidy567VFNtDrvoW8=.33a48b39-b448-45aa-88be-a0fb06649be9@github.com>

On Mon, 15 Nov 2021 19:05:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > The serialized form doc for both classes should say something about what is serialized. Since it is using writeReplace, it can indicate that CertificateRep/CertPathRep is used instead (and the arguments). likely you'll need to use the @serial javadoc tag and check the generated javadoc to verify.
> 
> The `writeReplace` methods do have `@serial` tags, and they do show up in the Serialized Form of the javadoc, ex: https://docs.oracle.com/en/java/javase/17/docs/api/serialized-form.html#java.security.cert.Certificate
> 
> Is your comment more that these methods could more clearly specify what is returned?

The `@java.io.Serial` annotation doesn't add any description to the generated javadoc or serialized form doc.

The javadoc in the serialized for says only: "Replace the Certificate to be serialized."
For my purposes it would enough to reword it to say it returns a CertificateRep holding the type and data or something similar.
The `@serial` javadoc tag might be useful but not necessary if the regular javadoc that is in the serialized form doc is concrete.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6392

From mullan at openjdk.java.net  Mon Nov 15 21:53:56 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 15 Nov 2021 21:53:56 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath [v2]
In-Reply-To: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
Message-ID: <915qS8umidIbsCCeckeTUDgceKERBlHd1ISJBwCaqOQ=.91f0076f-9c8f-4bc2-9d7f-c3101bb33762@github.com>

> Please review this 20+ year old bug (!), which marks the non-serializable fields of Certificate and CertPath with the transient modifier. These classes use an alternate serialization mechanism by overriding the writeReplace method. However, the fields of each class were never marked as transient and as a result were incorrectly documented in the Serialized Form section of the javadoc.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8277128

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Improve writeReplace methods to better describe what object is returned.
  Small wording improvements and use of {@code} in readResolve methods and CertPath serial fields.
  Corrected typo in type param of CertPathRep ctor (should be "Certificate type" and not "CertPath type").

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6392/files
  - new: https://git.openjdk.java.net/jdk/pull/6392/files/98803b81..5bb207f7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6392&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6392&range=00-01

  Stats: 26 lines in 2 files changed: 7 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6392.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6392/head:pull/6392

PR: https://git.openjdk.java.net/jdk/pull/6392

From mullan at openjdk.java.net  Mon Nov 15 21:53:57 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 15 Nov 2021 21:53:57 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath [v2]
In-Reply-To: <-dTklbWRCBwyhAeIzbMLHaXmCtWidy567VFNtDrvoW8=.33a48b39-b448-45aa-88be-a0fb06649be9@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
 <vxF-Q96Iwe87t_-3nCMfu7-6LdUkDSxVnXHyJ8yJgRc=.13079cc9-5fc4-4967-8c1f-a9e67f56078d@github.com>
 <XzcvevyY7XDalp07so9fBO60jyzB0McRqh8L8tkdHsU=.a226acb6-8d17-4223-9d64-e2e6b77eebbf@github.com>
 <-dTklbWRCBwyhAeIzbMLHaXmCtWidy567VFNtDrvoW8=.33a48b39-b448-45aa-88be-a0fb06649be9@github.com>
Message-ID: <0BjIJm7uP6slBggE9KjknxBiTh24zgXzIzChcFuuAa8=.b3fdaea7-6ae0-45e3-a941-545c81788f59@github.com>

On Mon, 15 Nov 2021 19:15:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > > The serialized form doc for both classes should say something about what is serialized. Since it is using writeReplace, it can indicate that CertificateRep/CertPathRep is used instead (and the arguments). likely you'll need to use the @serial javadoc tag and check the generated javadoc to verify.
> > 
> > 
> > The `writeReplace` methods do have `@serial` tags, and they do show up in the Serialized Form of the javadoc, ex: https://docs.oracle.com/en/java/javase/17/docs/api/serialized-form.html#java.security.cert.Certificate
> > Is your comment more that these methods could more clearly specify what is returned?
> 
> The `@java.io.Serial` annotation doesn't add any description to the generated javadoc or serialized form doc.
> 
> The javadoc in the serialized for says only: "Replace the Certificate to be serialized." For my purposes it would enough to reword it to say it returns a CertificateRep holding the type and data or something similar. The `@serial` javadoc tag might be useful but not necessary if the regular javadoc that is in the serialized form doc is concrete.

Sounds good, see the latest commit for improvements to `writeReplace` and a few other wording improvements in related methods/fields.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6392

From rriggs at openjdk.java.net  Mon Nov 15 23:23:42 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 15 Nov 2021 23:23:42 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath [v2]
In-Reply-To: <915qS8umidIbsCCeckeTUDgceKERBlHd1ISJBwCaqOQ=.91f0076f-9c8f-4bc2-9d7f-c3101bb33762@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
 <915qS8umidIbsCCeckeTUDgceKERBlHd1ISJBwCaqOQ=.91f0076f-9c8f-4bc2-9d7f-c3101bb33762@github.com>
Message-ID: <eMh4TmrYIqf1EYNNV64FQIbhVezniBnQbx8E_ziciFA=.3499b94c-dbd1-456f-b132-218cb0e9fbac@github.com>

On Mon, 15 Nov 2021 21:53:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this 20+ year old bug (!), which marks the non-serializable fields of Certificate and CertPath with the transient modifier. These classes use an alternate serialization mechanism by overriding the writeReplace method. However, the fields of each class were never marked as transient and as a result were incorrectly documented in the Serialized Form section of the javadoc.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8277128
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve writeReplace methods to better describe what object is returned.
>   Small wording improvements and use of {@code} in readResolve methods and CertPath serial fields.
>   Corrected typo in type param of CertPathRep ctor (should be "Certificate type" and not "CertPath type").

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6392

From valeriep at openjdk.java.net  Mon Nov 15 23:41:36 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 15 Nov 2021 23:41:36 GMT
Subject: RFR: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath [v2]
In-Reply-To: <915qS8umidIbsCCeckeTUDgceKERBlHd1ISJBwCaqOQ=.91f0076f-9c8f-4bc2-9d7f-c3101bb33762@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
 <915qS8umidIbsCCeckeTUDgceKERBlHd1ISJBwCaqOQ=.91f0076f-9c8f-4bc2-9d7f-c3101bb33762@github.com>
Message-ID: <5anoX4vPPYLhlwEXX0nRBE8vLkuyH6FPQF_NsiAjHUU=.e370d7c0-0112-44f8-9044-d6e48003befa@github.com>

On Mon, 15 Nov 2021 21:53:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this 20+ year old bug (!), which marks the non-serializable fields of Certificate and CertPath with the transient modifier. These classes use an alternate serialization mechanism by overriding the writeReplace method. However, the fields of each class were never marked as transient and as a result were incorrectly documented in the Serialized Form section of the javadoc.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8277128
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve writeReplace methods to better describe what object is returned.
>   Small wording improvements and use of {@code} in readResolve methods and CertPath serial fields.
>   Corrected typo in type param of CertPathRep ctor (should be "Certificate type" and not "CertPath type").

Marked as reviewed by valeriep (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6392

From weijun at openjdk.java.net  Tue Nov 16 01:44:35 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 16 Nov 2021 01:44:35 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled
In-Reply-To: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
Message-ID: <v1srOR6FK3xmjqx-fd0AYIIq7LeDGSuBERGh6ds7W_I=.bbde808c-9e71-41b4-98eb-826a8afaaad7@github.com>

On Mon, 8 Nov 2021 14:04:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> When a signature/digest algorithm was being checked, the algorithm constraints checked both the signature/digest algorithm and the key to see if they were restricted. This caused duplicate checks and was also problematic for `jarsigner` (and `keytool`) which need to distinguish these two cases, so that the output can properly indicate when the key is disabled but the signature or digest alg is ok. 
> 
> To address this issue, a new `checkKey` parameter is added to the `DisabledAlgorithmConstraints.permits` methods. When `true` the key (alg and size) is also checked, otherwise it is not. This flag is always set to `false` by `jarsigner` when checking algs and by the JDK when checking digest algorithms. Other small changes include changes in `SignerInfo` to use a record to store info about the algorithms to be checked, and removing an unnecessary CRL checking method from `AlgorithmChecker`.
> 
> `keytool` will be enhanced in a subsequent CR to call the new methods.

I'm feeling we should completely dump checking for algorithms and switch to checking algorithmIds. Even if currently it's only RSASSA-PSS, but suppose one day we support the SHAKE256-LEN MessageDigest algorithm and I suppose that LEN cannot be any number.

src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 749:

> 747:         Set<String> enabledAlgorithms = new HashSet<>();
> 748:         try {
> 749:             for (Map.Entry<AlgorithmId, AlgorithmInfo> algorithm :

You can use `var`.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1491:

> 1489:     private static String checkWeakAlg(String alg, CertPathConstraintsParameters cpcp) {
> 1490:         try {
> 1491:             CERTPATH_DISABLED_CHECK.permits(alg, cpcp, false);

Do we need to check AlgorithmParamters as well? Ex: if `alg` is RSASSA-PSS.

test/jdk/sun/security/tools/jarsigner/TimestampCheck.java line 368:

> 366:                         .shouldNotContain("The SHA-256 algorithm specified " +
> 367:                             "for the -tsadigestalg option is considered a " +
> 368:                             "security risk and is disabled")

Maybe just check `.shouldNotContain("option is considered a security risk and is disabled")`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6296

From mullan at openjdk.java.net  Tue Nov 16 17:58:36 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 16 Nov 2021 17:58:36 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled
In-Reply-To: <v1srOR6FK3xmjqx-fd0AYIIq7LeDGSuBERGh6ds7W_I=.bbde808c-9e71-41b4-98eb-826a8afaaad7@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
 <v1srOR6FK3xmjqx-fd0AYIIq7LeDGSuBERGh6ds7W_I=.bbde808c-9e71-41b4-98eb-826a8afaaad7@github.com>
Message-ID: <fcyu1eDc3cRnkBG370yE-RYc0bAsPimLBfCIymPynbg=.7d625e8b-0f40-4f91-8397-7b95ad2236ab@github.com>

On Tue, 16 Nov 2021 01:41:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I'm feeling we should completely dump checking for algorithms and switch to checking algorithmIds. Even if currently it's only RSASSA-PSS, but suppose one day we support the SHAKE256-LEN MessageDigest algorithm and I suppose that LEN cannot be any number.

Yes, this is a good suggestion, but I think it should be tackled separately. I'll file a separate RFE though. It would be nice if we made AlgorithmId a public API too.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1491:
> 
>> 1489:     private static String checkWeakAlg(String alg, CertPathConstraintsParameters cpcp) {
>> 1490:         try {
>> 1491:             CERTPATH_DISABLED_CHECK.permits(alg, cpcp, false);
> 
> Do we need to check AlgorithmParamters as well? Ex: if `alg` is RSASSA-PSS.

We should, but the problem is that jarsigner needs to individually test each algorithm, so it can properly display which algorithm is restricted. So, I think it will need to parse the RSSASSA params itself, and then call the constraints code to check each algorithm. Let me see if I can code up something that does that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6296

From mullan at openjdk.java.net  Tue Nov 16 18:04:34 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 16 Nov 2021 18:04:34 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled
In-Reply-To: <v1srOR6FK3xmjqx-fd0AYIIq7LeDGSuBERGh6ds7W_I=.bbde808c-9e71-41b4-98eb-826a8afaaad7@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
 <v1srOR6FK3xmjqx-fd0AYIIq7LeDGSuBERGh6ds7W_I=.bbde808c-9e71-41b4-98eb-826a8afaaad7@github.com>
Message-ID: <4vktONRf4A9aRziyWnYgBbIdtEnia0Kme96zmwB0Njk=.ef7c743a-f802-48b6-83d2-9dfe3ad32db6@github.com>

On Tue, 16 Nov 2021 01:07:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When a signature/digest algorithm was being checked, the algorithm constraints checked both the signature/digest algorithm and the key to see if they were restricted. This caused duplicate checks and was also problematic for `jarsigner` (and `keytool`) which need to distinguish these two cases, so that the output can properly indicate when the key is disabled but the signature or digest alg is ok. 
>> 
>> To address this issue, a new `checkKey` parameter is added to the `DisabledAlgorithmConstraints.permits` methods. When `true` the key (alg and size) is also checked, otherwise it is not. This flag is always set to `false` by `jarsigner` when checking algs and by the JDK when checking digest algorithms. Other small changes include changes in `SignerInfo` to use a record to store info about the algorithms to be checked, and removing an unnecessary CRL checking method from `AlgorithmChecker`.
>> 
>> `keytool` will be enhanced in a subsequent CR to call the new methods.
>
> src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 749:
> 
>> 747:         Set<String> enabledAlgorithms = new HashSet<>();
>> 748:         try {
>> 749:             for (Map.Entry<AlgorithmId, AlgorithmInfo> algorithm :
> 
> You can use `var`.

Yes.

> test/jdk/sun/security/tools/jarsigner/TimestampCheck.java line 368:
> 
>> 366:                         .shouldNotContain("The SHA-256 algorithm specified " +
>> 367:                             "for the -tsadigestalg option is considered a " +
>> 368:                             "security risk and is disabled")
> 
> Maybe just check `.shouldNotContain("option is considered a security risk and is disabled")`?

Ok

-------------

PR: https://git.openjdk.java.net/jdk/pull/6296

From mullan at openjdk.java.net  Tue Nov 16 18:10:04 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 16 Nov 2021 18:10:04 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled [v2]
In-Reply-To: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
Message-ID: <e9BN0gJjXMa95F9RrMmGr5ZvEYWDNm2gVGAeq0ziFks=.7cabc485-18f9-4873-be3a-098a17881650@github.com>

> When a signature/digest algorithm was being checked, the algorithm constraints checked both the signature/digest algorithm and the key to see if they were restricted. This caused duplicate checks and was also problematic for `jarsigner` (and `keytool`) which need to distinguish these two cases, so that the output can properly indicate when the key is disabled but the signature or digest alg is ok. 
> 
> To address this issue, a new `checkKey` parameter is added to the `DisabledAlgorithmConstraints.permits` methods. When `true` the key (alg and size) is also checked, otherwise it is not. This flag is always set to `false` by `jarsigner` when checking algs and by the JDK when checking digest algorithms. Other small changes include changes in `SignerInfo` to use a record to store info about the algorithms to be checked, and removing an unnecessary CRL checking method from `AlgorithmChecker`.
> 
> `keytool` will be enhanced in a subsequent CR to call the new methods.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Use var in for loop in SignerInfo.
  In TimestampCheck test, combine/simplify what messages should not be emitted
  when jar is signed with 512-bit RSA key.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6296/files
  - new: https://git.openjdk.java.net/jdk/pull/6296/files/6c1f1dd8..ac6d9436

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6296&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6296&range=00-01

  Stats: 13 lines in 2 files changed: 0 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6296.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6296/head:pull/6296

PR: https://git.openjdk.java.net/jdk/pull/6296

From weijun at openjdk.java.net  Tue Nov 16 19:43:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 16 Nov 2021 19:43:49 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a TSA
 certificate
Message-ID: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>

There is no need to check for the KeyUsage extension when validating a TSA certificate.

A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.

-------------

Commit messages:
 - 8277246: No need to check about KeyUsage when validating a TSA certificate

Changes: https://git.openjdk.java.net/jdk/pull/6416/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6416&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277246
  Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6416.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6416/head:pull/6416

PR: https://git.openjdk.java.net/jdk/pull/6416

From xuelei at openjdk.java.net  Tue Nov 16 19:49:37 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 16 Nov 2021 19:49:37 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate
In-Reply-To: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
Message-ID: <vpp7b4grbTrvboXBk_K1LlB3SydixMTECVIncxxF9bU=.f9da72fa-e811-404e-8add-5e216cfb793b@github.com>

On Tue, 16 Nov 2021 19:36:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> There is no need to check for the KeyUsage extension when validating a TSA certificate.
> 
> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.

src/java.base/share/classes/sun/security/validator/EndEntityChecker.java line 364:

> 362:                 ValidatorException.T_EE_EXTENSIONS, cert);
> 363:         }
> 364: 

Could you add a comment here just in case someone else adding the checking back?  Otherwise, looks nice to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From xuelei at openjdk.java.net  Tue Nov 16 20:37:44 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 16 Nov 2021 20:37:44 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v6]
In-Reply-To: <f0zhWobY52A8vwr7VJa3y4NXChXrpPTS1dNxovmypIY=.476da511-a2c2-42d1-bb0a-b8dc1119e928@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <f0zhWobY52A8vwr7VJa3y4NXChXrpPTS1dNxovmypIY=.476da511-a2c2-42d1-bb0a-b8dc1119e928@github.com>
Message-ID: <NyrHr52ZdFB3OgMsbrMkFI8Xbb4SUDTYoXMKfq2i0AE=.b2c85be2-4029-4cdc-8ddc-016aa4425b53@github.com>

On Wed, 3 Nov 2021 09:16:47 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bugfix

> /integrate
> 
> tier1, tier2 and jdk_core are all clean now. I think we're good to go.
> 

Thanks, I will sponsor the integration soon.

> Do PKCS11 implementations release resources when doFinal is called? Our documentation for Cipher does not mention that doFinal should be called to release resources, and our PKCS11 guide doesn't say that providers should release resources when doFinal is called.

That's a pretty old and interesting topic.  I don't think doFinal could really have PKCS11 release its resources.  As there is not close APIs for key instance, there is not much we can do right now.  Maybe, we could consider to support closable keys in the future.

>   Do we need to dispose GCM ciphers? They always call init and doFinal in matching pairs, so the extra doFinal in dispose looks superfluous.

It makes sense.  But it may make it complicated to check different ciphers.  In the long run, the doFinal() should be replaced with something like close().

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From duke at openjdk.java.net  Tue Nov 16 20:37:45 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 16 Nov 2021 20:37:45 GMT
Subject: Integrated: 8275811 Incorrect instance to dispose
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <3MIYLSrpKzSR4GOPKt14zQ6s2v4hG5nARXt1ZPHeJzQ=.657e2662-5f13-43b6-931d-20423a1aef16@github.com>

On Fri, 22 Oct 2021 18:24:22 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

This pull request has now been integrated.

Changeset: cddc6ce4
Author:    Daniel Jelinski <djelinski1 at gmail.com>
Committer: Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cddc6ce44695cba4614c3405eb2b194d7c76489b
Stats:     35 lines in 4 files changed: 32 ins; 0 del; 3 mod

8275811: Incorrect instance to dispose

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/6084

From mstjohns at comcast.net  Tue Nov 16 20:52:01 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 16 Nov 2021 15:52:01 -0500
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate
In-Reply-To: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
Message-ID: <b9a3c0e6-fa61-3264-3244-d3ba3eaa9a44@comcast.net>

On 11/16/2021 2:43 PM, Weijun Wang wrote:
> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>
> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> -------------
>
> Commit messages:
>   - 8277246: No need to check about KeyUsage when validating a TSA certificate
>
> Changes:https://git.openjdk.java.net/jdk/pull/6416/files
>   Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=6416&range=00
>    Issue:https://bugs.openjdk.java.net/browse/JDK-8277246
>    Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
>    Patch:https://git.openjdk.java.net/jdk/pull/6416.diff
>    Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/6416/head:pull/6416
>
> PR:https://git.openjdk.java.net/jdk/pull/6416

I just ran this by one of the PKIX folk and this fix isn't correct.?? 
Basically, if a certificate has both an Extended Key Usage and a Key 
Usage extension? then they both have to be consistent with the actual 
purpose and both have to be checked. The former for the specific use 
described in the TSA document, and the latter for general use (RFC3280 
and 5280).

In this case, checkKeyUsage attempts to find? keyUsageExtension and if 
it's not present returns true (e.g. key usage is acceptable).? Otherwise 
it checks to see if there's a digitalSignature bit set, and if it's not 
set checkKeyUsage returns false.?? The code as written (before the 
change) is correct.? Here's the utility method in EndEntityChecker.java

>     /**
> 220      * Utility method checking if bit 'bit' is set in this certificates
> 221      * key usage extension.
> 222      * @throws CertificateException if not
> 223      */
> 224     private boolean checkKeyUsage(X509Certificate cert, int bit)
> 225             throws CertificateException {
> 226         boolean[] keyUsage = cert.getKeyUsage();
> 227         if (keyUsage == null) {
> 228             return true;
> 229         }
> 230         return (keyUsage.length > bit) && keyUsage[bit];
> 231     }


It would be acceptable to have a certificate without a 
keyUsageExtension, but if the KUE is present, then the digitalSignature 
bit needs to be set.

Recommend backing out the change and closing the bug report as mistaken.


Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211116/8421e5e3/attachment.htm>

From weijun at openjdk.java.net  Tue Nov 16 21:00:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 16 Nov 2021 21:00:12 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
Message-ID: <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>

> There is no need to check for the KeyUsage extension when validating a TSA certificate.
> 
> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  clarify RFC requirement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6416/files
  - new: https://git.openjdk.java.net/jdk/pull/6416/files/e7db147e..a5b3bc86

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6416&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6416&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6416.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6416/head:pull/6416

PR: https://git.openjdk.java.net/jdk/pull/6416

From weijun at openjdk.java.net  Tue Nov 16 21:05:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 16 Nov 2021 21:05:40 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
Message-ID: <jrBGUc1J-lr0yQHkpKF_QrHSecWH9brwWlC7H3iKWog=.515c2cff-6220-4baf-8186-52eca2b2327a@github.com>

On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify RFC requirement

Hi Michael. Thanks for the comment. That was also our previous understanding but we are seeing timestamp returning by sigstore.dev (see the `rekor timestamp` command at https://github.com/sigstore/rekor) whose cert does not have the DigitialSignature bit set.

-----BEGIN CERTIFICATE-----
MIIBvzCCAWWgAwIBAgICBnowCgYIKoZIzj0EAwIwHzEdMBsGA1UEChMUaHR0cHM6
Ly9zaWdzdG9yZS5kZXYwHhcNMjExMTAyMTgxODI5WhcNMzExMTAyMTgxODI5WjAi
MSAwHgYDVQQKExdSZWtvciBUaW1lc3RhbXBpbmcgQ2VydDBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABJIsOXOZUdgXhnNmvue9AAsxSYWdp+1HvEQQMYuZUsU0Ylf2
bKqIp3zVrc0a58pGJZvwGjyOHgY5lRevPP1huuOjgY0wgYowDgYDVR0PAQH/BAQD
AgZAMAwGA1UdEwEB/wQCMAAwDgYDVR0OBAcEBQECAwQGMB8GA1UdIwQYMBaAFIiV
AzEbE/rHgP3CA3x7tofqTtIcMCEGA1UdEQQaMBiHBH8AAAGHEAAAAAAAAAAAAAAA
AAAAAAEwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwgwCgYIKoZIzj0EAwIDSAAwRQIg
XdDBMPMTrtXiHmhFJOgQW8DDz/IaHkNZ+hXNL19dmuICIQCw3lE5+52F41kpY3B/
sJaPjuKmeIuEyYZDnMnlhHSusg==
-----END CERTIFICATE-----

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From xuelei at openjdk.java.net  Tue Nov 16 21:35:36 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 16 Nov 2021 21:35:36 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
Message-ID: <2UM_HhPpD6k6L128D8kKTC1XLsxPSSkHgeGf3_G_5qc=.59540786-d00d-4877-84e6-6f1cbc62933f@github.com>

On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify RFC requirement

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From mstjohns at comcast.net  Tue Nov 16 22:58:47 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 16 Nov 2021 17:58:47 -0500
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <jrBGUc1J-lr0yQHkpKF_QrHSecWH9brwWlC7H3iKWog=.515c2cff-6220-4baf-8186-52eca2b2327a@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
 <jrBGUc1J-lr0yQHkpKF_QrHSecWH9brwWlC7H3iKWog=.515c2cff-6220-4baf-8186-52eca2b2327a@github.com>
Message-ID: <88b0f16a-1ab4-8cc2-f092-c3cb1c2d2d6b@comcast.net>

On 11/16/2021 4:05 PM, Weijun Wang wrote:
> On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang<weijun at openjdk.org>  wrote:
>
>>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>>>
>>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    clarify RFC requirement
> Hi Michael. Thanks for the comment. That was also our previous understanding but we are seeing timestamp returning by sigstore.dev (see the `rekor timestamp` command athttps://github.com/sigstore/rekor) whose cert does not have the DigitialSignature bit set.
>
> -----BEGIN CERTIFICATE-----
> MIIBvzCCAWWgAwIBAgICBnowCgYIKoZIzj0EAwIwHzEdMBsGA1UEChMUaHR0cHM6
> Ly9zaWdzdG9yZS5kZXYwHhcNMjExMTAyMTgxODI5WhcNMzExMTAyMTgxODI5WjAi
> MSAwHgYDVQQKExdSZWtvciBUaW1lc3RhbXBpbmcgQ2VydDBZMBMGByqGSM49AgEG
> CCqGSM49AwEHA0IABJIsOXOZUdgXhnNmvue9AAsxSYWdp+1HvEQQMYuZUsU0Ylf2
> bKqIp3zVrc0a58pGJZvwGjyOHgY5lRevPP1huuOjgY0wgYowDgYDVR0PAQH/BAQD
> AgZAMAwGA1UdEwEB/wQCMAAwDgYDVR0OBAcEBQECAwQGMB8GA1UdIwQYMBaAFIiV
> AzEbE/rHgP3CA3x7tofqTtIcMCEGA1UdEQQaMBiHBH8AAAGHEAAAAAAAAAAAAAAA
> AAAAAAEwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwgwCgYIKoZIzj0EAwIDSAAwRQIg
> XdDBMPMTrtXiHmhFJOgQW8DDz/IaHkNZ+hXNL19dmuICIQCw3lE5+52F41kpY3B/
> sJaPjuKmeIuEyYZDnMnlhHSusg==
> -----END CERTIFICATE-----
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/6416

The certificate is either incorrect, or weird and correct. I actually 
think its incorrect, but let's assume the latter and that either of 
these two key purposes can be used. ? ? Change the check to permit 
either of the two KUs in a? KeyUsageExtension:


// insert around line 109.

private static final int KU_NON_REPUDIATION = 1;

// replace line 359.

if (checkKeyUsage (cert, KU_SIGNATURE) == false && checkKeyUsage(cert, 
KU_NON_REPUDATION) == false) {

 From RFC5280:

> The digitalSignature bit is asserted when the subject public key
>        is used for verifying digital signatures, other than signatures on
>        certificates (bit 5) and CRLs (bit 6), such as those used in an
>        entity authentication service, a data origin authentication
>        service, and/or an integrity service.
>
>        The nonRepudiation bit is asserted when the subject public key is
>        used to verify digital signatures, other than signatures on
>        certificates (bit 5) and CRLs (bit 6), used to provide a non-
>        repudiation service that protects against the signing entity
>        falsely denying some action.  In the case of later conflict, a
>        reliable third party may determine the authenticity of the signed
>        data.  (Note that recent editions of X.509 have renamed the
>        nonRepudiation bit to contentCommitment.)

In any event, if you have a KU extension and it includes neither of 
these bits, the certificate is invalid for timestamping.? So simply 
deleting the check is wrong.

I'll reach out again to my expert and let you know what I find out.

Thanks - Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211116/33dd02d1/attachment.htm>

From weijun at openjdk.java.net  Tue Nov 16 23:28:36 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 16 Nov 2021 23:28:36 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
Message-ID: <d0szp_2SjSJ97bcEfvdpiIy_9w3CUIVh898cQ5kuUg0=.83c37d6e-1a8c-4736-af41-55f150e391b7@github.com>

On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify RFC requirement

Sean found RFC 5280, 4.2.1.12:

   id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
   -- Binding the hash of an object to a time
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation

so it seems either is OK. That said, it's just a "may", and to me it reads more like that others are NOT consistent and should be rejected.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From weijun at openjdk.java.net  Tue Nov 16 23:37:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 16 Nov 2021 23:37:39 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
Message-ID: <srpH90N6HSEZDkyMeYlXKoruYl8hYZJCl6NNuxNtmI4=.4876a188-a36b-447f-bf41-b2cfbb13d116@github.com>

On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify RFC requirement

I did see an issuer of TSA certs whose own certificate has EKU with id-kp-timeStamping and KU with both DigitialSignature and keyCertsign. This cert should be rejected if it signed a timestamp response.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From mstjohns at comcast.net  Tue Nov 16 23:39:35 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 16 Nov 2021 18:39:35 -0500
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <88b0f16a-1ab4-8cc2-f092-c3cb1c2d2d6b@comcast.net>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
 <jrBGUc1J-lr0yQHkpKF_QrHSecWH9brwWlC7H3iKWog=.515c2cff-6220-4baf-8186-52eca2b2327a@github.com>
 <88b0f16a-1ab4-8cc2-f092-c3cb1c2d2d6b@comcast.net>
Message-ID: <56e24a64-3147-c584-f9cb-2f4d75eb18c9@comcast.net>

On 11/16/2021 5:58 PM, Michael StJohns wrote:
> On 11/16/2021 4:05 PM, Weijun Wang wrote:
>> On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang<weijun at openjdk.org>  wrote:
>>
>>>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>>>>
>>>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    clarify RFC requirement
>> Hi Michael. Thanks for the comment. That was also our previous understanding but we are seeing timestamp returning by sigstore.dev (see the `rekor timestamp` command athttps://github.com/sigstore/rekor) whose cert does not have the DigitialSignature bit set.
>>
>> -----BEGIN CERTIFICATE-----
>> MIIBvzCCAWWgAwIBAgICBnowCgYIKoZIzj0EAwIwHzEdMBsGA1UEChMUaHR0cHM6
>> Ly9zaWdzdG9yZS5kZXYwHhcNMjExMTAyMTgxODI5WhcNMzExMTAyMTgxODI5WjAi
>> MSAwHgYDVQQKExdSZWtvciBUaW1lc3RhbXBpbmcgQ2VydDBZMBMGByqGSM49AgEG
>> CCqGSM49AwEHA0IABJIsOXOZUdgXhnNmvue9AAsxSYWdp+1HvEQQMYuZUsU0Ylf2
>> bKqIp3zVrc0a58pGJZvwGjyOHgY5lRevPP1huuOjgY0wgYowDgYDVR0PAQH/BAQD
>> AgZAMAwGA1UdEwEB/wQCMAAwDgYDVR0OBAcEBQECAwQGMB8GA1UdIwQYMBaAFIiV
>> AzEbE/rHgP3CA3x7tofqTtIcMCEGA1UdEQQaMBiHBH8AAAGHEAAAAAAAAAAAAAAA
>> AAAAAAEwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwgwCgYIKoZIzj0EAwIDSAAwRQIg
>> XdDBMPMTrtXiHmhFJOgQW8DDz/IaHkNZ+hXNL19dmuICIQCw3lE5+52F41kpY3B/
>> sJaPjuKmeIuEyYZDnMnlhHSusg==
>> -----END CERTIFICATE-----
>>
>> -------------
>>
>> PR:https://git.openjdk.java.net/jdk/pull/6416
>
> The certificate is either incorrect, or weird and correct. I actually 
> think its incorrect, but let's assume the latter and that either of 
> these two key purposes can be used. ? ? Change the check to permit 
> either of the two KUs in a KeyUsageExtension:
>
>
> // insert around line 109.
>
> private static final int KU_NON_REPUDIATION = 1;
>
> // replace line 359.
>
> if (checkKeyUsage (cert, KU_SIGNATURE) == false && checkKeyUsage(cert, 
> KU_NON_REPUDATION) == false) {
>
> From RFC5280:
>
>> The digitalSignature bit is asserted when the subject public key
>>        is used for verifying digital signatures, other than signatures on
>>        certificates (bit 5) and CRLs (bit 6), such as those used in an
>>        entity authentication service, a data origin authentication
>>        service, and/or an integrity service.
>>
>>        The nonRepudiation bit is asserted when the subject public key is
>>        used to verify digital signatures, other than signatures on
>>        certificates (bit 5) and CRLs (bit 6), used to provide a non-
>>        repudiation service that protects against the signing entity
>>        falsely denying some action.  In the case of later conflict, a
>>        reliable third party may determine the authenticity of the signed
>>        data.  (Note that recent editions of X.509 have renamed the
>>        nonRepudiation bit to contentCommitment.)
>
> In any event, if you have a KU extension and it includes neither of 
> these bits, the certificate is invalid for timestamping.? So simply 
> deleting the check is wrong.
>
> I'll reach out again to my expert and let you know what I find out.
>
> Thanks - Mike
>
>
According to the guy who wrote RFC5280, nonRepudiation (aka 
contentCommitment) is a valid alternative for a keyUsage that pairs with 
an extended key usage of id-kp-timestamping.? I'd add a check that 
requires one or the other or both if a KeyUsage extension exists.

I added a note to the Rekor CA repository, hopefully at the correct 
location suggesting they set both bits going forward. This was code they 
published only back in May.

Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211116/166139c0/attachment.htm>

From mstjohns at comcast.net  Tue Nov 16 23:43:31 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 16 Nov 2021 18:43:31 -0500
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <srpH90N6HSEZDkyMeYlXKoruYl8hYZJCl6NNuxNtmI4=.4876a188-a36b-447f-bf41-b2cfbb13d116@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
 <srpH90N6HSEZDkyMeYlXKoruYl8hYZJCl6NNuxNtmI4=.4876a188-a36b-447f-bf41-b2cfbb13d116@github.com>
Message-ID: <234b5c30-4d38-720c-b22f-10b0464392f3@comcast.net>

On 11/16/2021 6:37 PM, Weijun Wang wrote:
> On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:
>
>>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>>>
>>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    clarify RFC requirement
> I did see an issuer of TSA certs whose own certificate has EKU with id-kp-timeStamping and KU with both DigitialSignature and keyCertsign. This cert should be rejected if it signed a timestamp response.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/6416

Not quite.?? The rule is that if there's both an ExtendedKeyUsage and 
KeyUsage extensions, for any given OID in the EKU there has to be at 
least one bit in the KeyUsage extenstion that's compatible - there may 
be more than one.? If there's an EKU, and no KeyUsage, then only the EKU 
needs to have an OID for the key usage purpose - in this case signing a 
timestamp.

The cert you cite would be valid for timestamping.

Mike



From weijun at openjdk.java.net  Wed Nov 17 00:46:35 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 17 Nov 2021 00:46:35 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
Message-ID: <5gxBcuOJasvyy838GOcCzCqJWo-RJdeo4o9awoX2fZc=.efc8a35f-014e-40c5-9935-8e3a81009ce7@github.com>

On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify RFC requirement

Really? The TSA is http://timestamp.digicert.com and the cert chain is

CN=DigiCert Timestamp 2021, O="DigiCert, Inc.", C=US
KeyUsage: DigitalSignature
ExtendedKeyUsages: timeStamping

CN=DigiCert SHA2 Assured ID Timestamping CA, OU=www.digicert.com, O=DigiCert Inc, C=US
KeyUsage: DigitalSignature,  Key_CertSign, Crl_Sign
ExtendedKeyUsages: timeStamping

You mean this CA can be used for time stamping as well? I understand that when KU is using you can find out its usage in EKU (vice versa), but here it's a CA that can sign cert and CRLs. Does it really need to act as the end entity cert of a TSA server?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From mstjohns at comcast.net  Wed Nov 17 03:28:26 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 16 Nov 2021 22:28:26 -0500
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <5gxBcuOJasvyy838GOcCzCqJWo-RJdeo4o9awoX2fZc=.efc8a35f-014e-40c5-9935-8e3a81009ce7@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
 <5gxBcuOJasvyy838GOcCzCqJWo-RJdeo4o9awoX2fZc=.efc8a35f-014e-40c5-9935-8e3a81009ce7@github.com>
Message-ID: <bd95dbb8-04cb-958f-5f49-2faedee5ff58@comcast.net>

On 11/16/2021 7:46 PM, Weijun Wang wrote:
> On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang<weijun at openjdk.org>  wrote:
>
>>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>>>
>>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    clarify RFC requirement
> Really? The TSA ishttp://timestamp.digicert.com  and the cert chain is
>
> CN=DigiCert Timestamp 2021, O="DigiCert, Inc.", C=US
> KeyUsage: DigitalSignature
> ExtendedKeyUsages: timeStamping
>
> CN=DigiCert SHA2 Assured ID Timestamping CA, OU=www.digicert.com, O=DigiCert Inc, C=US
> KeyUsage: DigitalSignature,  Key_CertSign, Crl_Sign
> ExtendedKeyUsages: timeStamping
>
> You mean this CA can be used for time stamping as well? I understand that when KU is using you can find out its usage in EKU (vice versa), but here it's a CA that can sign cert and CRLs. Does it really need to act as the end entity cert of a TSA server?
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/6416

It doesn't need to act as an EE of a TSA server, but with those markings 
it can.

Whoever issued these over marked them.?? I think their intent was to say 
that this CA chain would issue time stamp issuing certificates, but? 
extendedKeyUsage contents are not transitive to the subordinate 
certificates so that extension is pretty much extraneous in a CA.? That 
said, if you got a timestamp verifiable by the public key in this CA 
certificate it would be valid (based on the certificate only).??? The 
TSA RFC doesn't actually prohibit having a basicConstraints ca=true 
extension.?? If I were verifying a timestamp, I'd probably filter out 
any signatures from certificates that are claiming to be CAs, but that's 
not strictly according to standards.


If I were issuing this chain, there would be no extendedKeyUsage 
extensions in the intermediate certificate(s), and the keyPurpose would 
only be keyCertSign or keyCertSign,cRLSign depending.? The EE 
certificate would have eku {id-kp-timestamping} and ku { 
digitalSignature } as I probably couldn't ensure non-repudiation for the 
time stamp (not the data being wrapped by the timestamp which is what 
the Rekor chain is trying to claim I think).


Hmm... while I was researching - I found this in RFC5280 - 4.2.1.12 
defining extendedKeyUsage oids:

>   This extension indicates one or more purposes for which the certified
>     public key may be used, in addition to or in place of the basic
>     purposes indicated in the key usage extension._In general, this extension will appear only in end entity certificates._   This
>     extension is defined as follows

and

>     id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
>     -- Binding the hash of an object to a time
>     -- Key usage bits that may be consistent:_digitalSignature_
>     -- and/or_nonRepudiation_

I hope that helps.


Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211116/be8baa79/attachment.htm>

From xuelei.fan at oracle.com  Wed Nov 17 05:46:20 2021
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 17 Nov 2021 05:46:20 +0000
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <bd95dbb8-04cb-958f-5f49-2faedee5ff58@comcast.net>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
 <5gxBcuOJasvyy838GOcCzCqJWo-RJdeo4o9awoX2fZc=.efc8a35f-014e-40c5-9935-8e3a81009ce7@github.com>
 <bd95dbb8-04cb-958f-5f49-2faedee5ff58@comcast.net>
Message-ID: <E74B71A9-7555-4DA7-B14A-749AC3ADE671@oracle.com>


On Nov 16, 2021, at 7:28 PM, Michael StJohns <mstjohns at comcast.net<mailto:mstjohns at comcast.net>> wrote:


   id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
   -- Binding the hash of an object to a time
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation

Hm, we may want to check it strictly in this update, by allowing nonRepudiation alternatively.

Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211117/44e73ed8/attachment-0001.htm>

From weijun at openjdk.java.net  Wed Nov 17 14:06:00 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 17 Nov 2021 14:06:00 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v3]
In-Reply-To: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
Message-ID: <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>

> There is no need to check for the KeyUsage extension when validating a TSA certificate.
> 
> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  check either KU_SIGNATURE or KU_NON_REPUDIATION

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6416/files
  - new: https://git.openjdk.java.net/jdk/pull/6416/files/a5b3bc86..2bd3c546

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6416&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6416&range=01-02

  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6416.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6416/head:pull/6416

PR: https://git.openjdk.java.net/jdk/pull/6416

From weijun at openjdk.java.net  Wed Nov 17 14:06:01 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 17 Nov 2021 14:06:01 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v2]
In-Reply-To: <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <PuVdWfvSSoh9r4qswzWqda2yba9ATb4SLaPiv4T37Gw=.41af60c8-9190-4598-aa94-3e48c38d4878@github.com>
Message-ID: <6v7cz75eOG8KToz91FQrv82y1GvNQVFF_yBqd4ChWYg=.4214213d-a412-4efb-b1d0-32ad7b81adcd@github.com>

On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify RFC requirement

Revert the removal and add check on nonRepudiation as well. And the test still works. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From mullan at openjdk.java.net  Wed Nov 17 14:19:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 17 Nov 2021 14:19:48 GMT
Subject: RFR: 8277246: No need to check about KeyUsage when validating a
 TSA certificate [v3]
In-Reply-To: <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>
Message-ID: <Az0esKNVwSEYEo5HEITiv59N_wCGFW4W3vzzEio04gM=.b1d0c149-a602-455c-ac1f-cf48f91ee017@github.com>

On Wed, 17 Nov 2021 14:06:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check either KU_SIGNATURE or KU_NON_REPUDIATION

Can you change the synopsis of the bug to more accurately reflect the current fix?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From weijun at openjdk.java.net  Wed Nov 17 14:27:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 17 Nov 2021 14:27:38 GMT
Subject: RFR: 8277246: Check for NonRepudiation as well when validating a
 TSA certificate [v3]
In-Reply-To: <Az0esKNVwSEYEo5HEITiv59N_wCGFW4W3vzzEio04gM=.b1d0c149-a602-455c-ac1f-cf48f91ee017@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>
 <Az0esKNVwSEYEo5HEITiv59N_wCGFW4W3vzzEio04gM=.b1d0c149-a602-455c-ac1f-cf48f91ee017@github.com>
Message-ID: <LMaQIHzKf1m25ucl-tu6648NYFTkC4k2lN8t80WdXZA=.cff1d635-4cdc-4afd-b7a9-9a1310c06b1a@github.com>

On Wed, 17 Nov 2021 14:16:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Can you change the synopsis of the bug to more accurately reflect the current fix?

Updated. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From mullan at openjdk.java.net  Wed Nov 17 14:43:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 17 Nov 2021 14:43:38 GMT
Subject: RFR: 8277246: Check for NonRepudiation as well when validating a
 TSA certificate [v3]
In-Reply-To: <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>
Message-ID: <RgN8yVajuUvIdgTAdehuLDBjfAm5RaFAdKZY-dgN1xk=.06b811a7-5ede-4c41-ad4a-77c08228c2a2@github.com>

On Wed, 17 Nov 2021 14:06:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check either KU_SIGNATURE or KU_NON_REPUDIATION

Marked as reviewed by mullan (Reviewer).

> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
> 
> On 11/16/2021 7:46 PM, Weijun Wang wrote:
> 
> It doesn't need to act as an EE of a TSA server, but with those markings it can.
> 
> Whoever issued these over marked them.?? I think their intent was to say that this CA chain would issue time stamp issuing certificates, but? extendedKeyUsage contents are not transitive to the subordinate certificates so that extension is pretty much extraneous in a CA.? That said, if you got a timestamp verifiable by the public key in this CA certificate it would be valid (based on the certificate only).??? The TSA RFC doesn't actually prohibit having a basicConstraints ca=true extension.?? If I were verifying a timestamp, I'd probably filter out any signatures from certificates that are claiming to be CAs, but that's not strictly according to standards.

I agree that having a CA act as a TSA is probably a bad idea. However, I don't think this particular CA is acting as a TSA, just looks like they overmarked it as you say.

In any case, I agree we should allow the KU of a TSA cert to be absent or if present it must contain a non-repudiation and/or digitalSignature bit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From coffeys at openjdk.java.net  Wed Nov 17 16:08:54 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 17 Nov 2021 16:08:54 GMT
Subject: RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
Message-ID: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>

Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need to account for that.

-------------

Commit messages:
 - 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE

Changes: https://git.openjdk.java.net/jdk/pull/6433/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6433&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277224
  Stats: 15 lines in 2 files changed: 10 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6433/head:pull/6433

PR: https://git.openjdk.java.net/jdk/pull/6433

From weijun at openjdk.java.net  Wed Nov 17 16:55:36 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 17 Nov 2021 16:55:36 GMT
Subject: RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws
 NPE
In-Reply-To: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
References: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
Message-ID: <9USCSdMt9nSQKDJ_AvyTN6yexcHZH5Rub3B-E30Ripc=.59ece75d-858c-434e-8e2f-0204780d922f@github.com>

On Wed, 17 Nov 2021 16:00:04 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need to account for that.

test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java line 67:

> 65:         // test PKCS9Attributes.toString(), PKCS9Attributes.getAttributes()
> 66:         System.out.println(authed);
> 67:         authed.getAttributes();

Looks like the old `getAttributes()` would only throw NPE if one of the attribute is of a type after `PKCS9_OIDS[10]`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6433

From coffeys at openjdk.java.net  Wed Nov 17 17:13:24 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 17 Nov 2021 17:13:24 GMT
Subject: RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws
 NPE
In-Reply-To: <9USCSdMt9nSQKDJ_AvyTN6yexcHZH5Rub3B-E30Ripc=.59ece75d-858c-434e-8e2f-0204780d922f@github.com>
References: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
 <9USCSdMt9nSQKDJ_AvyTN6yexcHZH5Rub3B-E30Ripc=.59ece75d-858c-434e-8e2f-0204780d922f@github.com>
Message-ID: <tL_TPl3QCtawMpOk9YB-7RxCrWgNgu0c0ml2SdF8VoE=.d6156e57-de27-456d-818b-764fda0d69b1@github.com>

On Wed, 17 Nov 2021 16:52:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need to account for that.
>
> test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java line 67:
> 
>> 65:         // test PKCS9Attributes.toString(), PKCS9Attributes.getAttributes()
>> 66:         System.out.println(authed);
>> 67:         authed.getAttributes();
> 
> Looks like the old `getAttributes()` would only throw NPE if one of the attribute is of a type after `PKCS9_OIDS[10]`.

Yes - its also bounded by the "attribs.length" check. I initially thought I'd have to build an PKCS9Attributes Object consisting of 10/11+ PKCS9Attribute Objects. That didn't seem feasible since many are not supported. 

but on re-read, yes, all I need to do is stick in an OID > PKCS9_OIDS[10] - I'll update the testcase.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6433

From coffeys at openjdk.java.net  Wed Nov 17 17:27:05 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 17 Nov 2021 17:27:05 GMT
Subject: RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws
 NPE [v2]
In-Reply-To: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
References: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
Message-ID: <U0CtXkJGMai4LCvM6MRtyLmfEh-rjLVHrRAxNViCyX4=.a3ac5b5c-018a-4456-83b6-4d994732d31b@github.com>

> Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need to account for that.

Sean Coffey 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/6433/files
  - new: https://git.openjdk.java.net/jdk/pull/6433/files/9755fa81..a134fab5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6433&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6433&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6433/head:pull/6433

PR: https://git.openjdk.java.net/jdk/pull/6433

From weijun at openjdk.java.net  Wed Nov 17 17:27:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 17 Nov 2021 17:27:11 GMT
Subject: RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws
 NPE [v2]
In-Reply-To: <U0CtXkJGMai4LCvM6MRtyLmfEh-rjLVHrRAxNViCyX4=.a3ac5b5c-018a-4456-83b6-4d994732d31b@github.com>
References: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
 <U0CtXkJGMai4LCvM6MRtyLmfEh-rjLVHrRAxNViCyX4=.a3ac5b5c-018a-4456-83b6-4d994732d31b@github.com>
Message-ID: <fcMFJmhq79UgN42qTmFhl7szqXdQSecOuPShPWD0gpY=.e4ee3fc9-a8aa-4c47-9b57-1d0a39630025@github.com>

On Wed, 17 Nov 2021 17:16:38 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need to account for that.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6433

From weijun at openjdk.java.net  Wed Nov 17 20:07:48 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 17 Nov 2021 20:07:48 GMT
Subject: Integrated: 8277246: Check for NonRepudiation as well when validating
 a TSA certificate
In-Reply-To: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
Message-ID: <SZZaL1C-FuaFlw5IpopitArn6PskIQUVFt-c3QB-j0Y=.316fa400-dcb5-423d-a6d9-e805fb0ddf6d@github.com>

On Tue, 16 Nov 2021 19:36:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> There is no need to check for the KeyUsage extension when validating a TSA certificate.
> 
> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.

This pull request has now been integrated.

Changeset: 262d0700
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/262d07001babcbe7f9acd2053aa3b7bac304cf85
Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod

8277246: Check for NonRepudiation as well when validating a TSA certificate

Reviewed-by: xuelei, mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From mbalao at openjdk.java.net  Wed Nov 17 20:23:43 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Wed, 17 Nov 2021 20:23:43 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
 <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>
Message-ID: <fWstzCufRv4o3funwtWjs-87MnR_uIdg_ph66GjVxX8=.7f8beed4-d731-4b57-81de-626d42aaebfc@github.com>

On Tue, 2 Nov 2021 22:44:16 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   P11Key static inner classes refactorings.
>
> Hi Martin,
> 
> Please find my comments in line below.
> 
>>     * Changing P11PrivateKey::getFormat to return 'PKCS#8' and not overriding this method on opaque/sensitive private key classes will be an observable change, and it does not match what's specified in Key::getFormat: 'Returns the name of the primary encoding format of this key, or null if this key does not support encoding.'. My thinking here is that an opaque key does not support encoding because its value is not even accessible.
> 
> Hmm, good point. I agree that returning null as default format and override it whenever an encoding is returned is the right thing to do.
> 
>>     * P11PrivateKeyRSA and P11RSAPrivateKey class names look confusing to me (where 'RSA' is located does not say anything about the class to me at least). The 'Opaque' suffix for the one that is package-private might be a better choice. I used the suffice 'Internal' before but now I like 'Opaque' more.
> 
> Sure, I didn't spend much time on this. Either Opaque or Internal suffix is fine. Generally I prefer shorter names.
> 
>>     * P11PrivateKeyRSA::of duplicates the attributes retrieval logic (session.token.p11::C_GetAttributeValue call), which is there and in P11Key::fetchAttributes. Sensitive RSA keys get the attributes from one place and non-sensitive from the other. This does not look to me an advantage when compared to the Fetcher, which does the same for RSA and uses P11Key::fetchAttributes for the others. However, having all the RSA-related logic in P11RSAAttributesFetcher::doFetchValues makes it a bit easier for me to reason about the 4 different scenarios to get the data: CRT + sensitive, non-CRT + sensitive, CRT + non-sensitive and non-CRT + non-sensitive.
> 
> This is where our view differs. We both have same class hierarchy but where the attributes are managed are different, you put all of them in the very bottom, i.e. fetcher, but I prefer them to be at top. Using RSA as an example, there are P11RSAPrivateKeyInternal - sensitive private key
> P11RSAPrivateKey - non-sensitive CRT private key
> P11RSAPrivateNonCRTKey - non-sensitive non-CRT private key
> P11RSAPublicKey - public key
> They all use the same P11RSAAttributesFetcher class but with different keySensitive, isPrivate flags to decide which attributes to query and which fields to populate. Whether the fields are null or not, the upper classes have no idea. The logic are all inside the fetcher. The keySensitive, isPrivate flags also have to be passed all around which seems strange as the classes themselves already implied these values and should not need to take arguments, i.e. P11RSAPrivateKey (keySensitive== false AND isPrivate == true). Overall, I find it hard to read. Comparing the fetcher model vs the non-fetcher model, the non-fetcher model has less code (at least 100 lines less) and it's very clear which attributes each class requires.
> 
>>     * By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.
> 
> There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.
> 
>>     * P11PrivateKeyRSA does not make the CRT/non-CRT distinction for sensitive keys, so the public exponent is not obtained when it could be. This is a bit less functionality than what the Fetcher provides, and would require a few changes to fit it into the design.
> 
> The proposed P11RSAPrivateKeyInternal class has no method for returning the public exponent either. If needed, it should be doable by adding extra attribute to the list of attributes in P11PrivateKeyRSA class. Should be trivial.
> 
> I updated the class naming in my prototype to align with yours and updated the prototype changes with your feedback. You can check/compare it at: http://cr.openjdk.java.net/~valeriep/8271566/webrev.01/
> 
> We have different views on this I guess. I prefer to let each class manage their list of attributes instead of a separate fetcher with their own logic. Former also has less code and follows the same model of existing code.
>  
> Thanks,
> Valerie

Hi @valeriepeng ,

Thanks for having a look at this. While we might have slightly different views on the fetcher, I appreciate that you took the time to explain your reasons. In any case, I believe that this iteration will be a significant improvement when compared to the old code, so I'm good to move forward on that. I'll check the other discussion points and your Webrev.01 proposal as soon as possible.

Martin.-

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From coffeys at openjdk.java.net  Wed Nov 17 20:53:46 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 17 Nov 2021 20:53:46 GMT
Subject: Integrated: 8277224: sun.security.pkcs.PKCS9Attributes.toString()
 throws NPE
In-Reply-To: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
References: <9pzG9jEiHMG5bujJfv8p3yM2TgzOyb9RX386gUkVyks=.10873c85-39d0-46e6-8441-3e948e9a388d@github.com>
Message-ID: <lUZ68VlGkD3G5ojZTZkEc4ixhqON302pMvrNfjNCzhA=.0634e567-4ed2-4511-9e9d-12f47e409b82@github.com>

On Wed, 17 Nov 2021 16:00:04 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need to account for that.

This pull request has now been integrated.

Changeset: 6bb04626
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6bb04626af6574ef1e8d4b7dad0389d4b59f5d08
Stats:     16 lines in 2 files changed: 11 ins; 2 del; 3 mod

8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/6433

From mbalao at openjdk.java.net  Wed Nov 17 21:28:45 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Wed, 17 Nov 2021 21:28:45 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
 <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>
Message-ID: <MunG7ACIrKQICX9V9VhbC2UxSMZylDb8XHPXTH41OEM=.e1b34735-cb9f-4899-9147-7645a79540e8@github.com>

On Tue, 2 Nov 2021 22:44:16 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> > ```
> > * By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.
> > ```
> 
> There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.
> 

In my view (Webrev.00 based comment), the variable 'n' holding the modulus value is private in P11RSAPrivateKey. This means that when P11PrivateKeyRSA::getModulus is called, P11PrivateKeyRSA::n (which is protected) has a 'null' value and the PKCS#11 lib call is done again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From mullan at openjdk.java.net  Thu Nov 18 13:51:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 18 Nov 2021 13:51:48 GMT
Subject: Integrated: 4337793: Mark non-serializable fields of
 java.security.cert.Certificate and CertPath
In-Reply-To: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
References: <K5YUTM2PG9U_ZJXKMq3aI19Ak43Y0UJP5j00hOqVQl4=.a723b7a1-09ed-4013-a4cf-fb8201d5c336@github.com>
Message-ID: <P5RSY2ZUDHZPg3fdRv3QS98A6OgEOY3MGwRulS2DVrI=.8c5aa82f-143c-4df4-b348-c8bb2c13a1a2@github.com>

On Mon, 15 Nov 2021 17:03:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this 20+ year old bug (!), which marks the non-serializable fields of Certificate and CertPath with the transient modifier. These classes use an alternate serialization mechanism by overriding the writeReplace method. However, the fields of each class were never marked as transient and as a result were incorrectly documented in the Serialized Form section of the javadoc.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8277128

This pull request has now been integrated.

Changeset: a44b45fd
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a44b45fdf31275a2c1e9d1d0132874a7de45f8ee
Stats:     29 lines in 2 files changed: 7 ins; 0 del; 22 mod

4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath

Reviewed-by: valeriep, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/6392

From mullan at openjdk.java.net  Thu Nov 18 15:06:45 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 18 Nov 2021 15:06:45 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled [v2]
In-Reply-To: <fcyu1eDc3cRnkBG370yE-RYc0bAsPimLBfCIymPynbg=.7d625e8b-0f40-4f91-8397-7b95ad2236ab@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
 <v1srOR6FK3xmjqx-fd0AYIIq7LeDGSuBERGh6ds7W_I=.bbde808c-9e71-41b4-98eb-826a8afaaad7@github.com>
 <fcyu1eDc3cRnkBG370yE-RYc0bAsPimLBfCIymPynbg=.7d625e8b-0f40-4f91-8397-7b95ad2236ab@github.com>
Message-ID: <nZCwWktdD_0W2Zd171MSWxt6MILWcrPMsdtmEyCory4=.25a690dc-840e-4594-a601-1c2140e4dea3@github.com>

On Tue, 16 Nov 2021 17:53:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1491:
>> 
>>> 1489:     private static String checkWeakAlg(String alg, CertPathConstraintsParameters cpcp) {
>>> 1490:         try {
>>> 1491:             CERTPATH_DISABLED_CHECK.permits(alg, cpcp, false);
>> 
>> Do we need to check AlgorithmParamters as well? Ex: if `alg` is RSASSA-PSS.
>
> We should, but the problem is that jarsigner needs to individually test each algorithm, so it can properly display which algorithm is restricted. So, I think it will need to parse the RSSASSA params itself, and then call the constraints code to check each algorithm. Let me see if I can code up something that does that.

I would like to defer the checking of AlgorithmParameters as part of another bug. There are some major restructuring changes that would need to be made to jarsigner to support this. And for RSASSA-PSS, there should not be any risk for a while since by default jarsigner uses at least SHA-256 for the digest algorithms in the PSS parameters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6296

From rhillegas at comcast.net  Thu Nov 18 18:07:16 2021
From: rhillegas at comcast.net (Richard Hillegas)
Date: Thu, 18 Nov 2021 10:07:16 -0800
Subject: new hurdle for applications which programatically install a
 SecurityManager
Message-ID: <f65f2908-617e-7e6b-3542-68208e2852fe@comcast.net>

Build 18-ea+23-1525 has introduced another hurdle for applications which 
use the SecurityManager. In order to install a SecurityManager, you now 
have to set -Djava.security.manager=allow on the boot command line. This 
property cannot be set programatically, unlike the other system 
properties related to the SecurityManager. I have attached a simple 
repro of this asymmetry (DERBY_7126_B) to 
https://issues.apache.org/jira/browse/DERBY-7126. The repro 
programatically sets java.security.manager. Here's the code:

import java.io.PrintWriter;
import java.util.Properties;

/**
 ?* Demonstrate that the SecurityManager can be installed by setting
 ?*/
@SuppressWarnings("removal")
public class DERBY_7126_B
{
 ??? private static final String PROPERTY_FILE_NAME = 
"/tmp/derby-7126_B.properties";
 ??? private static final String SECURITY_POLICY_FILE_NAME = 
"/tmp/derby-7126_B.policy";
 ??? private static final String SECURITY_POLICY_FILE_URL = "file:" + 
SECURITY_POLICY_FILE_NAME;

 ??? private final static String POLICY_FILE_PROPERTY = 
"java.security.policy";

 ??? private static final String SECURITY_FILE_CONTENTS =
 ??????? "grant\n" +
 ??????? "{\n" +
 ??????? "? permission java.io.FilePermission \"/tmp/-\", 
\"read,write,delete\";\n" +
 ??????? "};\n"
 ??????? ;

 ??? public static void main(String... args) throws Exception
 ??? {
 ??????? // write the policy file
 ??????? try (PrintWriter pw = new PrintWriter(SECURITY_POLICY_FILE_NAME))
 ??????? { pw.write(SECURITY_FILE_CONTENTS); }

 ??????? // start up a security manager using the policy file we just wrote
 ??????? System.setProperty( POLICY_FILE_PROPERTY, 
SECURITY_POLICY_FILE_URL );
 ??????? System.setProperty( "java.security.manager", "allow" );

 ??????? System.setSecurityManager( new SecurityManager() );
 ??? }

}

Here's the output I get when I run that program against 18-ea+23-1525 
WITHOUT setting java.security.manager on the boot command line:

Exception in thread "main" java.lang.UnsupportedOperationException: The 
Security Manager is deprecated and will be removed in a future release
 ?? ?at java.base/java.lang.System.setSecurityManager(System.java:411)
 ?? ?at DERBY_7126_B.main(DERBY_7126_B.java:34)

Here's the output I get when I run that program against 18-ea+23-1525 
but do set java.security.manager on the boot command line:

WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by DERBY_7126_B 
(file:/Users/rhillegas/src/)
WARNING: Please consider reporting this to the maintainers of DERBY_7126_B
WARNING: System::setSecurityManager will be removed in a future release

Is this asymmetry in the handling of this new system property 
deliberate? If so, what is the motivation for this asymmetry? If not, 
can the new property be made to operate like the other SecurityManager 
properties, that is, can the JDK be amended so that 
java.security.manager can be set programatically?

Thanks,
-Rick


From rick.hillegas at gmail.com  Thu Nov 18 18:22:43 2021
From: rick.hillegas at gmail.com (Rick Hillegas)
Date: Thu, 18 Nov 2021 10:22:43 -0800
Subject: Fwd: new hurdle for applications which programatically install a
 SecurityManager
In-Reply-To: <f65f2908-617e-7e6b-3542-68208e2852fe@comcast.net>
References: <f65f2908-617e-7e6b-3542-68208e2852fe@comcast.net>
Message-ID: <eb7270b9-0f7c-50d4-0d38-7bea77dc4c3d@gmail.com>

Re-sending from the account linked to my security-dev subscription



-------- Forwarded Message --------

Build 18-ea+23-1525 has introduced another hurdle for applications which 
use the SecurityManager. In order to install a SecurityManager, you now 
have to set -Djava.security.manager=allow on the boot command line. This 
property cannot be set programatically, unlike the other system 
properties related to the SecurityManager. I have attached a simple 
repro of this asymmetry (DERBY_7126_B) to 
https://issues.apache.org/jira/browse/DERBY-7126. The repro 
programatically sets java.security.manager. Here's the code:

import java.io.PrintWriter;
import java.util.Properties;

/**
 ?* Demonstrate that the SecurityManager can be installed by setting
 ?*/
@SuppressWarnings("removal")
public class DERBY_7126_B
{
 ??? private static final String PROPERTY_FILE_NAME = 
"/tmp/derby-7126_B.properties";
 ??? private static final String SECURITY_POLICY_FILE_NAME = 
"/tmp/derby-7126_B.policy";
 ??? private static final String SECURITY_POLICY_FILE_URL = "file:" + 
SECURITY_POLICY_FILE_NAME;

 ??? private final static String POLICY_FILE_PROPERTY = 
"java.security.policy";

 ??? private static final String SECURITY_FILE_CONTENTS =
 ??????? "grant\n" +
 ??????? "{\n" +
 ??????? "? permission java.io.FilePermission \"/tmp/-\", 
\"read,write,delete\";\n" +
 ??????? "};\n"
 ??????? ;

 ??? public static void main(String... args) throws Exception
 ??? {
 ??????? // write the policy file
 ??????? try (PrintWriter pw = new PrintWriter(SECURITY_POLICY_FILE_NAME))
 ??????? { pw.write(SECURITY_FILE_CONTENTS); }

 ??????? // start up a security manager using the policy file we just wrote
 ??????? System.setProperty( POLICY_FILE_PROPERTY, 
SECURITY_POLICY_FILE_URL );
 ??????? System.setProperty( "java.security.manager", "allow" );

 ??????? System.setSecurityManager( new SecurityManager() );
 ??? }

}

Here's the output I get when I run that program against 18-ea+23-1525 
WITHOUT setting java.security.manager on the boot command line:

Exception in thread "main" java.lang.UnsupportedOperationException: The 
Security Manager is deprecated and will be removed in a future release
 ?? ?at java.base/java.lang.System.setSecurityManager(System.java:411)
 ?? ?at DERBY_7126_B.main(DERBY_7126_B.java:34)

Here's the output I get when I run that program against 18-ea+23-1525 
but do set java.security.manager on the boot command line:

WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by DERBY_7126_B 
(file:/Users/rhillegas/src/)
WARNING: Please consider reporting this to the maintainers of DERBY_7126_B
WARNING: System::setSecurityManager will be removed in a future release

Is this asymmetry in the handling of this new system property 
deliberate? If so, what is the motivation for this asymmetry? If not, 
can the new property be made to operate like the other SecurityManager 
properties, that is, can the JDK be amended so that 
java.security.manager can be set programatically?

Thanks,
-Rick


From valeriep at openjdk.java.net  Thu Nov 18 18:40:43 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 18 Nov 2021 18:40:43 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <MunG7ACIrKQICX9V9VhbC2UxSMZylDb8XHPXTH41OEM=.e1b34735-cb9f-4899-9147-7645a79540e8@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
 <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>
 <MunG7ACIrKQICX9V9VhbC2UxSMZylDb8XHPXTH41OEM=.e1b34735-cb9f-4899-9147-7645a79540e8@github.com>
Message-ID: <ZZ-b127yn08zB3_Bt_6snyTk1P_TxEoog6nMiaVkhWk=.56324857-7842-46ee-975f-d18fd55e76f6@github.com>

On Wed, 17 Nov 2021 21:25:33 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> 
> 
> > > ```
> > > * By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.
> > > ```
> > 
> > 
> > There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.
> 
> In my view (Webrev.00 based comment), the variable 'n' holding the modulus value is private in P11RSAPrivateKey. This means that when P11PrivateKeyRSA::getModulus is called, P11PrivateKeyRSA::n (which is protected) has a 'null' value and the PKCS#11 lib call is done again.

Hmm, this is a bug and unintended. The 'n' in the child class should be removed as the 'n' in the parent class has scope protected and should be used instead. 
Regards,
Valerie

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From weijun at openjdk.java.net  Thu Nov 18 18:44:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 18 Nov 2021 18:44:44 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled [v2]
In-Reply-To: <e9BN0gJjXMa95F9RrMmGr5ZvEYWDNm2gVGAeq0ziFks=.7cabc485-18f9-4873-be3a-098a17881650@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
 <e9BN0gJjXMa95F9RrMmGr5ZvEYWDNm2gVGAeq0ziFks=.7cabc485-18f9-4873-be3a-098a17881650@github.com>
Message-ID: <QHbBAv908olINymNOJWqQQ_0oG-LIyAZ2prhTqU8frg=.5ea5818d-d2bd-458b-a6c3-c5a794d7fd9e@github.com>

On Tue, 16 Nov 2021 18:10:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> When a signature/digest algorithm was being checked, the algorithm constraints checked both the signature/digest algorithm and the key to see if they were restricted. This caused duplicate checks and was also problematic for `jarsigner` (and `keytool`) which need to distinguish these two cases, so that the output can properly indicate when the key is disabled but the signature or digest alg is ok. 
>> 
>> To address this issue, a new `checkKey` parameter is added to the `DisabledAlgorithmConstraints.permits` methods. When `true` the key (alg and size) is also checked, otherwise it is not. This flag is always set to `false` by `jarsigner` when checking algs and by the JDK when checking digest algorithms. Other small changes include changes in `SignerInfo` to use a record to store info about the algorithms to be checked, and removing an unnecessary CRL checking method from `AlgorithmChecker`.
>> 
>> `keytool` will be enhanced in a subsequent CR to call the new methods.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use var in for loop in SignerInfo.
>   In TimestampCheck test, combine/simplify what messages should not be emitted
>   when jar is signed with 512-bit RSA key.

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6296

From weijun at openjdk.java.net  Thu Nov 18 18:44:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 18 Nov 2021 18:44:45 GMT
Subject: RFR: 8275887: jarsigner prints invalid digest/signature algorithm
 warnings if keysize is weak/disabled [v2]
In-Reply-To: <nZCwWktdD_0W2Zd171MSWxt6MILWcrPMsdtmEyCory4=.25a690dc-840e-4594-a601-1c2140e4dea3@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
 <v1srOR6FK3xmjqx-fd0AYIIq7LeDGSuBERGh6ds7W_I=.bbde808c-9e71-41b4-98eb-826a8afaaad7@github.com>
 <fcyu1eDc3cRnkBG370yE-RYc0bAsPimLBfCIymPynbg=.7d625e8b-0f40-4f91-8397-7b95ad2236ab@github.com>
 <nZCwWktdD_0W2Zd171MSWxt6MILWcrPMsdtmEyCory4=.25a690dc-840e-4594-a601-1c2140e4dea3@github.com>
Message-ID: <40Mshnm6_3tttVogGBNdh3s8HnEG7AZkLBWyJL1PMlg=.0b5c4a0f-7a0b-489d-b885-47d441d5988b@github.com>

On Thu, 18 Nov 2021 15:03:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We should, but the problem is that jarsigner needs to individually test each algorithm, so it can properly display which algorithm is restricted. So, I think it will need to parse the RSSASSA params itself, and then call the constraints code to check each algorithm. Let me see if I can code up something that does that.
>
> I would like to defer the checking of AlgorithmParameters as part of another bug. There are some major restructuring changes that would need to be made to jarsigner to support this. And for RSASSA-PSS, there should not be any risk for a while since by default jarsigner uses at least SHA-256 for the digest algorithms in the PSS parameters.

Looks so.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6296

From sean.mullan at oracle.com  Thu Nov 18 19:21:37 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 18 Nov 2021 14:21:37 -0500
Subject: Fwd: new hurdle for applications which programatically install a
 SecurityManager
In-Reply-To: <eb7270b9-0f7c-50d4-0d38-7bea77dc4c3d@gmail.com>
References: <f65f2908-617e-7e6b-3542-68208e2852fe@comcast.net>
 <eb7270b9-0f7c-50d4-0d38-7bea77dc4c3d@gmail.com>
Message-ID: <c544c446-85f7-f2f3-2e5b-772094f71ef9@oracle.com>



On 11/18/21 1:22 PM, Rick Hillegas wrote:
> Here's the output I get when I run that program against 18-ea+23-1525
> WITHOUT setting java.security.manager on the boot command line:
> 
> Exception in thread "main" java.lang.UnsupportedOperationException: The
> Security Manager is deprecated and will be removed in a future release
>   ?? ?at java.base/java.lang.System.setSecurityManager(System.java:411)
>   ?? ?at DERBY_7126_B.main(DERBY_7126_B.java:34)
> 
> Here's the output I get when I run that program against 18-ea+23-1525
> but do set java.security.manager on the boot command line:
> 
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by DERBY_7126_B
> (file:/Users/rhillegas/src/)
> WARNING: Please consider reporting this to the maintainers of DERBY_7126_B
> WARNING: System::setSecurityManager will be removed in a future release
> 
> Is this asymmetry in the handling of this new system property
> deliberate?

Yes. The system property is read early (and never again) in VM init phase 3.

> If so, what is the motivation for this asymmetry? 

One of the motivations is to improve the performance of applications 
that do not use the Security Manager. These applications ideally should 
not have to incur the cost of supporting a SecurityManager if it is not 
used. By reading the system property early, the code for loading and 
checking the security field can be removed. More details are in the CSR 
for this change that initially went into JDK 12: 
https://bugs.openjdk.java.net/browse/JDK-8203316

> If not,
> can the new property be made to operate like the other SecurityManager
> properties, that is, can the JDK be amended so that
> java.security.manager can be set programatically?

AFAIK, the "java.security.manager" system property has always been read 
early before the main application is launched. Also, a change like that 
would negate the performance benefits described above.

--Sean


From rriggs at openjdk.java.net  Thu Nov 18 19:25:42 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 18 Nov 2021 19:25:42 GMT
Subject: RFR: 8274333: Redundant null comparison after Pattern.split
In-Reply-To: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
References: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
Message-ID: <0MHJIGzVRAUDK7hNcZc3nWifHd_9L7ib-t9GMUJuxVs=.09f96e20-1565-4ae0-83b2-2b18623bbe16@github.com>

On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5708

From mbalao at openjdk.java.net  Thu Nov 18 19:30:50 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Thu, 18 Nov 2021 19:30:50 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <ZZ-b127yn08zB3_Bt_6snyTk1P_TxEoog6nMiaVkhWk=.56324857-7842-46ee-975f-d18fd55e76f6@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
 <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>
 <MunG7ACIrKQICX9V9VhbC2UxSMZylDb8XHPXTH41OEM=.e1b34735-cb9f-4899-9147-7645a79540e8@github.com>
 <ZZ-b127yn08zB3_Bt_6snyTk1P_TxEoog6nMiaVkhWk=.56324857-7842-46ee-975f-d18fd55e76f6@github.com>
Message-ID: <juEag3BvVykVEgTTIOdop8eDhxaWvXBXIkDgHKrUs4M=.e63b7c64-d17a-4241-8241-cab64c0b7573@github.com>

On Thu, 18 Nov 2021 18:37:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>>> > ```
>>> > * By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.
>>> > ```
>>> 
>>> There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.
>>> 
>> 
>> In my view (Webrev.00 based comment), the variable 'n' holding the modulus value is private in P11RSAPrivateKey. This means that when P11PrivateKeyRSA::getModulus is called, P11PrivateKeyRSA::n (which is protected) has a 'null' value and the PKCS#11 lib call is done again.
>
>> 
>> 
>> > > ```
>> > > * By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.
>> > > ```
>> > 
>> > 
>> > There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.
>> 
>> In my view (Webrev.00 based comment), the variable 'n' holding the modulus value is private in P11RSAPrivateKey. This means that when P11PrivateKeyRSA::getModulus is called, P11PrivateKeyRSA::n (which is protected) has a 'null' value and the PKCS#11 lib call is done again.
> 
> Hmm, this is a bug and unintended. The 'n' in the child class should be removed as the 'n' in the parent class has scope protected and should be used instead. 
> 
> I checked webrev.01 and this has been caught and fixed already. Good to have a different pair of eyes and more likely to spot problems. Thanks!
> 
> Regards,
> Valerie

Hi @valeriepeng ,

Some comments and questions regarding Webrev.01:

 * P11Key.java

  * Would you consider replacing the 'Internal' suffix with 'Opaque'? I believe the term 'opaque' better reflects what these keys are: you cannot see their values -thus, opaque- but you can use them as-is. 'Internal' gives me the impression of something not supposed to be exposed; and this is not exactly the case.

  * Why are P11RSAPrivateKeyInternal::n, P11RSAPrivateKey::<e, d, p, q, pe, qe, coeff>, etc. now transient?

  * Now that P11RSAPrivateKey::n private field was removed, the extra PKCS#11 lib call I mentioned in Webrev.00 is not possible anymore. The override of ::getModulus looks good to me, though, for the reasons you said.

  * Can P11RSAPrivateNonCRTKey use the protected 'n' field from its parent instead of declaring a private one?

 * P11Signature.java

  * 'long errorCode = e.getErrorCode();' -> Looks to me that this change was included into the Webrev by mistake, and is part of JDK-8236512.

Thanks,
Martin.-

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From iris at openjdk.java.net  Thu Nov 18 20:20:43 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 18 Nov 2021 20:20:43 GMT
Subject: RFR: 8274333: Redundant null comparison after Pattern.split
In-Reply-To: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
References: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
Message-ID: <PDl6zvPoFY_B7osv9cBVtvAZn3scO_Va4PLCmUviJ24=.287f9314-6e09-4a3b-ad97-40fbf987f47e@github.com>

On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5708

From rick.hillegas at gmail.com  Thu Nov 18 21:44:33 2021
From: rick.hillegas at gmail.com (Rick Hillegas)
Date: Thu, 18 Nov 2021 13:44:33 -0800
Subject: Fwd: new hurdle for applications which programatically install a
 SecurityManager
In-Reply-To: <c544c446-85f7-f2f3-2e5b-772094f71ef9@oracle.com>
References: <f65f2908-617e-7e6b-3542-68208e2852fe@comcast.net>
 <eb7270b9-0f7c-50d4-0d38-7bea77dc4c3d@gmail.com>
 <c544c446-85f7-f2f3-2e5b-772094f71ef9@oracle.com>
Message-ID: <46c1106d-2a6c-6039-cb4f-2de3be5c32ac@gmail.com>

Thanks for the quick response and for the pointer to 
https://bugs.openjdk.java.net/browse/JDK-8203316

The change in the default value of java.security.manager prevents Derby 
from installing a SecurityManager when the user forgets to. This 
increases Derby's attack surface, significantly in my opinion.

On 11/18/21 11:21 AM, Sean Mullan wrote:
>
>
> On 11/18/21 1:22 PM, Rick Hillegas wrote:
>> Here's the output I get when I run that program against 18-ea+23-1525
>> WITHOUT setting java.security.manager on the boot command line:
>>
>> Exception in thread "main" java.lang.UnsupportedOperationException: The
>> Security Manager is deprecated and will be removed in a future release
>> ? ?? ?at java.base/java.lang.System.setSecurityManager(System.java:411)
>> ? ?? ?at DERBY_7126_B.main(DERBY_7126_B.java:34)
>>
>> Here's the output I get when I run that program against 18-ea+23-1525
>> but do set java.security.manager on the boot command line:
>>
>> WARNING: A terminally deprecated method in java.lang.System has been 
>> called
>> WARNING: System::setSecurityManager has been called by DERBY_7126_B
>> (file:/Users/rhillegas/src/)
>> WARNING: Please consider reporting this to the maintainers of 
>> DERBY_7126_B
>> WARNING: System::setSecurityManager will be removed in a future release
>>
>> Is this asymmetry in the handling of this new system property
>> deliberate?
>
> Yes. The system property is read early (and never again) in VM init 
> phase 3.
>
>> If so, what is the motivation for this asymmetry? 
>
> One of the motivations is to improve the performance of applications 
> that do not use the Security Manager. These applications ideally 
> should not have to incur the cost of supporting a SecurityManager if 
> it is not used. By reading the system property early, the code for 
> loading and checking the security field can be removed. More details 
> are in the CSR for this change that initially went into JDK 12: 
> https://bugs.openjdk.java.net/browse/JDK-8203316
>
>> If not,
>> can the new property be made to operate like the other SecurityManager
>> properties, that is, can the JDK be amended so that
>> java.security.manager can be set programatically?
>
> AFAIK, the "java.security.manager" system property has always been 
> read early before the main application is launched. Also, a change 
> like that would negate the performance benefits described above.
>
> --Sean
>


From bchristi at openjdk.java.net  Thu Nov 18 22:55:02 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 18 Nov 2021 22:55:02 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal
Message-ID: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>

Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.

This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.

The CSR has been approved.
An automated test build+test run passes cleanly (FWIW :D ).

-------------

Commit messages:
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - Fix @since on @Deprecated for java.lang.Enum
 - Clarify conditions for removal of Object.finalize method
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276447
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

PR: https://git.openjdk.java.net/jdk/pull/6465

From valeriep at openjdk.java.net  Fri Nov 19 00:23:43 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 19 Nov 2021 00:23:43 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <juEag3BvVykVEgTTIOdop8eDhxaWvXBXIkDgHKrUs4M=.e63b7c64-d17a-4241-8241-cab64c0b7573@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
 <fmpcDwY_h0bNqlEXFWDiw1yVRRdEawceb_pLWHdax64=.020f7bb7-811d-4fd8-a921-43acd9d6e637@github.com>
 <MunG7ACIrKQICX9V9VhbC2UxSMZylDb8XHPXTH41OEM=.e1b34735-cb9f-4899-9147-7645a79540e8@github.com>
 <ZZ-b127yn08zB3_Bt_6snyTk1P_TxEoog6nMiaVkhWk=.56324857-7842-46ee-975f-d18fd55e76f6@github.com>
 <juEag3BvVykVEgTTIOdop8eDhxaWvXBXIkDgHKrUs4M=.e63b7c64-d17a-4241-8241-cab64c0b7573@github.com>
Message-ID: <mrXZHQnofKh0SrhEjdLuPY7BuZfcuyTajiML02Nw23Y=.e1827edb-290d-4556-90d4-973e51f5717c@github.com>

On Thu, 18 Nov 2021 19:27:30 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> 
> 
> Hi @valeriepeng ,
> 
> Some comments and questions regarding Webrev.01:
> 
>     * P11Key.java
> 
>     * Would you consider replacing the 'Internal' suffix with 'Opaque'? I believe the term 'opaque' better reflects what these keys are: you cannot see their values -thus, opaque- but you can use them as-is. 'Internal' gives me the impression of something not supposed to be exposed; and this is not exactly the case.
> 
>     * Why are P11RSAPrivateKeyInternal::n, P11RSAPrivateKey::<e, d, p, q, pe, qe, coeff>, etc. now transient?
> 
>     * Now that P11RSAPrivateKey::n private field was removed, the extra PKCS#11 lib call I mentioned in Webrev.00 is not possible anymore. The override of ::getModulus looks good to me, though, for the reasons you said.
> 
>     * Can P11RSAPrivateNonCRTKey use the protected 'n' field from its parent instead of declaring a private one?
> 
>     * P11Signature.java
> 
>     * 'long errorCode = e.getErrorCode();' -> Looks to me that this change was included into the Webrev by mistake, and is part of JDK-8236512.
> 
> 
> Thanks, Martin.-

Either internal or opaque suffix works for me.  Fields aren't really being written out into the serialized bytes are "transient". IIRC, the serialized bytes are the "encoding" instead of the fields, we should mark these fields transient. As for the P11RSAPrivateNonCRTKey, yes, it should use the 'n' from parent instead of its own. I missed it when working on webrev.01. As for 'long errorCode = e.getErrorCode();' in P11Signature.java, yes, it should have been removed. I was manually merging the changes when refreshing the source tree and missed to remove this line.

Thanks,
Valerie

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From mullan at openjdk.java.net  Fri Nov 19 14:40:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 19 Nov 2021 14:40:48 GMT
Subject: Integrated: 8275887: jarsigner prints invalid digest/signature
 algorithm warnings if keysize is weak/disabled
In-Reply-To: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
References: <5YWrP3r93NuEd6Vvb333OxsorwaYGxyoNXE2k9R8M4g=.5596ec6c-9355-4a6a-82c8-bd419b443196@github.com>
Message-ID: <jUYCDieCSoSVHJcJshHWjdLGjjLWUJS1wwf85Px3dPQ=.04ad5e07-fc76-4c1b-93a4-b4275dc15c40@github.com>

On Mon, 8 Nov 2021 14:04:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> When a signature/digest algorithm was being checked, the algorithm constraints checked both the signature/digest algorithm and the key to see if they were restricted. This caused duplicate checks and was also problematic for `jarsigner` (and `keytool`) which need to distinguish these two cases, so that the output can properly indicate when the key is disabled but the signature or digest alg is ok. 
> 
> To address this issue, a new `checkKey` parameter is added to the `DisabledAlgorithmConstraints.permits` methods. When `true` the key (alg and size) is also checked, otherwise it is not. This flag is always set to `false` by `jarsigner` when checking algs and by the JDK when checking digest algorithms. Other small changes include changes in `SignerInfo` to use a record to store info about the algorithms to be checked, and removing an unnecessary CRL checking method from `AlgorithmChecker`.
> 
> `keytool` will be enhanced in a subsequent CR to call the new methods.

This pull request has now been integrated.

Changeset: 03f8c0fb
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03f8c0fb9363dc1bb07bed1ae0359c029caa0130
Stats:     121 lines in 9 files changed: 32 ins; 31 del; 58 mod

8275887: jarsigner prints invalid digest/signature algorithm warnings if keysize is weak/disabled

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/6296

From rriggs at openjdk.java.net  Fri Nov 19 17:31:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 19 Nov 2021 17:31:47 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <g-OOLS12CnVzpJmzzDjU72acZU5_sb508fBLcLxhzoA=.4d7503a8-c2d2-4dd1-b92e-2c0b1a5a10a2@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6465

From alanb at openjdk.java.net  Fri Nov 19 17:31:53 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Nov 2021 17:31:53 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <s5uZ42EuMGyW0S1nktOZSh1I5BUeC-lGUK4-VLTAZbw=.151b63d2-7598-47a7-a3e1-a0d9d0617aa9@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6465

From lancea at openjdk.java.net  Fri Nov 19 17:47:57 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 17:47:57 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <rk3xCjJlKgbIZt3rUi_crNZx2qjbpzB_ylVbpFjrR58=.71b45eb7-a79f-48d7-bd1b-cf541ba99268@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From mchung at openjdk.java.net  Fri Nov 19 18:10:09 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 18:10:09 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

src/java.base/share/classes/java/lang/Object.java line 481:

> 479:      * system resources or to perform other cleanup.
> 480:      * <p>
> 481:      * <b>When running in a Java virtual machine in which finalization has been

Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From darcy at openjdk.java.net  Fri Nov 19 18:10:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 19 Nov 2021 18:10:08 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <H67a1T-dtaGUqeKSvlrfRWlTL64nxFUSN6jKOg0gmC4=.15c0752b-dae1-4e6a-8109-1f8478628d8f@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From bchristi at openjdk.java.net  Fri Nov 19 18:19:10 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 19 Nov 2021 18:19:10 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
Message-ID: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>

On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> src/java.base/share/classes/java/lang/Object.java line 481:
> 
>> 479:      * system resources or to perform other cleanup.
>> 480:      * <p>
>> 481:      * <b>When running in a Java virtual machine in which finalization has been
> 
> Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.

The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal.  That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From duke at openjdk.java.net  Fri Nov 19 18:51:17 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 19 Nov 2021 18:51:17 GMT
Subject: Integrated: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <_JpRagrNxERC0uIpZ8Vj3F9xZ1StAeNX4oYWmWHI080=.931977e5-28f3-4466-b59c-076af0db650d@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

This pull request has now been integrated.

Changeset: 66775543
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6677554374ade32c9f2ddaaa093064de8aebd831
Stats:     38 lines in 17 files changed: 0 ins; 3 del; 35 mod

8274949: Use String.contains() instead of String.indexOf() in java.base

Reviewed-by: weijun, dfuchs, vtewari, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/5559

From duke at openjdk.java.net  Fri Nov 19 18:52:16 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 19 Nov 2021 18:52:16 GMT
Subject: Integrated: 8274333: Redundant null comparison after Pattern.split
In-Reply-To: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
References: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
Message-ID: <Ksw_ENgOKWkJ4DskJJnDxfrf17kPwa9VcPB4-oPtHQ0=.9b363fba-b07d-467c-91fa-0d3583a89e3c@github.com>

On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant.

This pull request has now been integrated.

Changeset: 36b59f38
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36b59f3814fdaa44c9c04a0e8d63d0ba56929326
Stats:     14 lines in 2 files changed: 4 ins; 5 del; 5 mod

8274333: Redundant null comparison after Pattern.split

Reviewed-by: mullan, weijun, rriggs, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/5708

From mchung at openjdk.java.net  Fri Nov 19 19:10:11 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 19:10:11 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <XQEqvCRazxICMGG28AwzLqjpFVc_le_-jemEcxzWWAA=.db4ee046-4961-4c30-8f23-f2ee57cd2ecc@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From mchung at openjdk.java.net  Fri Nov 19 19:10:12 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 19:10:12 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
 <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>
Message-ID: <YfMEhBgRnkNrn9LpnheH8NJNWnS5A7HEnbt_n0046jc=.9c0ccb5a-57a4-4e0e-a237-aac01051d0b3@github.com>

On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Object.java line 481:
>> 
>>> 479:      * system resources or to perform other cleanup.
>>> 480:      * <p>
>>> 481:      * <b>When running in a Java virtual machine in which finalization has been
>> 
>> Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.
>
> The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal.  That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS.

Thanks for pointing out that the CSR for JDK-8276422 ("Add command-line option to disable finalization") includes the change of the SE Platform Spec and JLS to allow an implementation for finalization to be disabled.   This makes senses now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From valeriep at openjdk.java.net  Fri Nov 19 19:54:10 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 19 Nov 2021 19:54:10 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
Message-ID: <8vTXZjaSwUZ3IoHJcfC2cllpmm75dey2vtvVenwo1I4=.8e9ed87b-36de-42c6-b70b-554ba2db23ab@github.com>

On Fri, 13 Aug 2021 17:11:45 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4.
>> 
>> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed.
>> 
>> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey.
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   P11Key static inner classes refactorings.

Hmm, thinking more about "internal"/"opaque", given this is naming for the parent, maybe "internal" is more correct. The non-sensitive keys are encapsulated by the children classes and is still an instance of the parent. If you name the parent class w/ "opaque" suffix, it looks misleading/confusing. The opaqueness is implied by the implementation instead of the properties of the objects.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From serb at openjdk.java.net  Fri Nov 19 20:16:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 20:16:12 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <ukGuoG0O2Jh8RpaJ-WYcNiWFpAqRXZdiuwKR6w9v9VQ=.07b447cd-6c91-4b5f-86d9-c0be213bb0b7@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From mcimadamore at openjdk.java.net  Mon Nov 22 12:02:47 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 22 Nov 2021 12:02:47 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v25]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <RLI2K0IF8MYBNWQuFvTJzdmyxNpzQScJbD0vyCrOwVI=.9a55346f-44d3-4ed5-83d8-66243b910576@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix javadoc issues found in CSR review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/79d3d685..1817975f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=23-24

  Stats: 10 lines in 4 files changed: 2 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From mcimadamore at openjdk.java.net  Mon Nov 22 12:09:30 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 22 Nov 2021 12:09:30 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v26]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <Ck-IxUi_PmVxuycKrHWlXSgRy7B3L-XEf23m1Lief8U=.8320f211-3752-4ae8-beab-58b180870790@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Merge branch 'master' into JEP-419
 - Fix javadoc issues found in CSR review
 - Adopt blessed modofier order
 - Merge branch 'master' into JEP-419
 - Revert removal of upcall MH customization
   (This change caused spurious VM crashes, so reverting to baseline)
 - Further tweak upcall safety considerations
 - Clarify safety considerations for upcalls
 - Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress
   (which is consistent with other restricted factories in VaList and NativeSymbol)
 - Streamline javadoc for package-info
 - * Add two new CLinker static methods to compute upcall/downcall method types
   * Clarify section on CLinker downcall type
   * Add section on CLinker safety guarantees
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/d427c79d...29cc6c60

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5907/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=25
  Stats: 14700 lines in 193 files changed: 6958 ins; 5126 del; 2616 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907

From mstjohns at comcast.net  Mon Nov 22 15:47:21 2021
From: mstjohns at comcast.net (Mike StJohns)
Date: Mon, 22 Nov 2021 10:47:21 -0500
Subject: Integrated: 8277246: Check for NonRepudiation as well when
 validating a TSA certificate
In-Reply-To: <SZZaL1C-FuaFlw5IpopitArn6PskIQUVFt-c3QB-j0Y=.316fa400-dcb5-423d-a6d9-e805fb0ddf6d@github.com>
References: <SZZaL1C-FuaFlw5IpopitArn6PskIQUVFt-c3QB-j0Y=.316fa400-dcb5-423d-a6d9-e805fb0ddf6d@github.com>
Message-ID: <C9F17C76-295B-43D3-96A4-B061F49EDD75@comcast.net>

You?ll be amused to find out that the code that generated the Rekor TS cert has been changed to use digitalSignature as its KU. https://github.com/sigstore/rekor/pull/504/files

I think the change you made is correct, but you probably won?t see a nonRepudiation bit for a while again.  Mike

Sent from my iPad

> On Nov 17, 2021, at 15:09, Weijun Wang <weijun at openjdk.java.net> wrote:
> 
> ?On Tue, 16 Nov 2021 19:36:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:
> 
>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
> 
> This pull request has now been integrated.
> 
> Changeset: 262d0700
> Author:    Weijun Wang <weijun at openjdk.org>
> URL:       https://git.openjdk.java.net/jdk/commit/262d07001babcbe7f9acd2053aa3b7bac304cf85
> Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod
> 
> 8277246: Check for NonRepudiation as well when validating a TSA certificate
> 
> Reviewed-by: xuelei, mullan
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6416
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211122/61dc5362/attachment.htm>

From weijun at openjdk.java.net  Mon Nov 22 19:06:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Nov 2021 19:06:37 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
Message-ID: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>

The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.

There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.

-------------

Commit messages:
 - TGT needs not to be forwardable in S4U2self request
 - address martin's comments
 - Merge
 - also a security property
 - a system property, do not care where ticket is from, more renames
 - move KDCReq::encoding to KrbKdcReq::obuf, no more ibuf in KrbTgsReq
 - a type label for credentials, encoding in KrbKdcReq, and some renames
 - implement the change
 - 8272162: S4U2Self ticket without forwardable flag

Changes: https://git.openjdk.java.net/jdk/pull/6082/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6082&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272162
  Stats: 413 lines in 17 files changed: 218 ins; 38 del; 157 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6082/head:pull/6082

PR: https://git.openjdk.java.net/jdk/pull/6082

From mbalao at openjdk.java.net  Mon Nov 22 19:06:38 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Mon, 22 Nov 2021 19:06:38 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
Message-ID: <n2iA4i90HVy8jfK2xFGFw6LjivB7JKGA2GjMtdC13Rs=.4215497d-698e-4753-b180-2329e051e99b@github.com>

On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
> 
> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.

Hi Max,

Thanks for making this contribution.

I see the problem that we are addressing here, and the trade-off between the proposed approach and the complexity of locating a DS_BEHAVIOR_WIN2012 DC. I'm okay overall with the decision made.

A few minor comments or suggestions:

 * The names 'second' and 'secondTicket' -that were used before- don't look ideal to me. I've not seen them used neither in RFC 4120 nor in MS-SFU (v.20.0). In the case of 'additionalTickets', it's defined in RFC 4120 but more from a message-format perspective than with any specific semantics. Many of us are familiar to these names at this point but perhaps we can take this opportunity to find a better replacement. These are service tickets used for impersonation, from a user principal probably. I used 'userSvcTicket' when working on the Referrals feature. It could be that or something different. I'm okay if you want to postpone this consideration, but I wanted to raise it just in case.

 * While I see the need of introducing a new class to the hierarchy (KrbKdcReq), I'd rearrange that a bit if possible. In particular, I'd make ::getMessage part of the interface, instead of ::encoding, and then delegate to the message (KDCReq --> ASReq | TGSReq) the encoding. In fact, the message already does the encoding; it's just caching it in the same place where it's done -which should be fine as the message is non-mutable-. This would simplify things a bit and we can have only one 'obuf' field in KDCReq, instead of caching it both in KrbAsReq and KrbTgsReq. We are not loosing encapsulation because the message is already accessible. What do you think?

 * In CredentialsUtil.java, I see how the checks 'additionalTickets == null || additionalTickets.length == 0' were replaced by 'second == null', but what about the check 'credsInOut[1] == null'?

 * I want to notice that 'additionalTickets' was technically an 'in/out' parameter in CredentialsUtil::serviceCredsReferrals. I couldn't find any consequence of making it an 'in' parameter, but just in case I want to mention this. I believe the only function that could have used that information is CredentialsUtil::acquireS4U2proxyCreds but it's an r-value there so it should be fine.

 * A KDC_ERR_BADOPTION error meaning that the KDC requires the 'FORWARDABLE' option in the ticket is what the code suggests. Is it possible that this is not what really happened and there is something else wrong? In other words, is it possible that a DS_BEHAVIOR_WIN2012 DC returns this error?

 * The FORWARDABLE check removed is the one in S4U2Self. Apparently, for S4U2Proxy with non-S4U2Self second-tickets there were no checks. Now we check at S4U2Proxy level (for all 'second' tickets, S4U2Self and non-S4U2Self ones). Is that okay? Or do we need to be more specific and check for S4U2Self second-tickets only (in a S4U2Proxy communication)?

Otherwise, looks good to me.

Thanks,
Martin.-

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From mbalao at openjdk.java.net  Mon Nov 22 19:06:40 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Mon, 22 Nov 2021 19:06:40 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <dCrOuBelH3OE-7dUlIFsc0nllHRKiIrH_AjA41e31C8=.3a8a3941-3ffa-47d6-b25f-9af9c79e3c27@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <n2iA4i90HVy8jfK2xFGFw6LjivB7JKGA2GjMtdC13Rs=.4215497d-698e-4753-b180-2329e051e99b@github.com>
 <dCrOuBelH3OE-7dUlIFsc0nllHRKiIrH_AjA41e31C8=.3a8a3941-3ffa-47d6-b25f-9af9c79e3c27@github.com>
Message-ID: <FC2bZuE8MWw9rpKCa1TjABgEUrFWBorfBMmAmn6aHbo=.244003de-a964-4c67-90ff-91af8b9ee186@github.com>

On Thu, 28 Oct 2021 21:49:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 
> > * The FORWARDABLE check removed is the one in S4U2Self. Apparently, for S4U2Proxy with non-S4U2Self second-tickets there were no checks. Now we check at S4U2Proxy level (for all 'second' tickets, S4U2Self and non-S4U2Self ones). Is that okay? Or do we need to be more specific and check for S4U2Self second-tickets only (in a S4U2Proxy communication)?
> 
> That's what I asked you about a more precise way to ensure a cred is a S4U2self one. I thought about stuff the `S4U2Type` value as a "type" field into the credentials returned by `serviceCreds()` but it looks a little ugly.
> 

This would be tricky. The problem is that the 'cname' and 'crealm' in the S4U2Self ticket are the user's ones; so indistinguishable from the non-S4U2Self. The 'sname' and 'srealm' are also equal: the middle service principal. I'm not sure if there are any differences in the PAC. Even when it's a bit 'ugly', storing the 'type' looks like a reliable scheme in my opinion. But the question that concerns me most is if we really want to make such a tight check, or we are willing to forward everything. I'd suggest to keep your proposal as it is now in this regard. Meanwhile, I'll check what the MIT client does and let you know if there is anything that we to consider.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From mbalao at openjdk.java.net  Mon Nov 22 19:06:41 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Mon, 22 Nov 2021 19:06:41 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <FC2bZuE8MWw9rpKCa1TjABgEUrFWBorfBMmAmn6aHbo=.244003de-a964-4c67-90ff-91af8b9ee186@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <n2iA4i90HVy8jfK2xFGFw6LjivB7JKGA2GjMtdC13Rs=.4215497d-698e-4753-b180-2329e051e99b@github.com>
 <dCrOuBelH3OE-7dUlIFsc0nllHRKiIrH_AjA41e31C8=.3a8a3941-3ffa-47d6-b25f-9af9c79e3c27@github.com>
 <FC2bZuE8MWw9rpKCa1TjABgEUrFWBorfBMmAmn6aHbo=.244003de-a964-4c67-90ff-91af8b9ee186@github.com>
Message-ID: <5RAIx3dj-R2UMv-w2NJtArPGkUg5pvwsFTfyFxnweZ4=.d3707bfe-63a0-4f87-a7dc-24d916c9f2eb@github.com>

On Mon, 1 Nov 2021 14:42:32 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>>> * The names 'second' and 'secondTicket' -that were used before- don't look ideal to me. I've not seen them used neither in RFC 4120 nor in MS-SFU (v.20.0). In the case of 'additionalTickets', it's defined in RFC 4120 but more from a message-format perspective than with any specific semantics. Many of us are familiar to these names at this point but perhaps we can take this opportunity to find a better replacement. These are service tickets used for impersonation, from a user principal probably. I used 'userSvcTicket' when working on the Referrals feature. It could be that or something different. I'm okay if you want to postpone this consideration, but I wanted to raise it just in case.
>> 
>> I see what you mean. I'll go through them.
>> 
>>> * While I see the need of introducing a new class to the hierarchy (KrbKdcReq), I'd rearrange that a bit if possible. In particular, I'd make ::getMessage part of the interface, instead of ::encoding, and then delegate to the message (KDCReq --> ASReq | TGSReq) the encoding. In fact, the message already does the encoding; it's just caching it in the same place where it's done -which should be fine as the message is non-mutable-. This would simplify things a bit and we can have only one 'obuf' field in KDCReq, instead of caching it both in KrbAsReq and KrbTgsReq. We are not loosing encapsulation because the message is already accessible. What do you think?
>> 
>> Good idea.
>> 
>>> * In CredentialsUtil.java, I see how the checks 'additionalTickets == null || additionalTickets.length == 0' were replaced by 'second == null', but what about the check 'credsInOut[1] == null'?
>> 
>> Sorry, missed it.
>> 
>>> * I want to notice that 'additionalTickets' was technically an 'in/out' parameter in CredentialsUtil::serviceCredsReferrals. I couldn't find any consequence of making it an 'in' parameter, but just in case I want to mention this. I believe the only function that could have used that information is CredentialsUtil::acquireS4U2proxyCreds but it's an r-value there so it should be fine.
>> 
>> That's right. Although the content of the original array argument could be modified, the caller has not used it. In fact, changing it from array to a normal object makes me feel relieved. I always needed to remind myself that this was not meant to be an '[out]' parameter.
>> 
>>> * A KDC_ERR_BADOPTION error meaning that the KDC requires the 'FORWARDABLE' option in the ticket is what the code suggests. Is it possible that this is not what really happened and there is something else wrong? In other words, is it possible that a DS_BEHAVIOR_WIN2012 DC returns this error?
>> 
>> I don't know.
>> 
>>> * The FORWARDABLE check removed is the one in S4U2Self. Apparently, for S4U2Proxy with non-S4U2Self second-tickets there were no checks. Now we check at S4U2Proxy level (for all 'second' tickets, S4U2Self and non-S4U2Self ones). Is that okay? Or do we need to be more specific and check for S4U2Self second-tickets only (in a S4U2Proxy communication)?
>> 
>> That's what I asked you about a more precise way to ensure a cred is a S4U2self one. I thought about stuff the `S4U2Type` value as a "type" field into the credentials returned by `serviceCreds()` but it looks a little ugly.
>> 
>>> 
>>> Otherwise, looks good to me.
>> 
>> Thanks.
>> 
>>> 
>>> Thanks, Martin.-
>
>> 
>> > * The FORWARDABLE check removed is the one in S4U2Self. Apparently, for S4U2Proxy with non-S4U2Self second-tickets there were no checks. Now we check at S4U2Proxy level (for all 'second' tickets, S4U2Self and non-S4U2Self ones). Is that okay? Or do we need to be more specific and check for S4U2Self second-tickets only (in a S4U2Proxy communication)?
>> 
>> That's what I asked you about a more precise way to ensure a cred is a S4U2self one. I thought about stuff the `S4U2Type` value as a "type" field into the credentials returned by `serviceCreds()` but it looks a little ugly.
>> 
> 
> This would be tricky. The problem is that the 'cname' and 'crealm' in the S4U2Self ticket are the user's ones; so indistinguishable from the non-S4U2Self. The 'sname' and 'srealm' are also equal: the middle service principal. I'm not sure if there are any differences in the PAC. Even when it's a bit 'ugly', storing the 'type' looks like a reliable scheme in my opinion. But the question that concerns me most is if we really want to make such a tight check, or we are willing to forward everything. I'd suggest to keep your proposal as it is now in this regard. Meanwhile, I'll check what the MIT client does and let you know if there is anything that we to consider.

> Hi @martinuy, I looked at the variable names. Some can be named `clientCreds` or `proxyCreds`. Some are for a general `additionalTickets`. I can name it to `additionalCreds` but this "creds" is only one object and not an array.

`additionalTickets` is a term introduced in the RFC. Even when it does not have defined semantics (i.e.: what are these attached/additional tickets for?), I'd keep it for everything related to message formatting. My comment was more about 'second', which is undefined in RFC/docs and not a very meaningful name. I prefer `clientCreds` over `proxyCreds` because 'proxy' makes me think about the middle-service. What about `userCreds`? (the reason I like 'user' is because it's more about the actor, while client might be a role that the middle-service is playing in a communication with a KDC or a back-end)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From weijun at openjdk.java.net  Mon Nov 22 19:06:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Nov 2021 19:06:42 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <FC2bZuE8MWw9rpKCa1TjABgEUrFWBorfBMmAmn6aHbo=.244003de-a964-4c67-90ff-91af8b9ee186@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <n2iA4i90HVy8jfK2xFGFw6LjivB7JKGA2GjMtdC13Rs=.4215497d-698e-4753-b180-2329e051e99b@github.com>
 <dCrOuBelH3OE-7dUlIFsc0nllHRKiIrH_AjA41e31C8=.3a8a3941-3ffa-47d6-b25f-9af9c79e3c27@github.com>
 <FC2bZuE8MWw9rpKCa1TjABgEUrFWBorfBMmAmn6aHbo=.244003de-a964-4c67-90ff-91af8b9ee186@github.com>
Message-ID: <4AsTT_fCQuPKaEhweJN1QHIHswJ1bY_4DPem0KCGWpU=.1076e325-7b48-4005-a551-724dad1faf24@github.com>

On Mon, 1 Nov 2021 14:42:32 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> But the question that concerns me most is if we really want to make such a tight check, or we are willing to forward everything.

Alexey said their customer has at least 50 KDCs. It will be quite a waste of time if we go through each of them and get a KDC_ERR_BADOPTION all the time. Therefore I would like this retry to be as restricted as possible.

> `additionalTickets` is a term introduced in the RFC. Even when it does not have defined semantics (i.e.: what are these attached/additional tickets for?), I'd keep it for everything related to message formatting. My comment was more about 'second', which is undefined in RFC/docs and not a very meaningful name. I prefer `clientCreds` over `proxyCreds` because 'proxy' makes me think about the middle-service. What about `userCreds`? (the reason I like 'user' is because it's more about the actor, while client might be a role that the middle-service is playing in a communication with a KDC or a back-end)

Unfortunately we cannot call them `additionalTickets` anymore, first it's no longer just a message, second it's not plural. Yes, `userCreds` is better. One place `proxyCreds` is used is because it's a `Krb5ProxyCredential`. As for `second`, I think it might be from the "second ticket" inside a ccache.

I've pushed a new commit for everything I've tried on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From weijun at openjdk.java.net  Mon Nov 22 19:06:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Nov 2021 19:06:43 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
Message-ID: <PNzwOr7muHMLrE34aDU2T_AX0Ma-6LbeQP4B2ybKeg8=.1df90025-28fc-45a6-a44c-e81694612f89@github.com>

On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
> 
> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.

Oops, I introduced a bug. At the end of the constructor of `KrbTgsReq`, `options` could be changed. Since I'm now calculating the encoding on-demand, the encoding will also change. I'll fix this in another commit.

First, my latest commit contains a mechanism to tell if a ticket is from S4U2self. Is it significant enough to change your mind?

Even if there is a system property for this purpose (suppose it's named `jdk.security.krb5.accept.non.forwardble.s4u2self.response.and.retry`), I wonder if it's worth turning it off. As you said, a  legitimate S4U2self should always be FORWARDABLE, and in this case the system property is useless. But, if a service really receives such a ticket, I assume it would prefer to try it in a S4U2proxy request instead of just failing early. After all, when it impersonates someone, its purpose should be accessing a backend service.

We usually introduce a system property for a compatibility reason so that existing normal cases will not behave differently, but here, we are simply trying to resurrect a former failure.

The main problem I see with the current approach is still about whether a "tolerant" KDC can be accessed in time. If this can be optimized by adjusting the orders of KDC either in krb5.conf or in the DNS response, then I would be greatly relieved.

That `ccreds` in `acquireS4U2selfCreds`? I'll fix it.

Other comments accepted. I'll add a system property.

All suggestions accepted, except that I still write out the full name for S4U2proxy in `java.security`.

For the `KrbKdcReq` method name. It's now `encoding` because it's returning a byte array. `getMessage` was used to return a message type.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From mbalao at openjdk.java.net  Mon Nov 22 19:06:43 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Mon, 22 Nov 2021 19:06:43 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <PNzwOr7muHMLrE34aDU2T_AX0Ma-6LbeQP4B2ybKeg8=.1df90025-28fc-45a6-a44c-e81694612f89@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <PNzwOr7muHMLrE34aDU2T_AX0Ma-6LbeQP4B2ybKeg8=.1df90025-28fc-45a6-a44c-e81694612f89@github.com>
Message-ID: <mYjBnL-wAPNyWGl3HMjTpQ3WbdrfvnGmLAzfe6Jeww8=.90216848-1296-494c-93cb-58dabe631be3@github.com>

On Mon, 1 Nov 2021 17:24:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
>> 
>> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.
>
> Oops, I introduced a bug. At the end of the constructor of `KrbTgsReq`, `options` could be changed. Since I'm now calculating the encoding on-demand, the encoding will also change. I'll fix this in another commit.

Hi @wangweij ,

Yes, I see the concern about the 50 KDCs scenario. But one nuance here: having different AD behaviors with issued tickets that won't be accepted in other services afterwards looks to me like a configuration problem that goes beyond OpenJDK. Now, if we cannot distinguish between S4U2Self and non-S4U2Self second tickets based on their actual data, it's likely that the KDC behaves in the same way when it comes to the forwardable flag -both in 2012 DC and after-. That would be a reason not to establish any difference in OpenJDK and behave in the same way. This official documentation here [1] makes no distinction between the two types:

"The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set (see Service 1 in the figure specifying Kerberos delegation with forwarded TGT, section 1.3.3). This ticket can be obtained through an S4U2self protocol exchange."

If we are concerned about this, why don't we let the user decide the behavior by means of a security/system property? That would also mitigate the risk of assuming that a KDC_ERR_BADOPTION error is always because of a non-forwardable ticket on a 2012 DC -which looks quite an assumption to me-.

Thanks,
Martin.-

--
[1] - https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/bde93b0e-f3c9-4ddf-9f44-e1453be7af5a

> First, my latest commit contains a mechanism to tell if a ticket is from S4U2self. Is it significant enough to change your mind?
> 
> Even if there is a system property for this purpose (suppose it's named `jdk.security.krb5.accept.non.forwardble.s4u2self.response.and.retry`), I wonder if it's worth turning it off. As you said, a  legitimate S4U2self should always be FORWARDABLE, and in this case the system property is useless. But, if a service really receives such a ticket, I assume it would prefer to try it in a S4U2proxy request instead of just failing early. After all, when it impersonates someone, its purpose should be accessing a backend service.
> 
> We usually introduce a system property for a compatibility reason so that existing normal cases will not behave differently, but here, we are simply trying to resurrect a former failure.
> 
> The main problem I see with the current approach is still about whether a "tolerant" KDC can be accessed in time. If this can be optimized by adjusting the orders of KDC either in krb5.conf or in the DNS response, then I would be greatly relieved.

Hi @wangweij ,

I liked the renaming that you proposed, including the 'ccreds -> middleTGT' change. I find it easier to reason about now. There is still a 'ccreds' in CredentialsUtil::acquireS4U2proxyCreds that you might want to check.

In regards to 'type' -and assuming that we want to keep that check-, can we re-use the CredentialsUtil::S4U2Type enum type? I'm fine if you want to move the enum location to Credentials.java.

I'm not sure that we are resurrecting an old failure. My understanding is that the new KrbException exception (in KdcComm::sendIfPossible) is causing a behavioral change in the sense that it's now allowing KDC iteration, and there is no way to go back to the old fail-immediately behavior. The property would be to avoid iterating over the 50 KDCs after the first failure; or it could be to not even try if the ticket is non-forwardable. In that sense, the property's name would be something like 'jdk.security.krb5.s4u2proxy.acceptNonForwardableServiceTicket'. My second concern is that the condition that we use to iterate might be beyond the forwardable flag scope, because we are now based on a KDC_ERR_BADOPTION error.

I personally wouldn't make any distinction between S4U2Self and non-S4U2Self second tickets when it comes to the second ticket forwardable flag.

> That `ccreds` in `acquireS4U2selfCreds`? I'll fix it.
> 
> Other comments accepted. I'll add a system property.

Hi @wangweij ,

Thanks for taking the backward-compatibility property suggestion.

I went through all the changes again and have some comments / questions:

 * I realized that the field 'Krb5Context::serviceCreds' in Krb5Context.java is now overloaded and might have two different value depending on whether it's an Initiator or an Acceptor context. A comment next to the field declaration might be helpful if you want to consider: "// On the Initiator side, contains the final TGS to a service on both delegation and no-delegation scenarios. On the Acceptor side, contains a user TGS usable for delegation.". Note that previous to this change, the field was meaningful for the Initiator side only, as the Acceptor side was using 'Krb5Context::serviceTicket'.

 * In Credentials.java, can we replace 'ccreds' with 'middleTGT' in acquireS4U2proxyCreds? This would align the names with CredentialsUtil::acquireS4U2proxyCreds and, in my opinion, would be more clear. Additionally, you might want to consider replacing 'ccreds' with 'initCreds' in acquireServiceCreds, so it's aligned with CredentialsUtil::acquireServiceCreds.

 * In KrbTgsReq.java, you said 'At the end of the constructor of KrbTgsReq, options could be changed. Since I'm now calculating the encoding on-demand, the encoding will also change. I'll fix this in another commit.'. Have you made that change? I still see 'obuf = ...' before 'options.set(KDCOptions.FORWARDED, true);'.

 * I'm not entirely sure of the reason why 'KrbKdcReq::getMessage' was reverted to 'KrbKdcReq::encoding'. It does not look wrong but wish I could understand the reason.

 * In CredentialsUtil.java, new line missing in 'return creds;' (CredentialsUtil::acquireS4U2selfCreds)

 * In java.security, I'd reword the text a bit (and fix a typo). One suggestion for you to consider:

"The S4U2proxy Kerberos extension enables a middle service to obtain a service ticket to another service on behalf of a user. It requires that the user service ticket to the middle service has the forwardable flag set [1]. However, some implementations ignore this requirement and accept service tickets with the flag unset.

If this security property is set to "true", then

1) The user service ticket, when obtained by the middle service after a S4U2self impersonation, is not required to have the forwardable flag set; and,

2) If a S4U2proxy request receives a KRB_ERROR of the KDC_ERR_BADOPTION error code and the ticket to the middle service is not forwardable, OpenJDK will try the same request in another KDC instead of treating it as a fatal failure.

The default value is "false".

If a system property of the same name is also specified, it supersedes the security property value defined here.

[1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/bde93b0e-f3c9-4ddf-9f44-e1453be7af5a
jdk.security.krb5.s4u2proxy.acceptNonForwardableServiceTicket=false
"

Thanks,
Martin.-

> All suggestions accepted, except that I still write out the full name for S4U2proxy in `java.security`.
> 
> For the `KrbKdcReq` method name. It's now `encoding` because it's returning a byte array. `getMessage` was used to return a message type.

Hi @wangweij 

Thanks for considering my suggestions.

I agree with removing the 'forwardable middle service TGT' requirement from S4U2Self.

This looks good to me.

Note: I'm not an official JDK Reviewer so you'll need someone else to have a look.

Martin.-

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From valeriep at openjdk.java.net  Mon Nov 22 19:06:45 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 22 Nov 2021 19:06:45 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
Message-ID: <V20utPVe9VjaFTJ0rnuMcGLju9RyvephCSjTO-Ax1cA=.94ed894a-1974-4bc5-a7f2-f626883f8f19@github.com>

On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
> 
> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.

src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java line 64:

> 62:         PrincipalName sname = middleTGT.getClient();
> 63:         String uRealm = user.getRealmString();
> 64:         String localRealm = middleTGT.getClient().getRealmString();

nit: can just use sname on line 64?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From weijun at openjdk.java.net  Mon Nov 22 19:06:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Nov 2021 19:06:47 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <V20utPVe9VjaFTJ0rnuMcGLju9RyvephCSjTO-Ax1cA=.94ed894a-1974-4bc5-a7f2-f626883f8f19@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <V20utPVe9VjaFTJ0rnuMcGLju9RyvephCSjTO-Ax1cA=.94ed894a-1974-4bc5-a7f2-f626883f8f19@github.com>
Message-ID: <NtPM0QPhE9p5RFnhZ3mvxTGYmwDQJ8fhvqpO9e_vCk8=.840d530a-49fb-44a0-a63d-5ec64658ce60@github.com>

On Fri, 19 Nov 2021 23:34:11 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
>> 
>> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java line 64:
> 
>> 62:         PrincipalName sname = middleTGT.getClient();
>> 63:         String uRealm = user.getRealmString();
>> 64:         String localRealm = middleTGT.getClient().getRealmString();
> 
> nit: can just use sname on line 64?

Sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From weijun at openjdk.java.net  Mon Nov 22 19:06:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Nov 2021 19:06:39 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <n2iA4i90HVy8jfK2xFGFw6LjivB7JKGA2GjMtdC13Rs=.4215497d-698e-4753-b180-2329e051e99b@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <n2iA4i90HVy8jfK2xFGFw6LjivB7JKGA2GjMtdC13Rs=.4215497d-698e-4753-b180-2329e051e99b@github.com>
Message-ID: <dCrOuBelH3OE-7dUlIFsc0nllHRKiIrH_AjA41e31C8=.3a8a3941-3ffa-47d6-b25f-9af9c79e3c27@github.com>

On Thu, 28 Oct 2021 19:21:02 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> * The names 'second' and 'secondTicket' -that were used before- don't look ideal to me. I've not seen them used neither in RFC 4120 nor in MS-SFU (v.20.0). In the case of 'additionalTickets', it's defined in RFC 4120 but more from a message-format perspective than with any specific semantics. Many of us are familiar to these names at this point but perhaps we can take this opportunity to find a better replacement. These are service tickets used for impersonation, from a user principal probably. I used 'userSvcTicket' when working on the Referrals feature. It could be that or something different. I'm okay if you want to postpone this consideration, but I wanted to raise it just in case.

I see what you mean. I'll go through them.

> * While I see the need of introducing a new class to the hierarchy (KrbKdcReq), I'd rearrange that a bit if possible. In particular, I'd make ::getMessage part of the interface, instead of ::encoding, and then delegate to the message (KDCReq --> ASReq | TGSReq) the encoding. In fact, the message already does the encoding; it's just caching it in the same place where it's done -which should be fine as the message is non-mutable-. This would simplify things a bit and we can have only one 'obuf' field in KDCReq, instead of caching it both in KrbAsReq and KrbTgsReq. We are not loosing encapsulation because the message is already accessible. What do you think?

Good idea.

> * In CredentialsUtil.java, I see how the checks 'additionalTickets == null || additionalTickets.length == 0' were replaced by 'second == null', but what about the check 'credsInOut[1] == null'?

Sorry, missed it.

> * I want to notice that 'additionalTickets' was technically an 'in/out' parameter in CredentialsUtil::serviceCredsReferrals. I couldn't find any consequence of making it an 'in' parameter, but just in case I want to mention this. I believe the only function that could have used that information is CredentialsUtil::acquireS4U2proxyCreds but it's an r-value there so it should be fine.

That's right. Although the content of the original array argument could be modified, the caller has not used it. In fact, changing it from array to a normal object makes me feel relieved. I always needed to remind myself that this was not meant to be an '[out]' parameter.

> * A KDC_ERR_BADOPTION error meaning that the KDC requires the 'FORWARDABLE' option in the ticket is what the code suggests. Is it possible that this is not what really happened and there is something else wrong? In other words, is it possible that a DS_BEHAVIOR_WIN2012 DC returns this error?

I don't know.

> * The FORWARDABLE check removed is the one in S4U2Self. Apparently, for S4U2Proxy with non-S4U2Self second-tickets there were no checks. Now we check at S4U2Proxy level (for all 'second' tickets, S4U2Self and non-S4U2Self ones). Is that okay? Or do we need to be more specific and check for S4U2Self second-tickets only (in a S4U2Proxy communication)?

That's what I asked you about a more precise way to ensure a cred is a S4U2self one. I thought about stuff the `S4U2Type` value as a "type" field into the credentials returned by `serviceCreds()` but it looks a little ugly.

> 
> Otherwise, looks good to me.

Thanks.

> 
> Thanks, Martin.-

Hi @martinuy, I looked at the variable names. Some can be named `clientCreds` or `proxyCreds`. Some are for a general `additionalTickets`. I can name it to `additionalCreds` but this "creds" is only one object and not an array.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From valeriep at openjdk.java.net  Mon Nov 22 21:29:09 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 22 Nov 2021 21:29:09 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag
In-Reply-To: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
Message-ID: <cUUNPxyf3MykkiedcedA2PLDzWd1UAQwASJCpFidRzY=.0c8dbcb8-0696-4fd9-acf4-e3c73bf5174b@github.com>

On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
> 
> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.

src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 69:

> 67:     private static boolean alreadyTried = false;
> 68: 
> 69:     public final static boolean S4U2PROXY_ACCEPT_NON_FORWARDABLE

nit: swap to use "static final"

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From darcy at openjdk.java.net  Mon Nov 22 21:55:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 22 Nov 2021 21:55:21 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v26]
In-Reply-To: <Ck-IxUi_PmVxuycKrHWlXSgRy7B3L-XEf23m1Lief8U=.8320f211-3752-4ae8-beab-58b180870790@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <Ck-IxUi_PmVxuycKrHWlXSgRy7B3L-XEf23m1Lief8U=.8320f211-3752-4ae8-beab-58b180870790@github.com>
Message-ID: <PPmB7JwIHcB9o_EKeZlI_FKzjvlSc288ui_NpfkbUXo=.ad0a87a3-24aa-40c1-b68c-caca7890db6b@github.com>

On Mon, 22 Nov 2021 12:09:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Merge branch 'master' into JEP-419
>  - Fix javadoc issues found in CSR review
>  - Adopt blessed modofier order
>  - Merge branch 'master' into JEP-419
>  - Revert removal of upcall MH customization
>    (This change caused spurious VM crashes, so reverting to baseline)
>  - Further tweak upcall safety considerations
>  - Clarify safety considerations for upcalls
>  - Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress
>    (which is consistent with other restricted factories in VaList and NativeSymbol)
>  - Streamline javadoc for package-info
>  - * Add two new CLinker static methods to compute upcall/downcall method types
>    * Clarify section on CLinker downcall type
>    * Add section on CLinker safety guarantees
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/d427c79d...29cc6c60

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From weijun at openjdk.java.net  Mon Nov 22 22:04:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Nov 2021 22:04:11 GMT
Subject: RFR: 8277246: Check for NonRepudiation as well when validating a
 TSA certificate [v3]
In-Reply-To: <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>
References: <EkEZwv2z5seunQZ0YZZZAItuqOVYgRu5fSUKMJPIbQA=.a831bdcb-6d21-4b1d-9c7a-cdd5c7c1df47@github.com>
 <NBxFVRCbNTwgW9ydGXEIy1a3UpI-FTBBbjiXyH5FgaQ=.24ebbbc2-7e39-4016-a712-96a3eb38adcf@github.com>
Message-ID: <z3FTB5oVxkykg7LdzhtIRzAqm6wiJ2OOVEMtDn5-2e8=.b8c0bc5e-124d-4b3e-827b-f138f9238b14@github.com>

On Wed, 17 Nov 2021 14:06:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>> 
>> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check either KU_SIGNATURE or KU_NON_REPUDIATION

Great. Thanks a lot for your suggestion to them. I really appreciate it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416

From valeriep at openjdk.java.net  Tue Nov 23 03:03:29 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 23 Nov 2021 03:03:29 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService()
Message-ID: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>

It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.

Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 

The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.

Please review and thanks in advance,
Valerie

-------------

Commit messages:
 - Removed obsolete private method.
 - 8276660: Scalability bottleneck in java.security.Provider.getService()

Changes: https://git.openjdk.java.net/jdk/pull/6513/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6513&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276660
  Stats: 382 lines in 1 file changed: 150 ins; 97 del; 135 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6513/head:pull/6513

PR: https://git.openjdk.java.net/jdk/pull/6513

From duke at openjdk.java.net  Tue Nov 23 08:29:09 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Nov 2021 08:29:09 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService()
In-Reply-To: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
Message-ID: <IwckAHOFwYhR2TpEPM57x5qXkO3JN3xwPZ-WEhpIRd4=.97454e3b-87ae-4cb1-967f-a0aed9d6af5b@github.com>

On Tue, 23 Nov 2021 02:55:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
> 
> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
> 
> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
> 
> Please review and thanks in advance,
> Valerie

src/java.base/share/classes/java/security/Provider.java line 919:

> 917: 
> 918:         Object o = super.remove(key);
> 919:         if (o != null && o instanceof String && key instanceof String) {

`o != null` seems redundant here. `o instanceof String` will be false in case of `o == null`

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From duke at openjdk.java.net  Tue Nov 23 08:35:10 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Nov 2021 08:35:10 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService()
In-Reply-To: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
Message-ID: <2e5Mp9CgvdZDzUO0CrzdEjy0zVhCe_YPIH7FSgywbIc=.9a6a12b8-5bc8-402d-b385-d001dff01000@github.com>

On Tue, 23 Nov 2021 02:55:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
> 
> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
> 
> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
> 
> Please review and thanks in advance,
> Valerie

src/java.base/share/classes/java/security/Provider.java line 930:

> 928:         boolean result = super.remove(key, value);
> 929:         if (result && key instanceof String && value instanceof String) {
> 930:             parseLegacy((String)key, (String)value, OPType.REMOVE);

I suggest to use pattern matching for instanceof to avoid manual casts

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From hans at guardianproject.info  Tue Nov 23 16:51:33 2021
From: hans at guardianproject.info (Hans-Christoph Steiner)
Date: Tue, 23 Nov 2021 17:51:33 +0100
Subject: JEP draft: TLS Encrypted ClientHello (ECH)
Message-ID: <1252f442-92e0-a721-823b-0d7b3b163b54@guardianproject.info>


The next revision of the IETF-standardized TLS protocol is known as Encrypted 
ClientHello (ECH) [0] formerly known as Encrypted SNI (ESNI). There is a related 
standard DNS RR Type known as SVCB or HTTPS [8].  ECH is built on top of TLSv1.3 
and completes unfinished work from the TLSv1.3 effort.  It is now in draft-13 
and there are many implementations that are interoperating.  I'm posting to 
start the discussion about implementing this in OpenJDK.  The IETF process is 
now in the interoperability testing phase, so we now need feedback from 
implementers.

ECH adds a new key to the TLS exchange, and the recommended way to get that key 
is from HTTPS/SVCB DNS queries.  It is not yet fixed where the right place to 
handle that DNS query, but it is clear that clients will have to do things 
differently to support ECH and/or SVCB.  The recommended way to use ECH is to 
get the ECH Config List and IP address info from the same DNS query.  This 
probably means that the DNS query needs to happen first, before creating the 
SSLSocket.

ECH is working for openssl[2], boringssl[3], nginx, Apache HTTP Server, 
lighttpd, HAProxy, Conscrypt[4], curl, and more.  There is work underway in 
Firefox [5] and Chromium [6].  It has been sketched out for OkHTTP [7].  Draft 
versions of ESNI and ECH have been deployed in Firefox releases and some 
production web services.

Here are some key pieces that need implementing for the client:

* HTTPS/SVCB DNS queries for getting ECH Config Lists.
* A way to provide ECH Config Lists as bytes to the SSLSocket.
* A method to ensure encrypted DNS is used so all metadata is encrypted,
   and that the DNS resolver is modern enough to handle new RR types.
* A callback that gets called whenever ECH negotiation fails and the server
   offers a "Retry Config".

FYI, the IETF TLS WG maintain a page with information about other implementations:
https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementations


[0] https://www.ietf.org/archive/id/draft-ietf-tls-esni-13.html
[1] https://bugs.python.org/issue45567
[2] https://github.com/openssl/openssl/issues/7482
[3] https://bugs.chromium.org/p/boringssl/issues/detail?id=275
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1725938
[6] https://bugs.chromium.org/p/chromium/issues/detail?id=1091403
[6] https://github.com/google/conscrypt/issues/730
[7] https://github.com/square/okhttp/issues/6539
[8] https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.html
[9] https://github.com/sftcd/openssl


Below is a draft JEP:
=============================================================


Title: TLS Encrypted ClientHello (ECH)
Author: Hans-Christoph Steiner
Organization: DEfO/Guardian Project
Created: 2021/11/22
Type: Feature
State: Draft
Exposure: Open
Scope: SE
Component: security-libs/javax.net.ssl
Discussion: security-dev at openjdk.java.net
Effort:	M


Summary
-------

Implement the TLS Encrypted ClientHello (ECH) Extension to allow more
secure and private internet connections when using TLS protocols.


Motivation
----------

TLS ECH is the next step in the development of the TLS protocol.  It provides
significant security improvements over previous versions. Several early
implementations from other vendors are already available.  Java should support
TLS ECH to remain compatible with the latest TLS standards.

The JDK should support ECH so that Java clients can use ECH when talking to web
services.  Since Java web services are often behind other servers which handle
terminating TLS, it is less important that the server-side is implemented.
There are already many interoperable implementations:

* Firefox supports ESNI in releases and is implementing ECH.
* Chromium is implementing ECH.
* BoringSSL merged working ECH support.
* Cloudflare deployed ESNI in production and has working ECH support.

There are working development forks of many projects that have been reviewed by
the upstream developers.  These should be merged once ECH hits RFC status:

* Apache HTTP Server
* boringssl
* Conscrypt
* curl
* HAProxy
* LigHTTPD
* nginx
* OkHTTP
* OpenSSL

Description
-----------

ECH is an extension to the TLS 1.3 protocol to encrypt sensitive metadata that is
currently in plain text in the TLS 1.3 negotiation process.  The primary goal of
this JEP is a minimal interoperable and compatible TLS ECH implementation. A
minimal implementation should support:

* Automatic fetching of ECH Config Lists from DNS via HTTPS and SVCB RR Types
* API for passing ECH Config Lists (byte arrays) the SSLSocket
* Enabling/disabling ECH GREASE
* Automatic handling of ECH Retry Configs
* SSLServerSocket API for setting and rotating ECH Key and Config
* API for generating ECH Key and Config for the server-side


Alternatives
------------

In order to provide more complete privacy protections, many setups have to use
VPNs and/or encrypted tunnels to reduce metadata leakage to the networks.

Testing
-------

There are already public web services available that use ECH.  There are also
other client and server implementations available to test against.

Assumptions
-----------

A third party TLS 1.3 ECH implementation that supports the RFC is required for
interoperability testing.  There are already working implementations in openssl,
boringssl, and live on Cloudflare.


Dependencies
-----------

The DNS will work with JNDI using numeric RR Types (e.g. "65" for HTTPS).
Ideally, the "HTTPS" and "SVCB" DNS RR Type names would be included in JNDI.


Impact
------

* Other JDK components: no impact on other JDK components
* Compatibility: no impact on compatibility for older TLS versions
* User Interface: no graphic user interface
* Portability: the DNS component works with JNDI
* Documentation: need to doc the new methods
* Internationalization: minimal impact, new error messages and methods
* Legal: no legal issue




-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

From weijun at openjdk.java.net  Wed Nov 24 02:45:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 24 Nov 2021 02:45:37 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag [v2]
In-Reply-To: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
Message-ID: <FVATzwwDHbzG31rslq_4pkFLKX5vITjBdlwPbKje6mo=.61ddf18d-0bbd-4ee2-a4eb-2f4d7ea83f0c@github.com>

> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
> 
> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  some word changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6082/files
  - new: https://git.openjdk.java.net/jdk/pull/6082/files/c07e6f64..1f93a881

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6082&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6082&range=00-01

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6082/head:pull/6082

PR: https://git.openjdk.java.net/jdk/pull/6082

From weijun at openjdk.java.net  Wed Nov 24 02:45:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 24 Nov 2021 02:45:41 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag [v2]
In-Reply-To: <cUUNPxyf3MykkiedcedA2PLDzWd1UAQwASJCpFidRzY=.0c8dbcb8-0696-4fd9-acf4-e3c73bf5174b@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <cUUNPxyf3MykkiedcedA2PLDzWd1UAQwASJCpFidRzY=.0c8dbcb8-0696-4fd9-acf4-e3c73bf5174b@github.com>
Message-ID: <kEJktyhSvoe3_fFfsphksZSIrQF7LLj94RobMuDE-8U=.86c6b37f-3dfa-4198-95fd-85e73259cad0@github.com>

On Mon, 22 Nov 2021 21:26:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some word changes
>
> src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 69:
> 
>> 67:     private static boolean alreadyTried = false;
>> 68: 
>> 69:     public final static boolean S4U2PROXY_ACCEPT_NON_FORWARDABLE
> 
> nit: swap to use "static final"

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From mcimadamore at openjdk.java.net  Wed Nov 24 11:55:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 24 Nov 2021 11:55:11 GMT
Subject: Integrated: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator)
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <lMUznRCV0PQNur1JEW_x9940VAD3m5xhSAWLWpEZaLA=.ccc1b83b-98e5-4aa6-a237-7c482550ab7e@github.com>

On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

This pull request has now been integrated.

Changeset: 96e36071
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/96e36071b63b624d56739b014b457ffc48147c4f
Stats:     14700 lines in 193 files changed: 6958 ins; 5126 del; 2616 mod

8275063: Implementation of Foreign Function & Memory API (Second incubator)

Reviewed-by: erikj, psandoz, jvernee, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/5907

From anders.rundgren.net at gmail.com  Wed Nov 24 16:14:36 2021
From: anders.rundgren.net at gmail.com (Anders Rundgren)
Date: Wed, 24 Nov 2021 17:14:36 +0100
Subject: Regression bug in PKCS12 key wrapping
Message-ID: <2c5ce2a8-8cc9-58ff-7fe7-2926583a5fcf@gmail.com>

Hi List,

Although this bug is for BC, I believe the problem is rather in JDK 17:
https://github.com/bcgit/bc-java/issues/823#issuecomment-977919380

Thanx,
Anders

From valeriep at openjdk.java.net  Wed Nov 24 18:01:08 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Nov 2021 18:01:08 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag [v2]
In-Reply-To: <FVATzwwDHbzG31rslq_4pkFLKX5vITjBdlwPbKje6mo=.61ddf18d-0bbd-4ee2-a4eb-2f4d7ea83f0c@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <FVATzwwDHbzG31rslq_4pkFLKX5vITjBdlwPbKje6mo=.61ddf18d-0bbd-4ee2-a4eb-2f4d7ea83f0c@github.com>
Message-ID: <8ruZbvR_vYoGEF91omws-6d3BWHM7Spzu2dJp2lEJY0=.372ed60d-357a-47fe-954a-d58b042280d6@github.com>

On Wed, 24 Nov 2021 02:45:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
>> 
>> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some word changes

Looks good. Thanks, Valerie

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6082

From valeriep at openjdk.java.net  Wed Nov 24 20:29:03 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Nov 2021 20:29:03 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService()
In-Reply-To: <2e5Mp9CgvdZDzUO0CrzdEjy0zVhCe_YPIH7FSgywbIc=.9a6a12b8-5bc8-402d-b385-d001dff01000@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <2e5Mp9CgvdZDzUO0CrzdEjy0zVhCe_YPIH7FSgywbIc=.9a6a12b8-5bc8-402d-b385-d001dff01000@github.com>
Message-ID: <kc_uOg-u0XXyAIMPBb7f61SReuQSPEURVR5QiZsj67s=.d7af88dd-00ee-4921-8aa0-ca8b4d6c39d2@github.com>

On Tue, 23 Nov 2021 08:32:24 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
>> 
>> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
>> 
>> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
>> 
>> Please review and thanks in advance,
>> Valerie
>
> src/java.base/share/classes/java/security/Provider.java line 930:
> 
>> 928:         boolean result = super.remove(key, value);
>> 929:         if (result && key instanceof String && value instanceof String) {
>> 930:             parseLegacy((String)key, (String)value, OPType.REMOVE);
> 
> I suggest to use pattern matching for instanceof to avoid manual casts

Sure, will do so. Thanks for the suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Wed Nov 24 21:17:34 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Nov 2021 21:17:34 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
Message-ID: <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>

> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
> 
> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
> 
> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
> 
> Please review and thanks in advance,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Updated to use pattern matching with instanceof operator.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6513/files
  - new: https://git.openjdk.java.net/jdk/pull/6513/files/3124e14c..37dc1d9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6513&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6513&range=00-01

  Stats: 34 lines in 1 file changed: 1 ins; 0 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6513/head:pull/6513

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Thu Nov 25 00:48:02 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Nov 2021 00:48:02 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <IwckAHOFwYhR2TpEPM57x5qXkO3JN3xwPZ-WEhpIRd4=.97454e3b-87ae-4cb1-967f-a0aed9d6af5b@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <IwckAHOFwYhR2TpEPM57x5qXkO3JN3xwPZ-WEhpIRd4=.97454e3b-87ae-4cb1-967f-a0aed9d6af5b@github.com>
Message-ID: <1nj21YtFCY_HaKz7Yg0fmzLslg0YZp2qZB96b7xBo9c=.689a8b8b-7c59-41aa-9c3d-f5f39031427d@github.com>

On Tue, 23 Nov 2021 08:25:42 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use pattern matching with instanceof operator.
>
> src/java.base/share/classes/java/security/Provider.java line 919:
> 
>> 917: 
>> 918:         Object o = super.remove(key);
>> 919:         if (o != null && o instanceof String && key instanceof String) {
> 
> `o != null` seems redundant here. `o instanceof String` will be false in case of `o == null`

Yup, removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From weijun.wang at oracle.com  Thu Nov 25 03:10:13 2021
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Thu, 25 Nov 2021 03:10:13 +0000
Subject: Regression bug in PKCS12 key wrapping
In-Reply-To: <2c5ce2a8-8cc9-58ff-7fe7-2926583a5fcf@gmail.com>
References: <2c5ce2a8-8cc9-58ff-7fe7-2926583a5fcf@gmail.com>
Message-ID: <4B9A70EB-2CC9-49DE-B8C1-274D71435B40@oracle.com>


> On Nov 24, 2021, at 11:14 AM, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> Hi List,
> 
> Although this bug is for BC, I believe the problem is rather in JDK 17:
> https://github.com/bcgit/bc-java/issues/823#issuecomment-977919380

Can you point out which part in JDK 17 the problem is?

Please note that in JDK 17 the default encryption algorithm for PKCS12 is upgraded to PBEWithHmacSHA256AndAES_256. If BC's decryption is not an exact reverse of SUN's encryption, then definitely the output will be garbage and you will not see the correct padding bytes.

Thanks,
Max

> 
> Thanx,
> Anders


From anders.rundgren.net at gmail.com  Thu Nov 25 05:39:44 2021
From: anders.rundgren.net at gmail.com (Anders Rundgren)
Date: Thu, 25 Nov 2021 06:39:44 +0100
Subject: Regression bug in PKCS12 key wrapping
In-Reply-To: <4B9A70EB-2CC9-49DE-B8C1-274D71435B40@oracle.com>
References: <2c5ce2a8-8cc9-58ff-7fe7-2926583a5fcf@gmail.com>
 <4B9A70EB-2CC9-49DE-B8C1-274D71435B40@oracle.com>
Message-ID: <0aec52d2-f3a9-ad55-1d78-86231ab60df5@gmail.com>

Apparently there was a bug in BC.  The GitHub issue has been updated.
Case dismissed :)

thanx,
Anders

On 2021-11-25 4:10, Wei-Jun Wang wrote:
> 
>> On Nov 24, 2021, at 11:14 AM, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
>>
>> Hi List,
>>
>> Although this bug is for BC, I believe the problem is rather in JDK 17:
>> https://github.com/bcgit/bc-java/issues/823#issuecomment-977919380
> 
> Can you point out which part in JDK 17 the problem is?
> 
> Please note that in JDK 17 the default encryption algorithm for PKCS12 is upgraded to PBEWithHmacSHA256AndAES_256. If BC's decryption is not an exact reverse of SUN's encryption, then definitely the output will be garbage and you will not see the correct padding bytes.
> 
> Thanks,
> Max
> 
>>
>> Thanx,
>> Anders
> 


From duke at openjdk.java.net  Thu Nov 25 10:45:11 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 25 Nov 2021 10:45:11 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
Message-ID: <AKxR-1TK9RWvc3ITRvEJOC9z9jTpVCpUF_Bg0ajfXaU=.5b911efb-cae0-4465-8527-cbff380bfce4@github.com>

On Wed, 24 Nov 2021 21:17:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
>> 
>> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
>> 
>> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
>> 
>> Please review and thanks in advance,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use pattern matching with instanceof operator.

src/java.base/share/classes/java/security/Provider.java line 1292:

> 1290:         }
> 1291: 
> 1292:         if (!legacyMap.isEmpty()) {

Looks like this check is redundant. get() will return `null` anyway.

src/java.base/share/classes/java/security/Provider.java line 1295:

> 1293:             Service s = legacyMap.get(key);
> 1294:             if (s != null && !s.isValid()) {
> 1295:                 legacyMap.remove(key);

I wonder if it's better to use `legacyMap.remove(key, value);` here. What if another thread put some other value by the same key?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From duke at openjdk.java.net  Thu Nov 25 11:04:09 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 25 Nov 2021 11:04:09 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
Message-ID: <n-GOi8usDvpd8tyZiKjPECS-4isPbwiNriliJE7sQAE=.03ad05f5-3c8a-4564-9771-579fc3a41b6d@github.com>

On Wed, 24 Nov 2021 21:17:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
>> 
>> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
>> 
>> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
>> 
>> Please review and thanks in advance,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use pattern matching with instanceof operator.

src/java.base/share/classes/java/security/Provider.java line 1324:

> 1322:     public Set<Service> getServices() {
> 1323:         checkInitialized();
> 1324:         if (serviceSet == null || legacyChanged || servicesChanged) {

`serviceSet` should be at least made `volatile`

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From duke at openjdk.java.net  Sat Nov 27 17:45:02 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Sat, 27 Nov 2021 17:45:02 GMT
Subject: RFR: 8274811: Remove superfluous use of boxing in java.base
In-Reply-To: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
References: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
Message-ID: <v9rzeOBEguCXoOFqzMfHzK7Tksg9bq0Il6f-2h6gQDk=.f42c7ec5-f09b-4d14-afdb-5f56f222208b@github.com>

On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop
> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset

let's wait for review a bit more

-------------

PR: https://git.openjdk.java.net/jdk/pull/5481

From duke at openjdk.java.net  Mon Nov 29 08:50:27 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 29 Nov 2021 08:50:27 GMT
Subject: RFR: 8277881 Missing SessionID in TLS1.3 resumption in compatibility
 mode
Message-ID: <OSdmLyXOjDALwV-MtAJCo6-yErvMQwLbjblvbOxCTa4=.29adf113-d39d-4f45-8c08-6310049e7757@github.com>

All TLS 1.3 handshakes in compatibility mode must send a non-empty SessionID field. Currently TLS1.3 session resumptions are sending empty session ID. This patch fixes that problem.

All jdk_core tests passed. The newly added check passes with the patch, fails without it.

-------------

Commit messages:
 - Add bug ID
 - Send SessionID during TLS 1.3 resumption

Changes: https://git.openjdk.java.net/jdk/pull/6583/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6583&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277881
  Stats: 14 lines in 3 files changed: 4 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6583.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6583/head:pull/6583

PR: https://git.openjdk.java.net/jdk/pull/6583

From weijun at openjdk.java.net  Mon Nov 29 23:28:09 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 29 Nov 2021 23:28:09 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
Message-ID: <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>

On Wed, 24 Nov 2021 21:17:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
>> 
>> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
>> 
>> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
>> 
>> Please review and thanks in advance,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use pattern matching with instanceof operator.

Some comments. I'm more concerned about the `parseLegacy()` method which is called everywhere. Without the synchronized keyword, is it safe to call into this method by multiple threads at the same time? Do we have tests around this?

src/java.base/share/classes/java/security/Provider.java line 832:

> 830:     // NOTE: may need extra mechanism for providers to indicate their
> 831:     // preferred ordering of SecureRandom algorithms since registration
> 832:     // ordering info is lost once serialized

Why is the ordering info lost once serialized? Weren't all entries re-added again in their original order?

src/java.base/share/classes/java/security/Provider.java line 901:

> 899:             legacyChanged = true;
> 900:         }
> 901:         return true;

Better put this "return" line into the else block.

src/java.base/share/classes/java/security/Provider.java line 979:

> 977:                 parseLegacy(sk, sv, OPType.REPLACE);
> 978:             }
> 979:         }

If you are going through all the entries, should we also clean up the legacy sets and restart?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Tue Nov 30 01:54:07 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 01:54:07 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <AKxR-1TK9RWvc3ITRvEJOC9z9jTpVCpUF_Bg0ajfXaU=.5b911efb-cae0-4465-8527-cbff380bfce4@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <AKxR-1TK9RWvc3ITRvEJOC9z9jTpVCpUF_Bg0ajfXaU=.5b911efb-cae0-4465-8527-cbff380bfce4@github.com>
Message-ID: <iCYTNV2BFLOCc4hC_QNLKmL_iljBytb1hj3cAowjsaM=.29339c6e-5f94-4c7e-b79d-aa969c798622@github.com>

On Thu, 25 Nov 2021 10:41:32 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use pattern matching with instanceof operator.
>
> src/java.base/share/classes/java/security/Provider.java line 1295:
> 
>> 1293:             Service s = legacyMap.get(key);
>> 1294:             if (s != null && !s.isValid()) {
>> 1295:                 legacyMap.remove(key);
> 
> I wonder if it's better to use `legacyMap.remove(key, value);` here. What if another thread put some other value by the same key?

Sure, I can do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Tue Nov 30 02:34:08 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 02:34:08 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <AKxR-1TK9RWvc3ITRvEJOC9z9jTpVCpUF_Bg0ajfXaU=.5b911efb-cae0-4465-8527-cbff380bfce4@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <AKxR-1TK9RWvc3ITRvEJOC9z9jTpVCpUF_Bg0ajfXaU=.5b911efb-cae0-4465-8527-cbff380bfce4@github.com>
Message-ID: <2I6qENRJgqDzLuhpw9t3KHAq-PP1S7GUOaHRPq-v7Mg=.c19febef-97a0-445f-9a11-9131c343928f@github.com>

On Thu, 25 Nov 2021 10:42:14 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use pattern matching with instanceof operator.
>
> src/java.base/share/classes/java/security/Provider.java line 1292:
> 
>> 1290:         }
>> 1291: 
>> 1292:         if (!legacyMap.isEmpty()) {
> 
> Looks like this check is redundant. get() will return `null` anyway.

Hmm, I suppose so.

> src/java.base/share/classes/java/security/Provider.java line 1324:
> 
>> 1322:     public Set<Service> getServices() {
>> 1323:         checkInitialized();
>> 1324:         if (serviceSet == null || legacyChanged || servicesChanged) {
> 
> `serviceSet` should be at least made `volatile`

Sure, will fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Tue Nov 30 02:44:06 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 02:44:06 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
Message-ID: <aM9yvBS6YtXPft9bMHUHBU4YIQHVfPbCgN41HE_O8gs=.3318d0fc-9228-45cd-810d-d2fe6e46dffa@github.com>

On Tue, 23 Nov 2021 15:02:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use pattern matching with instanceof operator.
>
> src/java.base/share/classes/java/security/Provider.java line 832:
> 
>> 830:     // NOTE: may need extra mechanism for providers to indicate their
>> 831:     // preferred ordering of SecureRandom algorithms since registration
>> 832:     // ordering info is lost once serialized
> 
> Why is the ordering info lost once serialized? Weren't all entries re-added again in their original order?

The serialized bytes are just the mappings, i.e. key + value pairs. There are no ordering info associated with the key + value pair. IIRC, the particular thing about SecureRandom is that the first registration of SecureRandom is deemed to be the most preferred. However, if given only the serialized bytes, the entries are added based on the resulting order stored by the parent class, not necessarily the ordering of the initial insertion/add calls.

> src/java.base/share/classes/java/security/Provider.java line 901:
> 
>> 899:             legacyChanged = true;
>> 900:         }
>> 901:         return true;
> 
> Better put this "return" line into the else block.

Sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Tue Nov 30 02:51:10 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 02:51:10 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
Message-ID: <i0ntwOOns48Sh_3Zewxk4YV7vc4Xkz5pERIyLNoFnV4=.afdeced3-2004-4d95-a47a-a1227fae76f8@github.com>

On Mon, 29 Nov 2021 23:10:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use pattern matching with instanceof operator.
>
> src/java.base/share/classes/java/security/Provider.java line 979:
> 
>> 977:                 parseLegacy(sk, sv, OPType.REPLACE);
>> 978:             }
>> 979:         }
> 
> If you are going through all the entries, should we also clean up the legacy sets and restart?

Do you mean simply wipe out the legacyMap and just do ADD instead of REPLACE?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From weijun at openjdk.java.net  Tue Nov 30 13:56:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Nov 2021 13:56:14 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <i0ntwOOns48Sh_3Zewxk4YV7vc4Xkz5pERIyLNoFnV4=.afdeced3-2004-4d95-a47a-a1227fae76f8@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
 <i0ntwOOns48Sh_3Zewxk4YV7vc4Xkz5pERIyLNoFnV4=.afdeced3-2004-4d95-a47a-a1227fae76f8@github.com>
Message-ID: <U85Djw27y2P_Fru3Z9T9xGTgjPIV2XqI-qbVU1E0dTs=.23ecba77-1c79-4a60-97c9-c11a94805c05@github.com>

On Tue, 30 Nov 2021 02:47:45 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Provider.java line 979:
>> 
>>> 977:                 parseLegacy(sk, sv, OPType.REPLACE);
>>> 978:             }
>>> 979:         }
>> 
>> If you are going through all the entries, should we also clean up the legacy sets and restart?
>
> Do you mean simply wipe out the legacyMap and just do ADD instead of REPLACE?

Yes, since you are simply iterating through all the entries instead of only the changed ones.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From weijun at openjdk.java.net  Tue Nov 30 14:02:10 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Nov 2021 14:02:10 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <aM9yvBS6YtXPft9bMHUHBU4YIQHVfPbCgN41HE_O8gs=.3318d0fc-9228-45cd-810d-d2fe6e46dffa@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
 <aM9yvBS6YtXPft9bMHUHBU4YIQHVfPbCgN41HE_O8gs=.3318d0fc-9228-45cd-810d-d2fe6e46dffa@github.com>
Message-ID: <XdiX6uuFFN19y7ZZFXaKexphCl9BuIHT3fYfuaak1Ew=.c42efb44-07b7-42d2-8428-14649d150a90@github.com>

On Tue, 30 Nov 2021 02:40:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Provider.java line 832:
>> 
>>> 830:     // NOTE: may need extra mechanism for providers to indicate their
>>> 831:     // preferred ordering of SecureRandom algorithms since registration
>>> 832:     // ordering info is lost once serialized
>> 
>> Why is the ordering info lost once serialized? Weren't all entries re-added again in their original order?
>
> The serialized bytes are just the mappings, i.e. key + value pairs. There are no ordering info associated with the key + value pair. IIRC, the particular thing about SecureRandom is that the first registration of SecureRandom is deemed to be the most preferred. However, if given only the serialized bytes, the entries are added based on the resulting order stored by the parent class, not necessarily the ordering of the initial insertion/add calls.

I see. How about serializing `prngAlgos` as a list?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From mbalao at openjdk.java.net  Tue Nov 30 19:02:06 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 30 Nov 2021 19:02:06 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <8vTXZjaSwUZ3IoHJcfC2cllpmm75dey2vtvVenwo1I4=.8e9ed87b-36de-42c6-b70b-554ba2db23ab@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
 <8vTXZjaSwUZ3IoHJcfC2cllpmm75dey2vtvVenwo1I4=.8e9ed87b-36de-42c6-b70b-554ba2db23ab@github.com>
Message-ID: <s_BsRCvDM73blvJJwBUFzV2zTgcbgwnWCuer8I0ZE70=.f6715098-8ce9-4290-9717-3fdec22807bc@github.com>

On Fri, 19 Nov 2021 19:50:33 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   P11Key static inner classes refactorings.
>
> Hmm, thinking more about "internal"/"opaque", given this is naming for the parent, maybe "internal" is more correct. The non-sensitive keys are encapsulated by the children classes and is still an instance of the parent. If you name the parent class w/ "opaque" suffix, it looks misleading/confusing. The opaqueness is implied by the implementation instead of the properties of the objects.

Hi @valeriepeng ,

Yes, I just verified how serialization works for P11Keys and your 'transient' change makes sense to me now.

I see your point about Internal/Opaque. Keep 'Internal' then if you prefer. The whole inheritance relationship between these classes sounds a bit weird to me, beyond the names we call them. I wouldn't suggest any additional changes there now, though.

It looks to me that the only 2 changes expected for Webrev.02 are: 1) P11RSAPrivateNonCRTKey to use the parent's protected 'n'; and 2) removal of 'long errorCode = e.getErrorCode();'.

Now that we almost have the changeset ready, I'm not sure of how to proceed with the push. Do you want me to commit Webrev.02 in my own branch and use the 'Co-authored-by:' header? If we do that, do we still need an additional Reviewer? Do you prefer to have your own branch? Please let me know of how to move forward.

Martin.-

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From valeriep at openjdk.java.net  Tue Nov 30 19:51:12 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 19:51:12 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <8vTXZjaSwUZ3IoHJcfC2cllpmm75dey2vtvVenwo1I4=.8e9ed87b-36de-42c6-b70b-554ba2db23ab@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
 <8vTXZjaSwUZ3IoHJcfC2cllpmm75dey2vtvVenwo1I4=.8e9ed87b-36de-42c6-b70b-554ba2db23ab@github.com>
Message-ID: <GK3nB9gsdNpbrhj1n25tpVXbQ285Zf1QccI3O2u3oGA=.404e8136-bf62-414c-b13d-d7db71f05ea6@github.com>

On Fri, 19 Nov 2021 19:50:33 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   P11Key static inner classes refactorings.
>
> Hmm, thinking more about "internal"/"opaque", given this is naming for the parent, maybe "internal" is more correct. The non-sensitive keys are encapsulated by the children classes and is still an instance of the parent. If you name the parent class w/ "opaque" suffix, it looks misleading/confusing. The opaqueness is implied by the implementation instead of the properties of the objects.

> Hi @valeriepeng ,
> 
> Yes, I just verified how serialization works for P11Keys and your 'transient' change makes sense to me now.
> 
> I see your point about Internal/Opaque. Keep 'Internal' then if you prefer. The whole inheritance relationship between these classes sounds a bit weird to me, beyond the names we call them. I wouldn't suggest any additional changes there now, though.
> 
> It looks to me that the only 2 changes expected for Webrev.02 are: 1) P11RSAPrivateNonCRTKey to use the parent's protected 'n'; and 2) removal of 'long errorCode = e.getErrorCode();'.
> 
> Now that we almost have the changeset ready, I'm not sure of how to proceed with the push. Do you want me to commit Webrev.02 in my own branch and use the 'Co-authored-by:' header? If we do that, do we still need an additional Reviewer? Do you prefer to have your own branch? Please let me know of how to move forward.
> 
> Martin.-

You can just incorporate the changes on your branch and proceeds with me being the reviewer. The webrev that I sent u is just an easier way to express the comments/feedbacks.

Thanks,
Valerie

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961

From valeriep at openjdk.java.net  Tue Nov 30 20:24:06 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 20:24:06 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
Message-ID: <tgJ4GWRfYF-v7wUgqyXxMivUDhUjcjHVvTPBH_7StS4=.5ab00c2a-bd27-4590-869b-80adb7a067cf@github.com>

On Mon, 29 Nov 2021 23:24:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Some comments. I'm more concerned about the `parseLegacy()` method which is called everywhere. Without the synchronized keyword, is it safe to call into this method by multiple threads at the same time? Do we have tests around this?

Hmm, the parseLegacy() method just processes the key/value legacy String-String mapping into corresponding service object (or its update) and store into the legacy service object (now typed as ConcurrentHashMap). I don't see any particular field which would require the "synchronized" keyword. There is test/jdk/java/security/Provider/GetServiceRace.java testing the legacy put() and getService() race condition. Not sure if it covers the scenarios you have in mind. Under most if not all usages, the legacy put() calls take place in provider constructor, unlike the getService() calls which may be called by different threads.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From weijun at openjdk.java.net  Tue Nov 30 20:54:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Nov 2021 20:54:14 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
Message-ID: <upmxCyeWKNkxpsA11kjdmXV4ipxZYkzUxktDvviFFS0=.54acf4ff-0434-46cf-a9a6-809cfff7febd@github.com>

On Wed, 24 Nov 2021 21:17:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service.
>> 
>> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". 
>> 
>> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass.
>> 
>> Please review and thanks in advance,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use pattern matching with instanceof operator.

Consider this case, two threads are changing a value at the same time. Since the method is not synchonized, thread1 might finish the first part of the method (`super.replace`) earlier than thread2, but it finishes the second part (`parseLegacy`) later than thread2. At the end, the internal entrySet has thread2's value but the legacy map has thread1's value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Tue Nov 30 22:19:04 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 22:19:04 GMT
Subject: RFR: 8272162: S4U2Self ticket without forwardable flag [v2]
In-Reply-To: <FVATzwwDHbzG31rslq_4pkFLKX5vITjBdlwPbKje6mo=.61ddf18d-0bbd-4ee2-a4eb-2f4d7ea83f0c@github.com>
References: <IMLHoan7CoKO0DEb-lW3Tf_8gwEhXUYi7JKxui7fDVM=.1fd3ecb7-ffa5-49eb-a5d3-19289e4e54a0@github.com>
 <FVATzwwDHbzG31rslq_4pkFLKX5vITjBdlwPbKje6mo=.61ddf18d-0bbd-4ee2-a4eb-2f4d7ea83f0c@github.com>
Message-ID: <vM-irKt6GaMVO99DENZSQEroR3s0h5TtT9WcW3tgdS8=.986f1d7f-6c52-4b51-b46d-1ac237cf5d67@github.com>

On Wed, 24 Nov 2021 02:45:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request.
>> 
>> There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some word changes

Marked as reviewed by valeriep (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6082

From valeriep at openjdk.java.net  Tue Nov 30 22:44:16 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 22:44:16 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <XdiX6uuFFN19y7ZZFXaKexphCl9BuIHT3fYfuaak1Ew=.c42efb44-07b7-42d2-8428-14649d150a90@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <pELStst8ko5Mf_BKZhi6NIz0UennI2f4hrb2iuiNV24=.035cdee0-1bca-4b78-a315-9af08fdee101@github.com>
 <aM9yvBS6YtXPft9bMHUHBU4YIQHVfPbCgN41HE_O8gs=.3318d0fc-9228-45cd-810d-d2fe6e46dffa@github.com>
 <XdiX6uuFFN19y7ZZFXaKexphCl9BuIHT3fYfuaak1Ew=.c42efb44-07b7-42d2-8428-14649d150a90@github.com>
Message-ID: <yRlvvDHf4CjnN0LM-O41YYQiaE6zYlsff6T24gH2RBE=.d1760cc2-a769-4e82-869a-6e92464c279d@github.com>

On Tue, 30 Nov 2021 13:59:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The serialized bytes are just the mappings, i.e. key + value pairs. There are no ordering info associated with the key + value pair. IIRC, the particular thing about SecureRandom is that the first registration of SecureRandom is deemed to be the most preferred. However, if given only the serialized bytes, the entries are added based on the resulting order stored by the parent class, not necessarily the ordering of the initial insertion/add calls.
>
> I see. How about serializing `prngAlgos` as a list?

That's one way to address this particular issue. However, it also breaks the serialization compatibility and we are somewhat bound to having 'prngAlgos' as part of the serialized fields. Since no one reported this as being an issue (yet), I wonder if it's worthwhile to address it this way and break the serialization compatibility. There are other possible approaches such as defining an alias or attribute for default SecureRandom algorithm/impl, so I just add a note here instead of serializing 'prngAlgos'.

>> Do you mean simply wipe out the legacyMap and just do ADD instead of REPLACE?
>
> Yes, since you are simply iterating through all the entries instead of only the changed ones.

Ok, will do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513

From valeriep at openjdk.java.net  Tue Nov 30 23:06:26 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Nov 2021 23:06:26 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <upmxCyeWKNkxpsA11kjdmXV4ipxZYkzUxktDvviFFS0=.54acf4ff-0434-46cf-a9a6-809cfff7febd@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <upmxCyeWKNkxpsA11kjdmXV4ipxZYkzUxktDvviFFS0=.54acf4ff-0434-46cf-a9a6-809cfff7febd@github.com>
Message-ID: <w6LDIKTRdwPAwYCXzjmF_XZArMxFSIjfYYk56qonvwQ=.3f5fca0f-e61e-418c-936a-ab16d0d3b5e5@github.com>

On Tue, 30 Nov 2021 20:50:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Consider this case, two threads are changing a value at the same time. Since the method is not synchonized, thread1 might finish the first part of the method (`super.replace`) earlier than thread2, but it finishes the second part (`parseLegacy`) later than thread2. At the end, the internal entrySet has thread2's value but the legacy map has thread1's value.

Well, then the synchronized keyword should be put on the public methods instead of the internal parseLegacy() method, no? Otherwise, the super.xxx() and the internal legacyMap may not updated in sync. The public methods did have the synchronized keywords which I removed since the putService() call isn't synchronized either (and it updates the serviceMap first and then stores the String-String mapping into super.xxx()). The main performance bottleneck is in getService(), so I can add back the "synchronized" keywords to other public methods if you are concerned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6513